User can't indicate in the sanity report or gcode who created the CAM job independently of who created the CAD file.

[Connor9220]

User can't indicate in the sanity report or gcode who created the CAM job independently of who created the CAD file.

[sliptonic]

The FreeCAD document has a created-by property as well as a changed-by property.

The document author gets set automatically if the fields are populated in preferences:

I've been unable to make the 'updated by' field change and I've never seen anyone talk about it on the forum or use it.

The proposed change is minor and I think it's a good idea. But since document author/changed by doesn't seem to be widely used, it's worth thinking it through to make sure we have a good and desirable feature.

I don't think the field should be added to the job task panel. Author data for the whole document is only accessible from the property pane so putting the job author data there would be consistent. DWG can weigh in on this though.

If you want the data to be available to postprocessors, the buildpostables method can be updated to get it from the job and insert a new postable populated with gcode comments. Then the post-processor can handle it appropriately. Either ignoring or writing it out.

Some questions:

Is "Job Author" an industry-accepted term? I've heard the term "CAM Programmer" used. Same thing?

Should the 'Job Author' get populated automatically? When? When the document is saved or when the job is created?

Should we update the 'Job Author' if the document is saved again or the Job is changed?

If the job is created by person A and later edited by person B, should the job author be 'A' or 'B' after the change? What if 'B' isn't populated in preferences? If the Job Author should update on change, what changes would trigger it?

Specific things I see that need to be done

• Add the property to the job object on creation.
• Add logic to make sure the property is added to legacy documents when opened.
• Add logic to read the author data from preferences and populate the property at the correct time.
• Edit the Sanity template to display the data
• Edit the sanity report logic to pull the data from the job and send it to the report generator
• Edit the buildPostables method to get the data to the postprocessors

[Connor9220]

I don't think the field should be added to the job task panel. Author data for the whole document is only accessible from the property pane so putting the job author data there would be consistent. DWG can weigh in on this though.

I would advocate that it DOES belong at the job task panel. Because, you can have multiple jobs within a single document, and you may have different people doing the cam work. I think it should follow the job object around.

Is "Job Author" an industry-accepted term? I've heard the term "CAM Programmer" used. Same thing?
I originally used CAM Author, But CAM Programmer looks to be industry term. In my POC, I started off with CAMAuthor in the code, but found that it didn't automatically add the space in the panel, and switched to Job Author. CAM_Programmer probably should be used and hopefully it'll replace the underscore with a space appropriately.

Should the 'Job Author' get populated automatically? When? When the document is saved or when the job is created?
If it get's populated automatically, I would advocate that it does it on save only if the 'Job Author' is blank.

Should we update the 'Job Author' if the document is saved again or the Job is changed?
If the field is already filled out, I think it should be left alone.

If the job is created by person A and later edited by person B, should the job author be 'A' or 'B' after the change? What if 'B' isn't populated in preferences? If the Job Author should update on change, what changes would trigger it?
I think that's up to the person editing at that point. That's a procedural thing for them to figure out.

Specific things I see that need to be done

• Add the property to the job object on creation.
• Add logic to make sure the property is added to legacy documents when opened.
  These have been coded already in my POC.

[sliptonic]

It does follow the job object. It would be a property of the job. That doesn't mean it needs to be in the task panel. There are, in fact, a lot of properties of jobs and ops that we don't expose through task panels. The guiding principle is to keep the task panels as lean as possible and focused on the controls that most users use most of the time. The property pane exposes everything and functions as an 'advanced' features tool.

Most people won't use an author field at all. Those that do use it won't need to edit it very often. It can even be set automatically and never require the user to edit it directly.

That's why it shouldn't be in the task panel. In the panel, everyone has to look at it every time they edit a job. It takes up screen real estate and adds cognitive load.

The property would appear here and be editable.

[Connor9220]

It does follow the job object. It would be a property of the job. That doesn't mean it needs to be in the task panel. There are, in fact, a lot of properties of jobs and ops that we don't expose through task panels. The guiding principle is to keep the task panels as lean as possible and focused on the controls that most users use most of the time. The property pane exposes everything and functions as an 'advanced' features tool.

OKay, sorry, I miss-understood about the placement.

Most people won't use an author field at all. Those that do use it won't need to edit it very often. It can even be set automatically and never require the user to edit it directly.

That's why it shouldn't be in the task panel. In the panel, everyone has to look at it every time they edit a job. It takes up screen real estate and adds cognitive load.

I had placed it on the General Tab under the Job Title, I don't think it took too much away from this page.. But, leave that up to whoever. See Screen shots below.