OCA
[16.0][IMP] purchase_security: add is_restricted option
This PR adapts the functionality of this PR https://github.com/OCA/purchase-workflow/pull/1866 to purchase_security.
@qrtl
Hi @pilarvargas-tecnativa, some modules you are maintaining are being modified, check this out!
@AungKoKoLin1997 Do you think it's really a good idea to combine the modules into one? I fail to see the point of doing so as the use cases are independent from each other, IMO.
Do you think it's really a good idea to combine the modules into one? I fail to see the point of doing so as the use cases are independent from each other, IMO.
My rationale for adding the is_restricted feature directly to the purchase_security module is rooted in its inherent security nature. Given that both functionalities revolve around enhancing security, it felt more streamlined and intuitive to consolidate them under one module. This way, users can access all related security features without the need to manage multiple modules.
I suggested also to join both in the same module, for 2 reasons:
- Technically, for avoiding incompatibilities between them.
- Functionally, for the reasons stated by @AungKoKoLin1997.
@pedrobaeza I have a concern. Is it a good design choice to keep all security functionalities related to purchase in the purchase_security module? If new purchase security features are proposed to OCA later, the module might become larger and harder to maintain. I believe each functionality should have its own separate module, but we also need to consider compatibility issues. I am not sure if excluding modules in CI for each purchase security-related concern is the best approach. What's your opinion?
Doing the exclusion thing in the CI is a total pain, increasing the build time, not knowing when weird things like POT generation starting to fail, so I don't like it.
For now, there's no other features planned for the security, so let's keep it together. If tomorrow another feature arises, then the discussion opens it again to split or not.