[FIX] delivery: always permit pack weight compute #164677
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ethanrobv
force-pushed
the
15.0-opw-3813917-multi-company-access-package-records-in-use-etvi
branch
from
6deea52
to
e9ac905
Compare
**Current behavior:**
In a multi-company environment, say we have a reusable box which
has been used by multiple companies. While the box actively
contains some product of companyA, companyB is not permitted to
view their own stock transfers.
**Expected behavior:**
The current status of a package should not affect the
accessibility of a company's picking history.
**Steps to reproduce:**
1. Setup 2 companies, for both:
Enable packages
Enable stock warehouse locations
Enable multi-step routes
Set their in/out routes to 3-step (pick, pack, ship)
2. Create a reusable box type package, don't assign it to
either company
3. In CompanyA, create a delivery using the reusable package and
complete it so the package is fully emptied and ready to be
reused
4. Switch to CompanyB, create a picking (any kind) using the
same reusable box -don't finish the transfer- then switch
back to CompanyA
5. Try to view Inventory transfers -> AccessError
**Cause of the issue:**
The delivery module adds the `_compute_shipping_weight()` method
which is called on-demand when we try to open the transfers tree
view. We will eventually look at packages from the picking that
used the reusable package (which now 'belongs' to another
company) and raise the AccessError.
**Fix:**
Use sudo() to read package records in the iteration over picking
records.
We are only reading from pickings which belong to the current
company, which makes the access check for the package records
redundant (and as we see here problematic).
opw-3813917
ethanrobv
force-pushed
the
15.0-opw-3813917-multi-company-access-package-records-in-use-etvi
branch
from
e9ac905
to
77850cb
Compare
|
|
|
robodoo r+ |
robodoo
pushed a commit
that referenced
this pull request
May 23, 2024
**Current behavior:**
In a multi-company environment, say we have a reusable box which
has been used by multiple companies. While the box actively
contains some product of companyA, companyB is not permitted to
view their own stock transfers.
**Expected behavior:**
The current status of a package should not affect the
accessibility of a company's picking history.
**Steps to reproduce:**
1. Setup 2 companies, for both:
Enable packages
Enable stock warehouse locations
Enable multi-step routes
Set their in/out routes to 3-step (pick, pack, ship)
2. Create a reusable box type package, don't assign it to
either company
3. In CompanyA, create a delivery using the reusable package and
complete it so the package is fully emptied and ready to be
reused
4. Switch to CompanyB, create a picking (any kind) using the
same reusable box -don't finish the transfer- then switch
back to CompanyA
5. Try to view Inventory transfers -> AccessError
**Cause of the issue:**
The delivery module adds the `_compute_shipping_weight()` method
which is called on-demand when we try to open the transfers tree
view. We will eventually look at packages from the picking that
used the reusable package (which now 'belongs' to another
company) and raise the AccessError.
**Fix:**
Use sudo() to read package records in the iteration over picking
records.
We are only reading from pickings which belong to the current
company, which makes the access check for the package records
redundant (and as we see here problematic).
opw-3813917
closes #164677
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This was referenced May 23, 2024
|
@ethanrobv @Whenrow this pull request has forward-port PRs awaiting action (not merged or closed): |
lohwswilson
pushed a commit
to lohwswilson/odoo
that referenced
this pull request
Jun 3, 2024
**Current behavior:**
In a multi-company environment, say we have a reusable box which
has been used by multiple companies. While the box actively
contains some product of companyA, companyB is not permitted to
view their own stock transfers.
**Expected behavior:**
The current status of a package should not affect the
accessibility of a company's picking history.
**Steps to reproduce:**
1. Setup 2 companies, for both:
Enable packages
Enable stock warehouse locations
Enable multi-step routes
Set their in/out routes to 3-step (pick, pack, ship)
2. Create a reusable box type package, don't assign it to
either company
3. In CompanyA, create a delivery using the reusable package and
complete it so the package is fully emptied and ready to be
reused
4. Switch to CompanyB, create a picking (any kind) using the
same reusable box -don't finish the transfer- then switch
back to CompanyA
5. Try to view Inventory transfers -> AccessError
**Cause of the issue:**
The delivery module adds the `_compute_shipping_weight()` method
which is called on-demand when we try to open the transfers tree
view. We will eventually look at packages from the picking that
used the reusable package (which now 'belongs' to another
company) and raise the AccessError.
**Fix:**
Use sudo() to read package records in the iteration over picking
records.
We are only reading from pickings which belong to the current
company, which makes the access check for the package records
redundant (and as we see here problematic).
opw-3813917
closes odoo#164677
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
fw-bot
deleted the
15.0-opw-3813917-multi-company-access-package-records-in-use-etvi
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Current behavior:
In a multi-company environment, say we have a reusable box which has been used by multiple companies. While the box actively contains some product of companyA, companyB is not permitted to view their own stock transfers.
Expected behavior:
The current status of a package should not affect the accessibility of a company's picking history.
Steps to reproduce:
Setup 2 companies, for both:
Enable packages
Enable stock warehouse locations
Enable multi-step routes -> set their in/out routes to 3-step (pick, pack, ship)
Create a reusable box type package, don't assign it to either company
In CompanyA, create a delivery using the reusable package and complete it so the package is fully emptied and ready to be reused
Switch to CompanyB, create a picking (any kind) using the same reusable box -don't finish the transfer- then switch back to CompanyA
Try to view Inventory transfers -> AccessError
Cause of the issue:
The delivery module adds the
_compute_shipping_weight()method which is called on-demand when we try to open the transfers tree view. We will eventually look at packages from the picking that used the reusable package (which now 'belongs' to another company) and raise the AccessError.Fix:
Use sudo() to read package records in the iteration over picking records.
We are only reading from pickings which belong to the current company, which makes the access check for the package records redundant (and as we see here problematic).
opw-3813917