[16.0][IMP] edi_oca: add smart button in record form to show all related queue jobs

OCA / edi-framework

GNU Affero General Public License v3.0

6 stars 26 forks source link

[16.0][IMP] edi_oca: add smart button in record form to show all related queue jobs #93

Open QuocDuong1306 opened 1 month ago

QuocDuong1306 commented 1 month ago

This PR adds a smart button in record form to show all related queue jobs

Depend on:

https://github.com/OCA/edi/pull/1004

OCA-git-bot commented 1 month ago

Hi @etobella, @simahawk, some modules you are maintaining are being modified, check this out!

QuocDuong1306 commented 2 weeks ago

Hello @simahawk , I updated as you suggested, could you have a look?

QuocDuong1306 commented 2 weeks ago

Hi @simahawk , I pushed 1 fixup commit for cases:

Assume that DB has already installed edi_sale_oca, edi_stock_oca, edi_product_oca, edi_partner_oca.. . On their form (sale.order, stock.picking, product.template,...) will limit the access right because their group was not implied base_edi.group_edi_user to read records on edi.exchange.consumer.mixin (big problem because of breaking flows and tests)

I suggest that:

Keep creating access rights to EDI stack for base.group_user, but should create read queue.job permission for base_edi.group_edi_user, for that edi user can access to edi.exchange.record form (not accepted for base.group_user)

Ex: Break when accessing to res.partner if users have not implied edi user group

simahawk commented 2 weeks ago

Hi @simahawk , I pushed 1 fixup commit for cases:

Assume that DB has already installed edi_sale_oca, edi_stock_oca, edi_product_oca, edi_partner_oca.. . On their form (sale.order, stock.picking, product.template,...) will limit the access right because their group was not implied base_edi.group_edi_user to read records on edi.exchange.consumer.mixin (big problem because of breaking flows and tests)

I suggest that:
* Keep creating access rights to EDI stack for `base.group_user`, but should create read `queue.job` permission for `base_edi.group_edi_user`, for that edi user can access to `edi.exchange.record` form (not accepted for `base.group_user`)
Ex: Break when accessing to res.partner if users have not implied edi user group

Can't we have a migration step to fix this? If not, let's go as you propose but we should some how log a deprecation.

nilshamerlinck commented 1 week ago

Hi @simahawk do you agree with these levels of access:

(1) Internal User: might be an EDI user without even knowing about it, triggering EDI flows by some of his actions on business records; does not need access to related queue jobs
(2) (new) EDI User: more conscious EDI user that might sometimes need to debug things a bit further and thus needs access to related queue jobs
(3) EDI Manager: full configuration access

If yes, then this PR does not introduce any change, just implements (2)

simahawk commented 1 week ago

Hi @simahawk do you agree with these levels of access:

* (1) **Internal User**: might be an EDI user without even knowing about it, triggering EDI flows by some of his actions on business records; does not need access to related queue jobs

* (2) (new) **EDI User**: more conscious EDI user that might sometimes need to debug things a bit further and thus needs access to related queue jobs

* (3) **EDI Manager**: full configuration access

If yes, then this PR does not introduce any change, just implements (2)

@nilshamerlinck thanks for the summary! I'm ok w/ this then. @QuocDuong1306 could you please add this info somewhere? Maybe a section "Jobs" in "CONFIGURE.rst" is appropriate. @etobella could you please pass by for a review?

QuocDuong1306 commented 1 week ago

Hello @simahawk , the PR is updated

OCA-git-bot commented 1 week ago

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). 🤖

MiquelRForgeFlow commented 1 week ago

conflicts