Wednesday, March 6, 2024
14 changes · saas-17.1
Enhancements to existing features
This update enhances website accessibility by addressing warnings related to missing ARIA labels and meta descriptions. It adds necessary ARIA attributes and default meta descriptions to improve user experience and SEO, ensuring compliance with accessibility standards.
Original PR description
[IMP] website: add an aria-label on the extra item anchor The goal of this commit is to add an `aria-label` attribute on the "extra item" anchor in order to improve the accessibility of the website…
[IMP] website: add an aria-label on the extra item anchor The goal of this commit is to add an `aria-label` attribute on the "extra item" anchor in order to improve the accessibility of the website pages and avoid a warning of type `Links do not have a discernible name`. However, as the logic responsible of the creation of this anchor is in a non lazy loaded file, the translate function `_t()` (located in a lazy loaded file) can not be used to translate the value of the `aria-label` attribute. To solve the problem, this value has been put in the `data-extra-items-toggle-aria-label` attribute on the header. The translated value is then extracted and added in the `aria-label` attribute at the extra items button creation. ------------------------------------------------------------------------------------------------------------------------------------------------------------------ [IMP] website: add a default meta description on website pages The goal of this commit is to add a default meta description on website homepage and "contact us" page in order to improve their SEO and avoid a warning of type `Document does not have a meta description`. ------------------------------------------------------------------------------------------------------------------------------------------------------------------ [IMP] website: add an aria-controls attribute on accordion tab elements In order to improve the accessibility of the website pages, an `aria-controls` attribute has been added on `tab` elements of the "Accordion" snippet to avoid a warning of type `Elements with an ARIA [role] that require children to contain a specific [role] are missing some or all of those required children`. Indeed, as explained in [the tab role documentation]; "An element with the `tab` role should contain the `aria-controls` property identifying a corresponding `tabpanel` (that has a `tabpanel` role) by that element's `id`". The `_createIDs()` method has been adapted in order to handle the update of the `aria-controls` attribute at the update of the `tabpanel` id. [the tab role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/tab_role#description ------------------------------------------------------------------------------------------------------------------------------------------------------------------ [IMP] website, *: add aria-label on social media anchors *: website_hr_recruitment In order to improve the accessibility of the website pages, an `aria-label` attribute has been added on some social media anchors to avoid a warning of type `Links do not have a discernible name`. The `options.js` file has also been adapted in order to correctly set the `aria-label` attribute of added social media anchors. ------------------------------------------------------------------------------------------------------------------------------------------------------------------ [IMP] *: improve accessibility of website pages *: base_import, gamification, hr_skills, mass_mailing, portal, portal_rating, survey, web, web_editor, website, website_sale, website_slides The goal of this commit is to improve the accessibility of the website pages. This has been made by implementing and correcting ARIA (Accessible Rich Internet Applications) roles and attributes. More precisely: - An `aria-label` attribute has been added on progressbar elements to avoid a warning of type `ARIA progressbar elements do not have accessible names`. It has also been added on iframes to avoid a warning of type `<frame> or <iframe> elements do not have a title`. Furthermore, `aria-label` has been incorporated on some anchors to avoid a warning of type `Links do not have a discernible name`. Finally, it has been added on elements that have the `dialog` role to avoid a warning of type `Elements with role="dialog" or role="alertdialog" do not have accessible names` and on elements that have the `listbox` role to avoid a warning of type `ARIA input fields do not have accessible names`. - To avoid a warning of type `Some ARIA parent roles must contain specific child roles to perform their intended accessibility functions`, `role="menuitem"` has been added on children of menu elements. As explained in [the menuitem role documentation], "The `menuitem` role indicates the element is an option in a set of choices contained by a `menu` or `menubar`". To avoid this warning, `role="presentation"` has also been added on elements located between `tablist` and `tab` and between `menu` and `menuitem`. Indeed, as explained in [the presentation role documentation]; "The `presentation` role removes an element's implicit ARIA semantics from being exposed to the accessibility tree". The goal is to inform the assistive technologies that the default semantics of the element should be ignored. Finally, to avoid this same warning, the `option` role has been added on elements to identify selections a user can make in a `listbox`. - The `aria-label` of some elements has been adapted in order to avoid a warning of type `Elements with visible text labels do not have matching accessible names`. - The value of `aria-disabled` has been corrected to `true` (instead of `disabled`) (see [the aria-disabled documentation]). Still to improve the accessibility of the website pages, an alternative text (`alt`) attribute has been provided for images. [the menuitem role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/menuitem_role [the presentation role documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/presentation_role [the aria-disabled documentation]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-disabled#values Forward-Port-Of: odoo/odoo#140453
This update introduces tags to Odoo accounts, improving clarity and user control over financial data. Previously, a complex mapping was used for reporting, but this change simplifies the process and aligns with best practices for Luxembourg accounting requirements. This enhances reporting accuracy and flexibility.
Original PR description
In this commit we will adds tags to some accounts. The tags added correspond to a mapping that was added in this PR: https://github.com/odoo/enterprise/commit/81c427ba1a505e1e9d4a64dd6227bbb747214142 This mapping was useful to separate the tax and net amount and then use it in the appendix A of the annual report. We decided the use tags instead of this mapping so that it's clearer for the users and to give control to them. task: 3646832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149752
Resolved issues and error corrections
PDF files in the Documents app that use a specific encoded file type will now generate and show thumbnails as expected. This makes it easier for users to visually identify documents without opening each file.
Original PR description
Steps to reproduce =================== - Open the documents module. - thumbnail of the some pdfs are not displayed. Technical =================== As we made some changes https://github.com/odoo/enterprise/pull/49111 here related to thumbnail thumbnail_status for the 'application/pdf;base64' type pdfs are set to be false instead of 'client_generated'. After this PR =================== thumbnail for the 'application/pdf;base64' mimetype pdfs will be generated. Task-3753929
The Salary Configurator now keeps the correct employee structure type when generating an offer. This prevents missing benefits and avoids an error that could block recruitment users from preparing salary offers.
Original PR description
Issue: - When we open the Salary Configurator, the employee structure type is set in the contract. Then, a new employee is created and the structure-type employee is replaced by `United States: Employee`. - _get_salary_package_values() does not get any benefits because the structure type of the contract is `United States: Employee`. - ROLLBACK the transaction, so the structure type is an employee instead of `United States: Employee`. - Salary_package/update_salary method inside get `holidays` benefits because search with employee structure type This commit led to the issue -issue.https://github.com/odoo/odoo/commit/e0a739897e170c5f08c1cf4ca3a98638ad664027 task-3740939
This update resolves an issue where branch accounts weren't correctly recognized for payment processing. The fix allows branches to use their own accounts for point-of-sale transactions, streamlining financial management and ensuring accurate record-keeping. This improves the flexibility and usability of the accounting and point-of-sale modules.
Original PR description
Steps to reproduce: - Install point of sale and accounting - Create a branch - Make a copy of the outstanding receipts account and change company to the branch - Attach the branch to this account in the accounting settings - Open a PoS make a transaction and close the session Issues: An error is displayed notifying the user that the journal entry draft is not valid. Solution: Accounts that are attached to a branch should be valid for them as well as their parents account. Task link: https://www.odoo.com/web#model=project.task&id=3659707 opw-3659707 Forward-Port-Of: odoo/odoo#148810
This update resolves an issue where coupon codes applied to a shopping cart were not being correctly removed. The fix addresses a technical glitch where a temporary order line was created when a coupon was applied, preventing its removal. This ensures users can accurately manage their shopping carts and discounts.
Original PR description
## Steps to reproduce - Install **eCommerce** app - Go to **Settings** and enable **Discounts, Loyalty & Gift Card** option - Go to **Website** app > **eCommerce** > **Loyalty** > **Discount &…
## Steps to reproduce - Install **eCommerce** app - Go to **Settings** and enable **Discounts, Loyalty & Gift Card** option - Go to **Website** app > **eCommerce** > **Loyalty** > **Discount & Loyalty** - Create a new coupon by setting the **Program Type** to **Coupons** and then save - Generate a new coupon by clicking the **GENERATE COUPONS** button. - Go to **Website** > **site** > **Homepage** - Go to **Shop** page - Add a product to the cart - Apply the coupon code created - Remove the coupon code by clicking the bin icon next to the coupon code line - The coupon code is **_NOT_** removed. ## Investigation #### First, we'll take a look on what happens when a coupon code is applied - When a coupon code is applied, a new `sale.order.line` is created for it. - That triggers `super()._compute_website_order_line()` https://github.com/odoo/odoo/blob/d8ec7735aa8759fa94fc0223945ac9b19e05312e/addons/website_sale_loyalty/models/sale_order.py#L111 which **_filters out_** the discount order line https://github.com/odoo/odoo/blob/d8ec7735aa8759fa94fc0223945ac9b19e05312e/addons/website_sale/models/sale_order.py#L66 via the `_show_in_cart()` method https://github.com/odoo/odoo/blob/d8ec7735aa8759fa94fc0223945ac9b19e05312e/addons/website_sale_loyalty/models/sale_order_line.py#L12 - Then a new **_temporary_** sale.order.line is created by https://github.com/odoo/odoo/blob/d8ec7735aa8759fa94fc0223945ac9b19e05312e/addons/website_sale_loyalty/models/sale_order.py#L121 meaning that is has no `id` - ⚠️ Note that we can only apply one coupon from the same program type. #### Second, Let's take a look on what happens when we try to remove a coupon code - A call is made to `cart_update_json()` which calls https://github.com/odoo/odoo/blob/d8ec7735aa8759fa94fc0223945ac9b19e05312e/addons/website_sale/controllers/main.py#L811-L819 which calls https://github.com/odoo/odoo/blob/d8ec7735aa8759fa94fc0223945ac9b19e05312e/addons/website_sale_loyalty/models/sale_order.py#L159 - But as noted above the coupon order line **`has no id`** being a **_temporary_** record. Hence the `line_id` is **None** which basically cancels the cart update. opw-3744910 Forward-Port-Of: odoo/odoo#156383 Forward-Port-Of: odoo/odoo#154680
This update fixes a bug where accrual calculations were incorrectly updating allocation amounts when created with start dates in the past. The fix ensures a 'nextcall' is automatically set, preventing immediate value changes and maintaining accurate accrual balances. This improves the reliability of our holiday accrual system.
Original PR description
Description of the issue: Before this commit, allocation created for which no nextcall were set (allocation starting in the past or immediately) would update to a wrong value if the cron is run immediately after the allocation creation To reproduce the issue: - Create an accrual plan giving daily allocation - Create an allocation with that accrual and a start date in the past - Validate the allocation - Run the accrual schedule action manually - The new amount for the allocation is inferior to what it was at creation Expected Behaviour: The value should remain the same Fix: A nextcall is now set whenever the allocation is supposed to have already started to ensure no immediate accrual update. Forward-Port-Of: odoo/odoo#148154
This update fixes an issue where expense totals were incorrectly calculated due to using the current exchange rate instead of the rate at the time the expense was incurred. The change ensures accurate totals in the 'totals to submit' section, improving the reliability of expense reporting. This impacts users who record expenses in multiple currencies.
Original PR description
## Issue: - Expenses entered in currencies other than the company currency are incorrectly calculated using today's exchange rate instead of the rate applicable on the date the expense was made. This results in inaccurate totals in the "totals to submit" section of the Expenses dashboard. ## Steps To Reproduce: - Go to Expenses. - See the current total to submit. - Create a new expense that is 999,999 EUR but $1.00 USD. - See that the expenses to submit is not matching the exchange rate we put in the expense. ## Solution: - In the 'get_expense_dashboard' method instead of summing up of 'total_amount_currency' and then converting to the company currency. we sum up directly the 'total_amount' for each expense instead. opw-3731445 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156591 Forward-Port-Of: odoo/odoo#155221
This update improves the speed of creating orderpoints in the stock management system. Previously, the process was slow due to inefficient data retrieval. This change streamlines the process, significantly reducing the time taken to create orderpoints and improving overall system performance.
Original PR description
This commit changes the computation of product having a negative forecasted quantity to create manual orderpoints. The issue was that each replenish location needed multiple `_read_group` on…
This commit changes the computation of product having a negative forecasted quantity to create manual orderpoints. The issue was that each replenish location needed multiple `_read_group` on `stock.quant` and `stock.move` on all storable product. This commit makes only 3 `_read_group`s for all products x locations and post process the group and quantity sum by location in Python. This method gives some performance gain in time as well as in memory consumption Task: 3653272 Here is the time comparison before/after the patch for different configuration | | before | after | |---|---|---| | 700 loc, 300 prod | 14.08s | 850ms | |10 loc, 3k prod | 2.174s | 349ms | |700 loc, 30k prod | TO | 74s | Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156507 Forward-Port-Of: odoo/odoo#149966
This update fixes an error that occurred during database upgrades, specifically when tracking values were associated with multiple models. The change ensures that tracking calculations are accurate, preventing errors related to model mismatches and improving data integrity. This resolves a potential issue impacting task management and reporting.
Original PR description
Forward-Port-Of: odoo/odoo#156571
This update resolves a user error that occurred during account tag migrations, specifically when inactive tags were present. The change ensures inactive tags are correctly processed, preventing migration blocks and allowing seamless updates to the accounting system. This improves stability and prevents disruptions during module upgrades.
Original PR description
After this commit: [commit](https://github.com/odoo/odoo/pull/148866/files) - If tags belonging to localization are present in the database but with active='f', the user error will still trigger. As…
After this commit: [commit](https://github.com/odoo/odoo/pull/148866/files)
- If tags belonging to localization are present in the database but with active='f', the user error will still trigger. As mentioned in the commit if tags are deleted by the end user, then updating the localization module will resolve this and will create the new tags for that localization, but in our case if the tag are present in the db but are active='f', so updating the localization module will not help as noupdate will become true, if the enduser makes any changes to it. so updating the localization will not change active='f' and the user error will keep on coming unless the end user manually set it active='t'.
**Steps to reproduce**:
1. Create a database in saas-16.2
2. Install the module account_accountant and a localization, for example l10n_ee.
3. With debug mode on, navigate to the account tags menu
(Configuration > Accounting > Account Tags).
4. Archive any tag using the archive action.
5. On the accounting settings page, under Fiscal Localization, trigger a user error when clicking the reload button.
This user error is blocking.
By making the record inactive, the user has made the account tag no-update, so upgrading the module does not solve this.
- So, as this mentioned commit is introduced in 16.2, any db migrating to v16.2 or further, when the ```_get_tag_mapper``` is triggered this user error is blocking the migration.
**Solution**:
- This commit adds a context to include the inactive tags here: [here](https://github.com/odoo/odoo/blob/saas-16.2/addons/account/models/chart_template.py#L924-L928)
OPW-3716164
UPG-1297494
[TBG-1074](https://upgrade.odoo.com/web#id=1074&cids=1&menu_id=107&action=178&model=upgrade.request.traceback.group&view_type=form)
Forward-Port-Of: odoo/odoo#155516
Forward-Port-Of: odoo/odoo#153944This update resolves a problem where new picking requests were incorrectly generated for repaired products without stock. The fix ensures that the system properly handles 'draft' moves during the repair process, preventing gaps in the repair sequence and maintaining accurate tracking. This improves the reliability of our repair operations.
Original PR description
For repaired products with no stock, a new picking is wrongly created, leading to a gap in the repair sequence. This because the move is created in 'draft' and the function does not take it into account. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156476 Forward-Port-Of: odoo/odoo#156083
This update optimizes how spreadsheet filters are evaluated, reducing unnecessary calculations and improving report loading times. Specifically, the Timesheet report now loads faster due to a change in how filter evaluations are handled. While this doesn't address all filter evaluation issues, it represents a significant performance gain.
Original PR description
Steps to reproduce:
- create a relational filter, let's say on `res.company`
- add a default value
- reference the filter in a cell with `=ODOO.FILTER.VALUE("my filter")`
=> every `ODOO.FILTER.VALUE` triggers an evaluation
With this commit, the re-evaluation after the data is fetched uses the
data source mechanism which only re-evaluates when all the data promises
are resolved, instead of evaluating after every resolved promise.
With this commit, the number of evaluations required when loading the
Timesheet report on our prod goes from 5 evaluations to only 3 (each evaluation
is 2-3s) because `ODOO.FILTER.VALUE("Company")` is present two times.
One issue this commit doesn't fix: there one RPC per `ODOO.FILTER.VALUE`
(can be fixed in master very easily because we refactored data fetching)
Task: 3787125
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#156495This update optimizes how Odoo routes incoming emails by adding an index to the `mail.alias` table. Previously, searching email aliases was slow due to inefficient database queries. This change dramatically speeds up email routing, particularly for high-volume email processing, leading to a more responsive system.
Original PR description
## Description Since https://github.com/odoo/odoo/pull/76734, the new field `alias_full_name` is used in addition to `alias_name` to search on `mail.alias` and route emails in `message_route`. It's…
## Description
Since https://github.com/odoo/odoo/pull/76734, the new field `alias_full_name` is used in addition to `alias_name` to search on `mail.alias` and route emails in `message_route`. It's also used as a search criteria in `_search_alias_email` on `mail.alias.mixin. optional`. The issue is that the table `mail.alias` can grow quite large, and only the old field `alias_name` has an index on it, which may not be selective enough, forcing Seq.Scans on the table with possibly millions of records. The impact is noticeable on `message_route` which is a hot path for processing incoming emails.
Adding an index on `alias_full_name` allows PostgreSQL to do an bitmap OR scan on the two indexes, considerably speeding up search criteria that are a disjunction between `alias_name` and `alias_full_name`.
## Benchmark
For domain
```python
[
'&',
('alias_model_id', '!=', reply_model_id),
'|',
('alias_full_name', 'in', email_to_list),
'&', ('alias_name', 'in', email_to_localparts), ('alias_incoming_local', '=', True),
]
```
with test arguments, on a `mail.alias` table containing over 2M records.
| | Before | After |
|-----------|--------|-------|
| Timing | 696ms | 1ms |
| Buffer IO | 790MB | 48KB |
Specially impactful as those gains needs to be multiplied by the frequency of the searches.
## Reference
task-3724844
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#156237