How to reproduce:
What happens: "Lot number field is empty"
What is expected: Lot number should be "12345".
I can confirm this issue.
I just created a HAR dump from firefox to have this documented. During massRemoveStock
the lot number seems not be transfered, if I see it correctly. Thus it needs to be implemented in the project run (to be present when clicking on "remove parts from stock".
Hello! I saw this issue on bountysource so I had a look at the code.
I was able to reproduce the bug. By inspecting http://partkeepr.local/api/project_run_parts/1
I saw that lotNumber
is set in the part inside project, but not set in the toplevel part. Based on this I think it's just a display issue rather than the lotNumber
value disappearing, indeed lotNumber
is copied over inside massRemoveStockAction
of src/PartKeepr/PartBundle/Controller/PartController.php
.
How does the following fix look? https://github.com/partkeepr/PartKeepr/pull/1153
Would be nice to get confirmation that your PR fixes this issue completely!
I tried to implement the changes but it did not seem to have any effect. I only implemented the changes and did a re-run of the /setup page. Do I need to do run any composer commands as well?
I think the cache of the frontend javascript files must be deleted for this change to apply. I just deleted them then reran setup but later I found these commands which may work better https://wiki.partkeepr.org/wiki/Running_PartKeepr_from_GIT#Console_commands
@ed-commits I am a total noob with this environment, so sorry for my stupid questions. But by deleting the frontend javascript cache do you mean running the rm -rf app/cache/*
command ? I have tried this, before runnin the setup, but I am still not able to make it include the lot number in the project runs. Can you provide me with the exact procedure you used to verify the patch so I can reproduce?
I did that, also maybe try rm -rf web/js/compiled
and rm -rf web/js/packages/extjs6
too. then rerun setup. then the change should apply.
@ed-commits I have now tried this as well, and I am unfortuently not able see that the change makes any difference. Are someone else able to confirm that this solves the issue?
I can now confirm that #1153 fixes this issue. Seems like the cache somewhere was reset after a while. However removing compiled and extjs6 is not reccomended. It will brick the whole system, making it stuck in in loading page, and setup page was be left blank. This issue can be closed once the fix is merged to master.
edit: Obs, I now see that the lot number in the project Run will change if the Project changes (under edit-> projects). This is not correct. The Lot number should not be possible to change after a project run. So not linked directly to the project, if that makes sense.
I think the issue is indeed somewhere in the massremovestock action
here: https://github.com/partkeepr/PartKeepr/blob/e39c5f87f9ad44c7b7d4ffb521178f492761320d/src/PartKeepr/PartBundle/Controller/PartController.php#L95
Or rather, that the $removal->lotNumber
field is empty. So more specifially somewhere in the json request
https://github.com/partkeepr/PartKeepr/blob/e39c5f87f9ad44c7b7d4ffb521178f492761320d/src/PartKeepr/PartBundle/Controller/PartController.php#L33
Which I guess is set somewhere here:
https://github.com/partkeepr/PartKeepr/blob/7dd3ef8f2395097b3659bbe0587eac70b6ff7671/src/PartKeepr/FrontendBundle/Resources/public/js/Components/Project/ProjectReportResultGrid.js#L357
Just in case is useful,
I notice the there is some kind of logic problem with the button "Save Project" when importing part into the project.
Once all the process done (read of CSV file, click "Execute Import") successful to add the list of parts to the project, the table ProjectPart is correctly fulfilled, even closing the import window continues to be correct but when you click the "Save Project" button it discharge/revert the changes (?)
at the end of this page is explained how the users circumvent this
https://readthedocs.web.cern.ch/display/PARTK/07a+-+Creating+Projects+and+BOM+Imports
the mention of the "save project" at the beginning of this issue and the behavior described seem similar to what I described.
Regards
Dear JoarGjersund and ed-commits
If I understood correctly when you run http://localhost/web/app_dev.php
https://readthedocs.web.cern.ch/display/PARTK/Setup+for+Debug+and+Verbose+mode
you don't care about the cache, what you execute is done directly.
Regards
Most helpful comment
Hello! I saw this issue on bountysource so I had a look at the code.
I was able to reproduce the bug. By inspecting
http://partkeepr.local/api/project_run_parts/1
I saw thatlotNumber
is set in the part inside project, but not set in the toplevel part. Based on this I think it's just a display issue rather than thelotNumber
value disappearing, indeedlotNumber
is copied over insidemassRemoveStockAction
ofsrc/PartKeepr/PartBundle/Controller/PartController.php
.How does the following fix look? https://github.com/partkeepr/PartKeepr/pull/1153