1 ACCEPTED SOLUTION
Accepted Solutions
Hi Jens,
there seems to be a difference between the "copy item" and "create related item" function.
When using "copy item", the "copy fields" (that can be defined per Type) are used to limit the amount of copied field values.
When using "create related item" (at least in your setup) there is always the checkbox to "copy common fields" in the upcoming dialog.
This seems to do exactly what it says: It's an all or nothing option to either copy nothing at all (unchecked) or to copy all common fields, independent of the type setup (checked).
To some extend this behavior makes sense, but I understand you problem 
We have a comparable usecase and solved it using a pre-trigger that simple removes all field values on the newly created item we do not want to be copied (e.g. a comment field).
Unfortunately this does only work after the user "reviewed "the new item and clicked apply (which fires the trigger event).
The users may be confused to see some fields value that are not actually stored afterwards.
Thinking of it, there might be a solution to this using constraints based on the "unspecified" state....
HTH Matthias
Hi Jens,
there seems to be a difference between the "copy item" and "create related item" function.
When using "copy item", the "copy fields" (that can be defined per Type) are used to limit the amount of copied field values.
When using "create related item" (at least in your setup) there is always the checkbox to "copy common fields" in the upcoming dialog.
This seems to do exactly what it says: It's an all or nothing option to either copy nothing at all (unchecked) or to copy all common fields, independent of the type setup (checked).
To some extend this behavior makes sense, but I understand you problem
We have a comparable usecase and solved it using a pre-trigger that simple removes all field values on the newly created item we do not want to be copied (e.g. a comment field).
Unfortunately this does only work after the user "reviewed "the new item and clicked apply (which fires the trigger event).
The users may be confused to see some fields value that are not actually stored afterwards.
Thinking of it, there might be a solution to this using constraints based on the "unspecified" state....
HTH Matthias
Hi Matthias,
again you saved my day, and this time the solution is that simple: i really missed the option "copy common fields". I really didnt recognize it
That any trigger just can work after the apply-button is clicked, is a problem to us too. We spoke to our PTC-consultants (and opened a RfC for this) that we want to have some more direct reactions by the system (i.e when a field is changed that another field gets a new value or such things), but there is not much hope that such a RfC will ever be fulfilled...
Thanks, Jens
Hi Michael, Hi Matthias,
we're using 10.4 at the moment and will switch to 10.5 in the next weeks.
Our wishes for more direct reactions are not just field values depending on values of other fields (this example was too simple ). Some other things we want to have are:
- running computations without "apply": we have a date-field, and a field which shows the weeknumber of the date. This works with a computation, but you have to click at "apply" first.
- dynamic change of field-size: we want to have the possibility to change dynamically the size of a long text field from 5 to 25 lines for editing.
- we want to have action buttons inside the form, and a click at these action button should start an action (just like a custom action), but with a dependency to the values which are in the form, but not yet in the database.
- ...
But i think, this is subject of another discussion, and some of these points are listed as RfC already.
kind regards, Jens
