Error duplicating products

[JonatanGk (Jonatan)]

Hi,
I have restricted access to a product field to a certain group. When I try to duplicate the product with read-only access user, it gives me an error just in that “field”. I have created default for that field without success, same error.

I’ve also seen something similar being talked about in:

Product duplication and account_category

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 (clear…

Add field access on referential document (#10269) · Issues · Tryton / Tryton...

But I can’t see a solution.

I would greatly appreciate help in this regard since being able to duplicate products for the rest of the staff would be of great help.

Thanks in advance

[pokoli (Sergi Almacellas Abellana)]

It will be great to know which version are you working on because it may alter the behaviour of the system. Also it will be great if you can give more info about the field usage and why you added the restriction for some users.

@JonatanGk

When I try to duplicate the product with read-only access user, it gives me an error just in that “field”.

With Manage copy record with access right limitation on some fields (#10536) · Issues · Tryton / Tryton · GitLab it will only raise the error if the user changed the default value. This makes sense because the user is writing a value to a field that he is not allowed to do so.

Prior to this issue, tryton will raise an error on each write because the user is not allowed to write on the field.

[ced (Cédric Krier)]

@pokoli

With Issue 10536: Manage copy record with access right limitation on some fields - Tryton issue tracker it will only raise the error if the user changed the default value.

So this can be avoided by extending ModelStorage.copy to reset the default value for the specific field.

[JonatanGk (Jonatan)]

I’m using Tryton 5.2. The field is a “deprecated” Boolean required. I have and a GROUP responsable from deprected products and others and only they can modify this field.

@pokoli

With Issue 10536: Manage copy record with access right limitation on some fields - Tryton issue tracker it will only raise the error if the user changed the default value. This makes sense because the user is writing a value to a field that he is not allowed to do so.

Im tryting to do a backport but the problem persist when im trying to duplicate.

[ced (Cédric Krier)]

@JonatanGk

I’m using Tryton 5.2

This is clearly not supported by this very old series.

@JonatanGk

Im tryting to do a backport but the problem persist when im trying to duplicate.

It is probably better to upgrade because this feature is probably based on many others.

[pokoli (Sergi Almacellas Abellana)]

@JonatanGk

The field is a “deprecated” Boolean required. I have and a GROUP responsable from deprected products and others and only they can modify this field.

So in your case, any user that is not responsible of the deprecated products can not modify this field.

The best will be to upgrade to a 6.2 series (where the new behaviour is already available) and set the deprecated flag to false when duplicating records.

That should fix your issues.

[JonatanGk (Jonatan)]

thx @ced & @pokoli

We had in mind to do that update in a ““short time””.
Some trick to do this UPGRADE? since there are several versions and it is a bit scary since we have the corporate information as you can imagine

[pokoli (Sergi Almacellas Abellana)]

@JonatanGk

Some trick to do this UPGRADE?

There is no trick for the upgrade. Just have a look at the migration topics
for all the series, upgrade your code, run the database upgrade and do some test on a non production environment before going live.

We normally try to clean obsolete code and reduce the number of custom modules (if you have some) when doing some upgrade process.

[JonatanGk (Jonatan)]

Hi again, returning at UPGRADE TOPIC i have a requirement soon to do some API Endpoint to do some job. I see that Tryton 6.0 / 6.2 works with werkzeug 2.0 and i dont kwow if that upgrade that we talk can be better to do after/before now that know that explianed new needs.

Thanks in advance

[pokoli (Sergi Almacellas Abellana)]

The upgrade should not produce any difference on the API enpoint behaviour.
I will say the soon you do the upgrade the less issues you will have.