Data collection during manufacturing


Its really strange. because I have been following the same steps you mentioned up. I have even opened the link to your of production run demo added a comment, clicked on submit, but when I click on print (button) the comment section shows only “test comment” as value.


I tested again with new production run from scratch, it seems to work only for the very first comment, and no matter what is entered again in the comment field, it does not take it into consideration meaning if a mistake is made, it cant be edited. I think if the field is made to hold the data and allow provision for editing it will be great.

This other one is just an aside, I dont seem to find the file displaying the header of the part of print


I fixed the production run task comment update. It’s currently available in our demo server. It will be also available in our public repo soon, hopefully today.

Check framework/common/widget/CommonScreens.xml > SimpleDecorator screen definition, you’ll find all the fo.ftl files used to build the header, mainly used in PDF.


Thanks Minifreak, You have been very helpful thanks, waiting for the commit.
Is there a proper chanel to signal other bug issues or I can through github like pagination employees ?
Do I also follow the same proceedure to display the worker field just below the comment ?


You can report issues through Github and even provide merge-requests if you want. We will appreciate it a lot. What do you mean by pagination employees?

For the worker field, should be similar. Have in mind that what you’ll get is the partyId so if you want something more user friendly (ie: his/her real name + surname) you may need to use some PartyWorker/PartyHelper utility method in order to get it.


Ok when you post the commit, I will try to use similar method for the partyId of worker.

About the employees pagination, Just noticed that when user of this page become more than 20, the next page to display the rest of the users remains blank. You can reproduce the issue by creating more that 20 users.


Oh, ok. In this case better open a new ticket in the forum or an issue at Github. I’d be more inclined for the latter since it is a bug, apparently.


Since many users can work on the same production run for different tasks, how to display the user that completed that particular task? meaning when printing it shows the users that completed the particular task.

I will signal the other bug issues directly on github as you proposed


Hi did get to this commit. Thanks and update on other issue?


Hey Maximillian,

I’ll take a look next week, let’s see if it can covered. I am not 100% sure I will be able to add more info to the existing tasks table without implying a layout overhaul. On the other hand, we are about to release version 1.14.5, so we are considerably busy these days.


Hello M,
Ok thanks, expecting to hear from you soon.


Hey Maximillian,

I’ve just committed a fix for the worker (party) stuff for production run tasks. You’ll see that now the worker field has been converted to a lookup so you will be able to search in a more convenient way. The most substantial change though, is the addition of a role dropdown which is something I had to do in order to accommodate the actual data model. In other words, the data model already expected a production run task party assignment (see WorkEffortPartyAssignment entity) and that entity also expects a role. I’ve restricted the roles to be EMPLOYEE and its children because I see no reason to allow the rest for production run tasks. If you find roles missing for your need you’ll have to add them manually.

Hopefully my changes will be available to you soon, probably this evening or tomorrow so if you have the chance, I’d appreciate any input you can provide.


I checked out the commits and must say the printout out makes more sense now and more helpful. thanks

I have other proposals based on real scenario of productions still for Manufacturing module. You can check and see if they are helpful, but I think they are

  1. Asides selecting the worker as lookup which is very good, there can be a possibility of instead using but the user login as worker and current worker as supervisor if it applies, that way user wont be able select a different worker (we consider that a user can complete one task while another user completes another task which should reflect in the printout during production.)
  2. The possibility of printing out work efforts schedules that show on the calendar
  3. It is also necessary to display manufacturing date(end of a production, this is already there as actual completion time) and the expiry date entered manually possibly beside the “Production run and produce section” for the last task, this two dates can automatically be added to to the inventory when produced product is sent to inventory immediately after production.
  4. You also mentioned that the data model expects a production run task party assignment, but it is found only in the work effort in the work effort module not in the routing task area of production, which can be very confusing to the user doing production, given that he might have not been the one who created roles. You could leave it but make it optional, because now shows error when not well matched.

Thanks. Let me know what you think as I will continue exploring exploring.


Hey Maximillian,

  1. I am not sure I am following here. If I am not mistaken, depending on the role, an user wouldn’t be able to assign a different user. So only users with the right permissions are allowed to do so. In any case, what you are saying here is probably business specific although I should take a much deeper look in order to give you a better input. If you can elaborate a bit more, that would be really helpful.

  2. That sounds good to me. Added it to the wish-list for any upcoming release (either 1.14.5 or 1.14.6)

  3. You mean to set those dates automatically once all production run tasks are completed? I’ll double check, but I think it is working like that already.

  4. You are right. I noticed that it could be confusing. My plan is to load only the roles that the selected worker has. I didn’t do it yet due to technical reasons (minilang makes things hard in that regard). Another thing noted for upcoming releases.

Thanks a lot for your input!


I am happy you saw them, an sorry for this late reply, actually i was not seeing your reply and just saw it today.
For the points you mentioned.

  1. Here I mean that, instead of selecting worker, lt could instead populate with the actual signed in user.
    Such that if user 1 runs task 1 and user 1 runs task 1, the prints will actually show user 1 for task 1 and user 2 for task two during printing. The lookup can still be there as another optional field in case a user wants to select another worker. Main issue is the report should be able to show the user that executed the task and the other worker that was selected separately. My humble opinion, applies to most scenarios but its just an opinion that i think could be better if you consider.
  2. The dates here are not automatic, because after production user needs to go to inventory before setting dates again meanwhile, dates could be set in production process and automatically potted to inventory without even the user noticing upon completion of production run. Here a field called expiry date could be added in the production run process.