Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[13.0][ADD]web_duplicate_context #2967

Open
wants to merge 1 commit into
base: 13.0
Choose a base branch
from

Conversation

GuillemCForgeFlow
Copy link

@GuillemCForgeFlow GuillemCForgeFlow commented Oct 17, 2024

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

cc @ForgeFlow

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

@AaronHForgeFlow AaronHForgeFlow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code review 👍

@OCA-git-bot
Copy link
Contributor

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
Copy link
Author

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

@pedrobaeza pedrobaeza added this to the 13.0 milestone Oct 23, 2024
@CarlosRoca13
Copy link
Contributor

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
Copy link
Author

@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
Copy link
Member

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
Copy link
Author

GuillemCForgeFlow commented Oct 23, 2024

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
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants