[13.0][ADD]web_duplicate_context

[GuillemCForgeFlow]

New module which adds a specific key to the context after duplicating a record

cc @ForgeFlow

[AaronHForgeFlow]

Code review 👍

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[GuillemCForgeFlow]

@CarlosRoca13 perhaps this is an interesting addition? If we can get it merged, I can FW it to upper versions.

[CarlosRoca13]

A priori, this makes sense but I have some doubts...

What situation leads you to change the interface when you have duplicated a record?
Have you considered that this context is a very volatile piece of data? This is because when you access the duplicated record again, that context will no longer exist, and therefore, the modifications you make based on it will not be available.

I haven't mentioned anything about using this context in Python since the methods copy and copy_data exist for that purpose.

[GuillemCForgeFlow]

@CarlosRoca13 in my case, this is the solution I have found in order to restrict the edition of a record only after it has been duplicated (as described in the USAGE file), but it can have many other scenarios for which it can be useful.

I'm aware of the copy and copy_data methods, the thing is that when duplicating a record, the action is obtained via the duplicateRecord method on BasicModel.js. It is only in there when it is possible to add this context that can enable then us to have some specifics' behaviors via the Python code.

Have you considered that this context is a very volatile piece of data? This is because when you access the duplicated record again, that context will no longer exist, and therefore, the modifications you make based on it will not be available.

Sure, it is something I have already checked and considered, it is done exactly for this purpose. The idea is to have it removed once you move out of the duplicated record.

I haven't mentioned anything about using this context in Python since the methods copy and copy_data exist for that purpose.

I don't see a way on how I could do this with these methods, as the context comes directly from the action I've mentioned, the context from the copy or copy_data will not be used. Perhaps there's a way to do it?

[pedrobaeza]

The question is not to inject a context, but to model your business logic inside that methods. Which is the business need to require such context? You can intervene such Python methods to perform whatever change you need at business level, and thus, not requiring to inject anything.

[GuillemCForgeFlow]

The question is not to inject a context, but to model your business logic inside that methods. Which is the business need to require such context? You can intervene such Python methods to perform whatever change you need at business level, and thus, not requiring to inject anything.

I see @pedrobaeza. My business case is to only allow users to edit records just after duplicating a record. I don't see another way to detect when the user is in that specific step of the process other than injecting the context which will be returned upon the duplication of the record. This context will be available in the action that has been returned with the duplicated record.

As far I can see, the only way to detect that scenario is via the action context. Perhaps there's another way?

[pedrobaeza]

But that seems awkward to let to change things "only once". If they make any mistake or refresh the tab, they lose the ability to fix any data. It's better to constraint the saving of changed data according certain conditions. Example: on products, there's a protection at write level for not changing the type of the product if there's already some records linked (don't remember right now if sale.order.line or stock.move). If there are no moves, why not allowing the user to change that data?

[GuillemCForgeFlow]

But that seems awkward to let to change things "only once". If they make any mistake or refresh the tab, they lose the ability to fix any data. It's better to constraint the saving of changed data according certain conditions. Example: on products, there's a protection at write level for not changing the type of the product if there's already some records linked (don't remember right now if sale.order.line or stock.move). If there are no moves, why not allowing the user to change that data?

I see, that gave me an idea on how to adjust the logic without the need of this module. Thank you for the feedback 🙂 @pedrobaeza
closing this