Product duplication and account_category

We just realized that since modules/account_product: 7d1e483acac1 the account_category of a product is not duplicated but the default value for the category is used.

I understand that this was done in response to this comment:

https://bugs.tryton.org/issue10269#msg69650

But it looks like a degradation of the UX in many cases, not only because we don’t get the copy the user expects but because the product may be assigned to a completely different category. Would it be reasonable to apply this behavior only when the user is not in the group_account_product_admin group?

Something similar was done for parties but for me is less of a concern given that duplication of parties should be rare.

Indeed there is no default value for account category, so the field will be emptied which sounds like a good solution for me.

I guess your idea is:

  1. If the user is allowed to write on the field, keep the current value
  2. Otherwise use the default value.

That make sense for me, but to be coherent all the restricted fields should behave this way.

Can you point where?

I do not agree. For me having different behavior depending on the access right is not coherent and make the system less predictable for the users. Indeed it is what I already said in Add field access on referential document (#10269) · Issues · Tryton / Tryton · GitLab.

Could you clarify which part are you refering to?

If you refer to:

I think it will be bad to have such random success

I do not think this is random because the user clearly see if he is allowed to write on such field or not . So if he can access we preserve the current value and allow edition or we use the default if the user is not allowed to change such value.

For me it is random because two different users will have different result for the exact same operation.
The typical problem will be that the admin user will tell other user to just duplicate the record because when he has tested that was working but it will not work the other user.

Of course, this is the basis of access rules. Two diferent users can have diferent resutls depending on their access. For me this is expected not random.

For example, writing on the field will have two diferent results (one succeeds and the other fails) due to access rule.

That makes no sense. Following your example: admin user will tell other user to just create the record and set the category because he has tested and was working but creation won’t work for other users :man_shrugging:

Sorry but for me access rule is about access not behavior.

I think you are nitpicking here to compare different behavior with errors.

That’s not a problem because the user will be stopped by the field being read only. So he will know the process was not done completely.

Sorry but I do not understand the difference.

I agree, this is the expected behaviour.

But the problem is in the admin user who will be forced to re-enter the value because it has been cleared without any reason and without any notice. And that what albert says in:

I will not restart the all point that it is a bad behavior because the result depend on the access rules which is not the role of the access rules.

Then why we set the default value when duplicating? As far as I understand we use the default value for fields which are linked to an access rule. So we are already making the result depend on the access rules by updating the values when we know an access rule exist.

Furthermore, if a new access rule is added for another field the plain (without access) user will get an error when writting a value different than the default one. So I’m wondering if we should manage that in a generic way (clearing the value when the users is not allowed to write on it) instead of using a hard coded default for each field.

False. The result is not depending on access rules.

Proof that it is not depend on access rules.

It will be wrong to make it depending on access rules still for the same reason.