Friday, May 24, 2024
4 changes
2 changes
Enhancements to existing features
Appointment setup screens now use clearer wording and controls to distinguish recurring appointments from one-time bookings. Confirmation pages have been redesigned so customers can more easily see appointment status, calendar options, video meeting access, and cancellation guidance.
Original PR description
Improve the appointment type form view design by: - Rewording fields - Adding 2 new radio buttons to better distinguish the recurring and the punctual appointment type categories. The 2 buttons switching between showing the max schedule date field (recurring) and the daterange widget (punctual). Improve the appointment validation template by: - Removing the "Schedule another" button - Moving the "Google Agenda", "Add to iCal/Outlook" buttons under the appointment date so that users best spot them as they were often forgotten at the bottom of the page. - Hiding the videoconference link in the provider's name and add a copy button for convenience. - ... For more details see commit messages Task-3877550
Products are now presented with a clearer goods type and a separate option to track inventory, replacing the older storable product category. This makes product setup easier to understand and ensures inventory tracking options only appear when relevant.
2 changes
Resolved issues and error corrections
This fix ensures that the request stack is properly cleaned up even when errors occur during request initialization. Previously, if an error happened during the request setup process, the system could be left in an inconsistent state, causing unrelated requests to fail with missing session information. This change prevents those cascading failures by guaranteeing proper cleanup in all scenarios.
Original PR description
Original PR description
**In this commit we have adapted the changes for the following improvement:** - The detailed_type 'storable product' is removed and instead we add a Boolean field to track inventory. - The tracking field should be visible only after the boolean field to track inventory is enabled **Task**: 3526304
**Impacted versions:** - 17.0 - 16.0 **Description of the issue/feature this PR addresses:** The addition of `request._post_init()` in #104573, introduced the possibility that `_request_stack.pop()`…
**Impacted versions:** - 17.0 - 16.0 **Description of the issue/feature this PR addresses:** The addition of `request._post_init()` in #104573, introduced the possibility that `_request_stack.pop()` is not called after `_request_stack.push(...)` was called before. This would happen in the case if request._post_init() raised an Exception. Even though with the standard `SessionStore` this is extremely unlikely to happen the possibility remains. In any case, one shouldn't set the expectation that `request._post_init()` isn't allowed to raise, therefore by moving the function call into the try block, it makes sure that `_request_stack.pop()` is called in the finally block. **Current behavior before PR:** If `request._post_init()` raises an Exception, `_request_stack` is left in a polluted state. This can cause issues during RPC-Calls, since during an RPC-Call, the request in `_request_stack` is borrowed with the expectation that `_request_stack` is empty. This can cause issues further down the line for completely separate requests which may break here: https://github.com/odoo/odoo/blob/4b6dea23a04d7b5317a94e75c8a670de82762276/odoo/addons/base/models/ir_qweb.py#L879 It breaks because, `request` will not be `None` (as would be expected due to borrowing) but `session` is not set on the `Request` object since that only happens if `_post_init()` succeeds. This results in the following error for completely unrelated requests going forward: ``` AttributeError: 'Request' object has no attribute 'session' ``` As a side-note, in our environment this happened likely due to using [camptocamp/odoo-cloud-platform/session_redis](https://github.com/camptocamp/odoo-cloud-platform/tree/16.0/session_redis). I did a write-up of the specific issue I ran into myself and reproduction steps here: https://gist.github.com/Jenjen1324/81d3547e5713ba253b67970bc8388147 I'm also not sure if there might be any security implications leaving a *partially* constructed object in this stack. **Desired behavior after PR is merged:** It is no longer possible to have a broken request hanging on in `_request_stack`, be it in stock Odoo or with customizations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166524
This fix resolves an issue where users in one company couldn't view their own inventory transfers when a reusable shipping package was being used by another company. The problem occurred because the system was incorrectly checking access permissions on shared packages when calculating shipping weights. Now the system properly allows companies to view their own transfer history regardless of which packages are in use elsewhere.
Original PR description
**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…
**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
Forward-Port-Of: odoo/odoo#166575
Forward-Port-Of: odoo/odoo#164677