Friday, March 1, 2024
94 changes · master
Enhancements to existing features
The percentage field tests in the web module were moved to the newer testing approach. This helps maintain product quality and makes future changes to percentage inputs safer, with no direct change for end users.
Original PR description
task-3705027
The web module’s automated checks for percent pie fields were moved to a newer testing approach. This helps maintain the reliability of this interface element while keeping the test suite easier to maintain.
Original PR description
task-3705027
The PDF viewer field tests in the web module were moved to the newer testing framework. This is an internal quality improvement that helps maintainers validate PDF viewing behavior more consistently without changing user-facing features.
Original PR description
task-3705027
Users can now find the image insertion command more easily when searching with common words like “image” or “picture.” This makes creating and editing content faster and more intuitive in the web editor.
Original PR description
With this commit, when a user attempts to insert an image using terms like image or picture it automatically locates the /image command within the powerbox. This improvement simplifies the process for users, allowing them to easily access the /image command. task-3754831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The portal rating display now removes the extra text label next to star ratings. This makes the rating area cleaner while keeping the meaning clear for users through the stars themselves.
Original PR description
**Before the commit:** The rating stars were associated with the rating label, but they seemed to be unnecessary. **After this commit:** Rating labels are removed since the stars are pretty much self-explanatory. task-3617971
Code cleanup and technical improvements
Odoo's automated guided tour tests now use a newer internal method to find page elements instead of the older jQuery-based approach. This keeps test infrastructure aligned with the platform's current tooling and helps maintain reliability across affected apps without changing end-user features.
Miscellaneous changes
Before this commit, the `bg-primary` class was overwriting the `bg_color` set by the user after saving changes as it has the `!important` tag. Steps to reproduce the issue: 1. Go to Shop page on website 2. Enable edit mode 3. Pick a product and create a new Badge (ribbon) 4. Change the background color and save changes -> color reverts to `bg-primary` This commit fixes this behavior by adding the `!important` tag to the `bg_color` so that it properly overwrites the `bg-primary`
Original PR description
Before this commit, the `bg-primary` class was overwriting the `bg_color` set by the user after saving changes as it has the `!important` tag. Steps to reproduce the issue: 1. Go to Shop page on website 2. Enable edit mode 3. Pick a product and create a new Badge (ribbon) 4. Change the background color and save changes -> color reverts to `bg-primary` This commit fixes this behavior by adding the `!important` tag to the `bg_color` so that it properly overwrites the `bg-primary` color. opw-3734598 Forward-Port-Of: odoo/odoo#155040
This fixes visual issues with dropdown buttons so they clearly appear active when opened and their caret icons align correctly. It also improves search bar consistency by matching dropdown height and focus styling, creating a smoother user experience.
Original PR description
Before this PR: 1. The dropdown toggle button would not display as active when opened. 2. The dropdown caret position was wrong in some cases, (no margin, displayed too low). 3. When hotkeys are…
Before this PR: 1. The dropdown toggle button would not display as active when opened. 2. The dropdown caret position was wrong in some cases, (no margin, displayed too low). 3. When hotkeys are added on an dropdown toggle with a caret, the caret shows on top of the hotkey element. This happens because the caret is added using css `:after` selector, and is thus displayed after the hotkey element. 4. The dropdown in the community searchbar did not have the same height as the searchbar input. After this PR: 1. The border and background color of a dropdown toggle (element with the classes `.o-dropdown.btn-secondary`) is displayed as active when the dropdown is open. 2. The dropdown caret now properly position itself in the middle of the button and has a margin when some elements precede it. 3. The hotkey elements have now a z-index of 1, which is enough for it to be displayed of top of potential `:after` in the target element. 4. The dropdown in the community searchbar now has the same height as the searchbar input. The caret in the search bar as also been changed to use the o-dropdown-caret css class instead of a custom i element. Related task-3754441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change removes duplicate logic used to identify stock accounting entries, so related processes rely on one consistent rule. It helps reduce the risk of inconsistent cost accounting behavior and makes future maintenance safer.
Original PR description
The `_eligible_for_cogs` method was added in v15 (https://github.com/odoo/odoo/commit/2e95fda97d29cab4819b4b64edfb956cb52f3a6f). Later, the `_can_use_stock_accounts` method was added in v14 (https://github.com/odoo/odoo/commit/42ec2a088a735fed879bcd50f3744031ab45d08e, amended in https://github.com/odoo/odoo/commit/1f8889437f859f0bb4dfb801293ed48bb6fe1c65) and forward ported to v15. Thus, both methods coexist and they do the same. We should merge them, right? --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves internal testing for the company switch menu on desktop and mobile. It ensures the right test categories are applied and removes timing-related instability, helping future changes be validated more consistently without affecting end users.
Original PR description
Before this commit: - "desktop" tags were added on each test of the switch_company_menu tests, instead of being globally declared; - "mobile" tags were missing from its mobile counterpart; - there was an undeterministic error (at least when testing in local) due to timers not being properly awaited after switching companies in a test (the router does the "pushState" after a 0ms timeout). This commit handles these issues, while also enforcing the use of adequate helpers in these suites. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoice and purchase order email headers now use the recipient user's selected language date format instead of a default format. This makes emailed documents more consistent and easier for users to read across different locales.
Original PR description
Before this PR, the email header for purchase orders and invoices sent from the purchase and account modules did not display the user's selected date format in their language. Instead, it showed the default date format. Technical Reason: In the 'format_date' function, the issue arises because the date format is forcefully set within both modules in arguments, overriding the language specific date format. After this PR, user's selected date format will show in both email header and body. **Task**-3618955
This update corrects the base demo data by linking a demo partner record to its related user. This helps demo environments show more consistent ownership information and reduces confusion during testing or demonstrations.
Original PR description
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
This fixes a small issue that caused unnecessary warning messages in server logs when field service worksheet templates were looked up. The change helps keep logs cleaner and avoids misleading operational noise without changing user-facing behavior.
Original PR description
Before this commit, a warning is logged in the server logs because `=` operator is used with an array as right leaf in a domain used in a search in `_compute_worksheet_template_id` defined in `project.project` model. The operator used should be `in` instead of `=`, that's why we got that warning. This commit fixes the issue by changing the operator used inside that domain to use `in` instead of `=`. runbot-58374 X-original-commit: 2b12d5e8
Original PR description
Before this commit, triggers (extra_triggers, alt_triggers and skip_triggers) defined in steps of tours were found in the DOM with $() jQuery function. In this commit, these steps are now found with Hoot queryAll() function. Triggers of steps have so been adapted to satisfy this adaptation. task~3600484 https://github.com/odoo/enterprise/pull/57825
This update changes how automated guided tour tests identify page elements, moving from an older method to a newer internal testing approach. It helps keep quality checks reliable across many business apps without changing the day-to-day user experience.
Original PR description
Before this commit, triggers (extra_triggers, alt_triggers and skip_triggers) defined in steps of tours were found in the DOM with $() jQuery function. In this commit, these steps are now found with Hoot queryAll() function. Triggers of steps have so been adapted to satisfy this adaptation. task~3600484 https://github.com/odoo/odoo/pull/155605
Before this commit, it was possible to capture an order twice due to the rounding difference in quantity, especially when users use a scale. With this commit, it uses a more relaxed condition and remove the quantity from the orderline comparison. Given that the system checks the payments and with the same product and price units, it's unlikely that two orders will have the same payment amount. opw-3735436 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/su
Original PR description
Before this commit, it was possible to capture an order twice due to the rounding difference in quantity, especially when users use a scale. With this commit, it uses a more relaxed condition and remove the quantity from the orderline comparison. Given that the system checks the payments and with the same product and price units, it's unlikely that two orders will have the same payment amount. opw-3735436 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155513
Before this commit, due to a recent change, the customer name was not being printed on reprinted receipts. This was inconsistent with user expectations, as they expected to see the customer name on the receipt, regardless of whether a loyalty program was in place or not. With this commit, we ensure that the customer name is always printed on reprinted receipts, aligning the system behavior with user expectations. opw-3760165 --- I confirm I have signed the CLA and read the PR guideline
Original PR description
Before this commit, due to a recent change, the customer name was not being printed on reprinted receipts. This was inconsistent with user expectations, as they expected to see the customer name on the receipt, regardless of whether a loyalty program was in place or not. With this commit, we ensure that the customer name is always printed on reprinted receipts, aligning the system behavior with user expectations. opw-3760165 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155543
Currently, when adding a product to a quotation with the catalog, no warning message will appear when adding a poduct that has a warning or blocking message. Steps to reproduce: ------------------- * Go to **Sales** app -> Configuration -> Settings * Enable **Sale Warnings** * Go to **Products** -> Products * Create a new product * Under **Sales** tab: * For warning, select either warning or blocking message * Write a message * Go to **Orders** -> Quotations * Create a new quota
Original PR description
Currently, when adding a product to a quotation with the catalog, no warning message will appear when adding a poduct that has a warning or blocking message. Steps to reproduce: ------------------- *…
Currently, when adding a product to a quotation with the catalog, no warning message will appear when adding a poduct that has a warning or blocking message.
Steps to reproduce:
-------------------
* Go to **Sales** app -> Configuration -> Settings
* Enable **Sale Warnings**
* Go to **Products** -> Products
* Create a new product
* Under **Sales** tab:
* For warning, select either warning or blocking message
* Write a message
* Go to **Orders** -> Quotations
* Create a new quotation
* Select the **Catalog** to add products
* Add the newly created product
Why the fix:
------------
The first version of this fix was a python exclusive change. It was a bit hacky; it was raising an error when the product had a blocking warning and sending a message on the bus when the product had a non-blocking warning.
The second version was changing the return value of `_update_order_line_info` to return the price and the warning if any. The warning was shown inside JS with `_updateQuantity`. This change was not good for a stable verion as it was changing the signature of a public method.
This fix automatically changes the data that is loaded to the catalog. It adds the warning message if any and changes the `readOnly` field accordingly.
Warning/blocking messages will be automatically displayed in the catalog, on the product informations. Products with blocking messages will me marked as readonly to avoid being able to add the product to the sale order (this is the original behavior for blocking messages).
Regarding the field `readOnly` and ẁarning`:
* We can't write `res[product.id]['readOnly'] = product.sale_line_warn == "block"' because readOnly is set to True by default if the sale order is cancelled and doing this would overide that value later. See:
https://github.com/odoo/odoo/blob/21c25a7ccd0ba2d6574ddbcfbcf50dbbc03a1e6c/addons/product/models/product_catalog_mixin.py#L97-L99
* We're also sending the warning only if there is one because of this:
```python
<span t-elif="props.readOnly" class="my-2 pt-3 border-top" t-out="props.warning">
You can't edit this product in the catalog.
</span>
```
Because in the case where readOnly is True for another reason than the product having a blocking warning, the initial message will be displyed.
Since the module purchase also uses the warning on products, this fix is extended to include it.
opw-3631511
Forward-Port-Of: odoo/odoo#149155Since the introduction of the Embed Code snippet with [1], in case some content was created dynamically through a `<script>` tag, it would be duplicated upon editing the snippet again after it had been displayed a 1st time. This is because each time you open the snippet's ace editor, the current state of the snippet (including dynamically created elements) is saved in the view. This commit removes the `<script>`s inside embed code snippets from the view in edit mode, and then saves them
Original PR description
Since the introduction of the Embed Code snippet with [1], in case some content was created dynamically through a `<script>` tag, it would be duplicated upon editing the snippet again after it had…
Since the introduction of the Embed Code snippet with [1], in case some
content was created dynamically through a `<script>` tag, it would be
duplicated upon editing the snippet again after it had been displayed a
1st time. This is because each time you open the snippet's ace editor,
the current state of the snippet (including dynamically created
elements) is saved in the view.
This commit removes the `<script>`s inside embed code snippets from the
view in edit mode, and then saves them on the server upon save.
We also take the opportunity to add a message in edit mode if the
snippet doesn't display anything (e.g. if it only contains a script tag,
or an empty element), so that it is easily focusable to edit its
content.
Finally, we add a message upon editing an embed code snippet to inform
the user that they should not use it unless they know what they're doing
as well as tell them they may inject code in the `<head>` or `<body>`
elements through the Theme panel.
Note: this fix is only valid for code injected inside the embed code
snippet. For code injected outside of the snippet, we have no way of
controlling / sanitizing the DOM after the fact.
Steps to reproduce:
1. Drag and drop an Embed Code Snippet
2. Copy the following code:
```
<script>
document.addEventListener('DOMContentLoaded', function () {
const alertEl = document.createElement('div');
alertEl.classList.add('alert', 'alert-primary');
alertEl.textContent = "Hello";
document.getElementById('some-stuff').appendChild(alertEl);
});
</script>
<div id="some-stuff"></div>
```
3. Save and exit the editor. The injected div should appear.
4. Go back to the editor, click to edit the snippet and either save or
discard.
5. Exit the editor
=> The div is duplicated.
[1]: https://github.com/odoo/odoo/commit/2cc481d1a62202ade4c1ca8f846c962f9f2cc34d
opw-3513760
Forward-Port-Of: odoo/odoo#153751
Forward-Port-Of: odoo/odoo#142130- Simplify and clean up formatLang code. - Adds the possibility to give formatLang() a 'rounding_mode' (any Decimal rounding mode) and an amount_rounding ('decimals', 'units', 'thousands', 'millions' and 'lakhs'). 'amount_rounding' will display the amount in the given unit. For example, 10456 in 'thousands' will be 10. task-3626894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154397 Forward-Port-Of: odoo/odoo#151
Original PR description
- Simplify and clean up formatLang code.
- Adds the possibility to give formatLang() a 'rounding_mode' (any Decimal rounding mode)
and an amount_rounding ('decimals', 'units', 'thousands', 'millions' and 'lakhs').
'amount_rounding' will display the amount in the given unit. For example, 10456 in 'thousands' will be 10.
task-3626894
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#154397
Forward-Port-Of: odoo/odoo#151314Prior to this commit, the receipt element was cloned and appended to the render-container for web printing, then deleted after print callback. This approach failed on Android, leading to an empty page, as the cloned element was removed before printing. This commit resolves the issue by retaining the cloned element until the next clone addition to the container, at which point existing elements are removed. opw-3755682 --- I confirm I have signed the CLA and read the PR guidelines at www.o
Original PR description
Prior to this commit, the receipt element was cloned and appended to the render-container for web printing, then deleted after print callback. This approach failed on Android, leading to an empty page, as the cloned element was removed before printing. This commit resolves the issue by retaining the cloned element until the next clone addition to the container, at which point existing elements are removed. opw-3755682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154777
PURPOSE ======= The survey addon assets contain some global rules for print mode, that are present in the global backend stack. In Odoo 15.2, we put these rules in `survey_templates_results.scss`. Then, in later versions of Odoo we updated it wih more 'print mode' global rules. As these rules are specific to the survey addon, we don't want them to affect the (whole) Odoo backend. HOW TO FIX ========== It seems rules defined in `survey_templates_results.scss` are not used in
Original PR description
PURPOSE ======= The survey addon assets contain some global rules for print mode, that are present in the global backend stack. In Odoo 15.2, we put these rules in `survey_templates_results.scss`.…
PURPOSE ======= The survey addon assets contain some global rules for print mode, that are present in the global backend stack. In Odoo 15.2, we put these rules in `survey_templates_results.scss`. Then, in later versions of Odoo we updated it wih more 'print mode' global rules. As these rules are specific to the survey addon, we don't want them to affect the (whole) Odoo backend. HOW TO FIX ========== It seems rules defined in `survey_templates_results.scss` are not used in survey backend views, but specific to frontend views. `survey_templates_results.scss` is also part of the `survey.survey_assets` bundle. This bundle is loaded only for the following frontend views: - Survey: main page (take survey) - Survey: custom 403 page - Survey: void content - Survey: login required - Survey: expired - Survey: Access Code page - Survey: print page - Survey: result statistics page Among them, views that are not intended to be printed are not negatively impacted by the css rules for print mode. A solution would therefore be to remove `survey_templates_results.scss` from the backend stack. see https://github.com/odoo/odoo/commit/03641610c2b4a6b832ea87795fd21e1d7af10b59 see https://github.com/odoo/odoo/pull/135683 see https://github.com/odoo/odoo/pull/146812 task-3666858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155126 Forward-Port-Of: odoo/odoo#148296
Before this commit, in a kanban view grouped by a date(time) field, with progressbars and an aggregate field, after clicking on a bar to filter records, the aggregate value was always 0. This was due to a mismatch when trying to find the value of the aggregate in the web_read_group result, as when grouped by a date or datetime field, the key is `fieldname:granularity`, and we were looking for the fieldname only. This commit fixes the issue. It also fixes the mocked version of read_progress
Original PR description
Before this commit, in a kanban view grouped by a date(time) field, with progressbars and an aggregate field, after clicking on a bar to filter records, the aggregate value was always 0. This was due…
Before this commit, in a kanban view grouped by a date(time) field, with progressbars and an aggregate field, after clicking on a bar to filter records, the aggregate value was always 0. This was due to a mismatch when trying to find the value of the aggregate in the web_read_group result, as when grouped by a date or datetime field, the key is `fieldname:granularity`, and we were looking for the fieldname only. This commit fixes the issue. It also fixes the mocked version of read_progress_bar in the MockServer, s.t. we can correctly reproduce the scenario in tests, as in the previous version, keys in the returned object weren't computed the same way as in the real read_progress_bar (e.g., "14,Mitchel", instead of "Mitchel"). A similar fix has been done in [1]. This allows us to introduce a test when grouped by many2one, which doesn't work as of 17.0. [1] fd759f18d056844c486a68d0c394df5a03e789f0 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#155701 Forward-Port-Of: odoo/odoo#155524
Previously, when exporting CIUS-RO XML and the supplier (company) or customer doesn't have a country code prefix on either their VAT or company ID, an error will be thrown preventing the user from generating the XML. But after allowing the XML generating process, the XML is then rejected by the validator because of `BR-CO-09` rule: ```xml <assert id="BR-CO-09" flag="fatal" test="( contains( ' 1A AD AE AF AG AI AL AM AO AQ AR AS AT AU AW AX AZ BA BB BD BE BF BG BH BI BJ BL BM BN BO BQ BR BS B
Original PR description
Previously, when exporting CIUS-RO XML and the supplier (company) or customer doesn't have a country code prefix on either their VAT or company ID, an error will be thrown preventing the user from…
Previously, when exporting CIUS-RO XML and the supplier (company) or customer doesn't have a country code prefix on either their VAT or company ID, an error will be thrown preventing the user from generating the XML. But after allowing the XML generating process, the XML is then rejected by the validator because of `BR-CO-09` rule: ```xml <assert id="BR-CO-09" flag="fatal" test="( contains( ' 1A AD AE AF AG AI AL AM AO AQ AR AS AT AU AW AX AZ BA BB BD BE BF BG BH BI BJ BL BM BN BO BQ BR BS BT BV BW BY BZ CA CC CD CF CG CH CI CK CL CM CN CO CR CU CV CW CX CY CZ DE DJ DK DM DO DZ EC EE EG EH EL ER ES ET FI FJ FK FM FO FR GA GB GD GE GF GG GH GI GL GM GN GP GQ GR GS GT GU GW GY HK HM HN HR HT HU ID IE IL IM IN IO IQ IR IS IT JE JM JO JP KE KG KH KI KM KN KP KR KW KY KZ LA LB LC LI LK LR LS LT LU LV LY MA MC MD ME MF MG MH MK ML MM MN MO MP MQ MR MS MT MU MV MW MX MY MZ NA NC NE NF NG NI NL NO NP NR NU NZ OM PA PE PF PG PH PK PL PM PN PR PS PT PW PY QA RE RO RS RU RW SA SB SC SD SE SG SH SI SJ SK SL SM SN SO SR SS ST SV SX SY SZ TC TD TF TG TH TJ TK TL TM TN TO TR TT TV TW TZ UA UG UM US UY UZ VA VC VE VG VI VN VU WF WS XI YE YT ZA ZM ZW ',substring(cbc:CompanyID,1,2) ) )">[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’.</assert> ``` In Romania however, there are multiple types of "Tax IDs", and it is perfectly valid in Romania to have a Tax ID without RO (country code prefix) in front of them. They are not a subject to paying VAT, and it should still be possible to generate CIUS-RO XML with their tax identifications. This commit aims to fix this behavior by applying some special treatment to Romanian partners when generating the XML: by modiying the TaxScheme ID. The error only raises when the detected ID is 'VAT'. This commit also fixes and clean some of the irrelevant constraints and tests previously written in `l10n_ro_edi`. task-id: 3649426 Forward-Port-Of: odoo/odoo#155252
How to reproduce: - Install hr with demo data - Create a user without access to hr and turn it into an employee - Create a user for Abigail - Assign Abigail as manager of the new user - Click on "onboarding plan" in the chatter of the new user - Then in the dialog, click on "Schedule" button You get the error "Assigned user test has no access to the document and is not able to handle this activity." because the new user has no access to the record employee on which those activities are
Original PR description
How to reproduce: - Install hr with demo data - Create a user without access to hr and turn it into an employee - Create a user for Abigail - Assign Abigail as manager of the new user - Click on…
How to reproduce: - Install hr with demo data - Create a user without access to hr and turn it into an employee - Create a user for Abigail - Assign Abigail as manager of the new user - Click on "onboarding plan" in the chatter of the new user - Then in the dialog, click on "Schedule" button You get the error "Assigned user test has no access to the document and is not able to handle this activity." because the new user has no access to the record employee on which those activities are scheduled. As activities for which the user has no access to the underlying record are now displayed in the systray (with no access to the record), we remove the check that prevent assigning an activity to a user on a record he has no access to. Technical note: before odoo/odoo#149965, activities scheduled manually were created with the flag "automated" set to True and when this flag is set the check that ensures that the user has access to the record is skipped. With odoo/odoo#149965, as the "automated" flag is set to False when scheduling activities manually, an error is trigerred if the user has no access to the underlying record. Here we always skip that test and mark the method as deprecated because the user can see the activity no matter the access he has on the underlying record. Task-3598836 Forward-Port-Of: odoo/odoo#155576
Steps to reproduce the bug: - Create a storable product “P1”: - Tracked by “SN” - Update the qty to 1 in “WH/stock” with “SN1” - Create an internal transfer: - Location: wh/Stock - Dest location: wh2/stock - Mark as todo - Try to select SN1 in the `stock.move` Problem: A warning is triggered: `Existing Serial numbers. Please correct the serial numbers encoded: (001) exists in location WH/Stock` We do a search to find all the quants in every location to verify
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked by “SN”
- Update the qty to 1 in “WH/stock” with “SN1”
- Create an internal transfer:
- Location: wh/Stock
- Dest location: wh2/stock
- Mark as todo
- Try to select SN1 in the `stock.move`
Problem:
A warning is triggered:
`Existing Serial numbers. Please correct the serial numbers encoded: (001) exists in location WH/Stock`
We do a search to find all the quants in every location to verify if the same serial number is not being used, but we do not exclude the source location.
opw-3734300
Forward-Port-Of: odoo/odoo#155651
Forward-Port-Of: odoo/odoo#154626PURPOSE Mail: add tests for MailTemplate send_mail Several flows use MailTemplate.send_mail() in batch, notably event email scheduler which sends emails to event attendee in batch. This commit adds tests around 'send_mail' method of MailTemplate model * add tests for batch: it is currently not supported hence using a loop but batch is going to be added soon, allowing to test the batch version works as intended; * add query counters, notably for batch mode and when dynam
Original PR description
PURPOSE Mail: add tests for MailTemplate send_mail Several flows use MailTemplate.send_mail() in batch, notably event email scheduler which sends emails to event attendee in batch. This commit adds…
PURPOSE
Mail: add tests for MailTemplate send_mail
Several flows use MailTemplate.send_mail() in batch, notably event email
scheduler which sends emails to event attendee in batch. This commit adds
tests around 'send_mail' method of MailTemplate model
* add tests for batch: it is currently not supported hence using a loop but
batch is going to be added soon, allowing to test the batch version works
as intended;
* add query counters, notably for batch mode and when dynamic reports are
involved in templates;
Event: improve mail scheduler tests
Make them easier to improve and modify
* use a dedicated setup (allowing to add specific unit tests on test data);
* move initial asserts into its own unit test (to keep other tests shorter);
* use available mocks for freezetime and sql.now;
Then add tests for registration emails, to check what happens for communication
scheduled right at registration time.
LINKS
Part of Task-3764894: Event: Allow using cron triggers for communication
Part of Task-3764891: Mail: Batch-ize MailTemplate send_mail
Part of Task-3164278: Mail: Batch send: ensure limit, avoid force
Part of Task-3084943: Event: Improve communication scheduler scalability
Forward-Port-Of: odoo/odoo#155717`_message_auto_subscribe` relies on `_get_subscription_data` to know who is subscribed to what. This method uses a raw SQL query but doesn't flush the relevant records beforehand. This is not an issue in most normal cases, but if followers are edited manually, for example in order to merge existing models, it may cause issues when then assigning someone to the model will attempt adding them to the list of followers, when they already were on it. task-3713472 original issue in opw-3634410
Original PR description
`_message_auto_subscribe` relies on `_get_subscription_data` to know who is subscribed to what. This method uses a raw SQL query but doesn't flush the relevant records beforehand. This is not an issue in most normal cases, but if followers are edited manually, for example in order to merge existing models, it may cause issues when then assigning someone to the model will attempt adding them to the list of followers, when they already were on it. task-3713472 original issue in opw-3634410 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155043 Forward-Port-Of: odoo/odoo#152041
Since [1], the `Channel subscription is renewed when channel is added from invite` test was sometimes failing. The bus subscription is refreshed when the user joins a channel at the same time or after the initial bus subscription. Usually, the channel is created at the same time than the bus subscription. When it is not the case, the test fails. This PR fixes the issue by patching the date so that the channel is clearly created before the bus subscription. As a result, there will be no subscr
Original PR description
Since [1], the `Channel subscription is renewed when channel is added from invite` test was sometimes failing. The bus subscription is refreshed when the user joins a channel at the same time or after the initial bus subscription. Usually, the channel is created at the same time than the bus subscription. When it is not the case, the test fails. This PR fixes the issue by patching the date so that the channel is clearly created before the bus subscription. As a result, there will be no subscription initially. fixes runbot-57787 [1]: https://github.com/odoo/odoo/pull/153666 Forward-Port-Of: odoo/odoo#155606
Starshipit is the leading provider of integrated and automated fulfillment solutions for online businesses integrating with the leading carriers used in Australia and New Zealand, such as Australia Post, DHL, Aramex, CouriersPlease, and more This PR will add support to integrate with starshipit directly in Odoo, providing rates and shipping for users who need it. Task ID # 3041982 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of
Original PR description
Starshipit is the leading provider of integrated and automated fulfillment solutions for online businesses integrating with the leading carriers used in Australia and New Zealand, such as Australia Post, DHL, Aramex, CouriersPlease, and more This PR will add support to integrate with starshipit directly in Odoo, providing rates and shipping for users who need it. Task ID # 3041982 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155664 Forward-Port-Of: odoo/odoo#135839
**Steps:** - Open Timesheets - Go to To Validate > All Timesheets - Pivot View is rendered **Issue:** The validate button is not rendered when the pivot view is loaded **Solution:** The changes introduced in these files are aimed at enhancing the customization and flexibility of the Pivot component in the web application. By adding the buttonTemplate prop to the PivotController and utilizing it in the PivotRenderer template, developers can dynamically choose the template for rendering
Original PR description
**Steps:** - Open Timesheets - Go to To Validate > All Timesheets - Pivot View is rendered **Issue:** The validate button is not rendered when the pivot view is loaded **Solution:** The changes…
**Steps:** - Open Timesheets - Go to To Validate > All Timesheets - Pivot View is rendered **Issue:** The validate button is not rendered when the pivot view is loaded **Solution:** The changes introduced in these files are aimed at enhancing the customization and flexibility of the Pivot component in the web application. By adding the buttonTemplate prop to the PivotController and utilizing it in the PivotRenderer template, developers can dynamically choose the template for rendering buttons within the pivot view. This change is particularly beneficial for scenarios where different button layouts or styles are required based on specific use cases or user preferences. Additionally, the introduction of a default value for buttonTemplate in the PivotView configuration ensures a smooth fallback mechanism if a custom template is not explicitly provided. Overall, these adjustments contribute to a more adaptable and extensible Pivot component, catering to diverse application requirements. **Task**-3623493 Forward-Port-Of: odoo/odoo#155667 Forward-Port-Of: odoo/odoo#147054
Steps to reproduce: 1. Install l10n_mx 2. Go to Accounting > Reporting > Trial balance. 3. Click the COA SAT(XML) export button. 4. Warnings are raised. Problem: the report should work out-of-the-box on new databases. Cause: 1. Some tags are missing on auto-generated accounts. 2. Some data were not correct and had the wrong tag. 102 accounts in particular should be debit and not credit. This PR migrate the incorrect data and add a default naive computation of the tag on newly crea
Original PR description
Steps to reproduce: 1. Install l10n_mx 2. Go to Accounting > Reporting > Trial balance. 3. Click the COA SAT(XML) export button. 4. Warnings are raised. Problem: the report should work out-of-the-box on new databases. Cause: 1. Some tags are missing on auto-generated accounts. 2. Some data were not correct and had the wrong tag. 102 accounts in particular should be debit and not credit. This PR migrate the incorrect data and add a default naive computation of the tag on newly created accounts. opw-3283746 Enterprise: https://github.com/odoo/enterprise/pull/57531 Forward-Port-Of: odoo/odoo#155677 Forward-Port-Of: odoo/odoo#119485
Description of the issue/feature this PR addresses: Previously, an `ir_actions_report` refactor landed on: - [ ] https://github.com/odoo/odoo/pull/85150 It totally makes sense to create `ir.attachment` from the streams if needed during PDF generation. For some of the projects we still need to override attachment values. This PR provides a hook to prepare attachment values needed for attachments creation during the pdf report generation. Nothing changes in the sense of business logic.
Original PR description
Description of the issue/feature this PR addresses: Previously, an `ir_actions_report` refactor landed on: - [ ] https://github.com/odoo/odoo/pull/85150 It totally makes sense to create `ir.attachment` from the streams if needed during PDF generation. For some of the projects we still need to override attachment values. This PR provides a hook to prepare attachment values needed for attachments creation during the pdf report generation. Nothing changes in the sense of business logic. Ping @smetl @xmo-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153086 Forward-Port-Of: odoo/odoo#138159
To reproduce: ============ - on Planning create new shift - select a template - change the end date -> the end date is reset to the template value Problem: ======== - `end_datetime` and `start_datetime` have the same compute method - `template_id` depends on `start_datetime` and `end_datetime` - so changing `end_datetime` triggers the compute method of `template_id` that will read `start_datetime` - reading `start_datetime` triggers the compute method of `end_datetime`, that will che
Original PR description
To reproduce: ============ - on Planning create new shift - select a template - change the end date -> the end date is reset to the template value Problem: ======== - `end_datetime` and…
To reproduce: ============ - on Planning create new shift - select a template - change the end date -> the end date is reset to the template value Problem: ======== - `end_datetime` and `start_datetime` have the same compute method - `template_id` depends on `start_datetime` and `end_datetime` - so changing `end_datetime` triggers the compute method of `template_id` that will read `start_datetime` - reading `start_datetime` triggers the compute method of `end_datetime`, that will check if `template_id` is set and if so, will take its values ------- why the compute method of `end_datetime` is triggered ? : ------- - `start_datetime` is not protected from recomputing, at this line : https://github.com/odoo/odoo/blob/83aa46a4ab88c0226b1aa1dc36671d3208a0835a/odoo/models.py#L6746 we only protect the fields sent by frontend (only `end_datetime`) - frontend doesn't send `start_datetime` as it was not changed Solution ======== as ORM fix can't be made in stable, we send `start_datetime` in the `onchange` query even if it's unchanged to make sure both fields are protected opw-3693206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155705 Forward-Port-Of: odoo/odoo#154190
Steps to reproduce: - Install Accounting and l10n_ar - Create 2 companies located in Argentina (e.g. Company A & Company B) - Switch to Company A - Go to Accounting settings - Set Fiscal Localization to Argentina (e.g. Argentina - Argentine Generic Chart of Accounts for Excempt individuals) - Switch to Company B - Go to Accounting settings - Set Fiscal Localization to the same Fiscal Localization than Company A (i.e. Argentina - Argentine Generic Chart of Accounts for Excempt individuals
Original PR description
Steps to reproduce: - Install Accounting and l10n_ar - Create 2 companies located in Argentina (e.g. Company A & Company B) - Switch to Company A - Go to Accounting settings - Set Fiscal Localization…
Steps to reproduce: - Install Accounting and l10n_ar - Create 2 companies located in Argentina (e.g. Company A & Company B) - Switch to Company A - Go to Accounting settings - Set Fiscal Localization to Argentina (e.g. Argentina - Argentine Generic Chart of Accounts for Excempt individuals) - Switch to Company B - Go to Accounting settings - Set Fiscal Localization to the same Fiscal Localization than Company A (i.e. Argentina - Argentine Generic Chart of Accounts for Excempt individuals) - Try to install "l10n_ar_withholding" module Issue: A User Error is raised: "Incompatible companies on records: - 'account.tax.repartition.line,1230' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.03.020 SUSS Withholding incurred') belongs to another company. - 'account.tax.repartition.line,1232' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.03.020 SUSS Withholding incurred') belongs to another company. - 'account.tax.repartition.line,1234' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.05.030 Withholdings of Profits incurred') belongs to another company. - 'account.tax.repartition.line,1236' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.05.030 Withholdings of Profits incurred') belongs to another company." Cause: When installing "l10n_ar_withholding" module, each Argentine company is updated with some tax data. These data are "generic" (not linked to any company) and used for each company, but some treatment is performed on them by the first Argentine company, linking them to the account ids of that company. The following companies are then updated with data linked to the first company. Solution: Compute the data for each company. opw-3709819 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154219
This commit resolves the accessibility issue where the search field located within the header was not navigable (see [1]) via keyboard tabbing, rendering it inaccessible to users relying on keyboard navigation. This fix ensures that users can seamlessly navigate to the search field in the header using the keyboard, thereby enhancing the overall accessibility and usability of the website. [1]: https://github.com/odoo/odoo/commit/ac5866a059c345480e246b558eeae1e94aead822 task-3607481
Original PR description
This commit resolves the accessibility issue where the search field located within the header was not navigable (see [1]) via keyboard tabbing, rendering it inaccessible to users relying on keyboard navigation. This fix ensures that users can seamlessly navigate to the search field in the header using the keyboard, thereby enhancing the overall accessibility and usability of the website. [1]: https://github.com/odoo/odoo/commit/ac5866a059c345480e246b558eeae1e94aead822 task-3607481 Forward-Port-Of: odoo/odoo#153197
**Steps to reproduce:** - Go to activity view. - Schedule an activity for one document. (Say 8 docs are available) - Schedule an activity for the second time. (Again 8 docs are available) - Try to schedule an activity for the 3rd time. (Only 2 docs are available) **Issue:** Since 7682286, the existing props of activity model are being passed as params while scheduling an activity. Currently, `["activity_ids", "!=", false]` is being pushed to the domain of activity model in order to dis
Original PR description
**Steps to reproduce:** - Go to activity view. - Schedule an activity for one document. (Say 8 docs are available) - Schedule an activity for the second time. (Again 8 docs are available) - Try to…
**Steps to reproduce:** - Go to activity view. - Schedule an activity for one document. (Say 8 docs are available) - Schedule an activity for the second time. (Again 8 docs are available) - Try to schedule an activity for the 3rd time. (Only 2 docs are available) **Issue:** Since 7682286, the existing props of activity model are being passed as params while scheduling an activity. Currently, `["activity_ids", "!=", false]` is being pushed to the domain of activity model in order to display only those records on which activities have been set. As a result, after you schedule activities more than once, `["activity_ids", "!=", false]` domain gets applied and the list of documents available for scheduling activity is restricted to only those specific records from the third time onwards. **Fix:** This PR passes the 'searchParams' of activity model as params to the 'load' method while scheduling activity, instead of existing props, to ensure that the existing params are applied, as well as all documents are accessible while scheduling activity in `searchCreateDialog` (i.e. ["activity_ids", "!=", false] condition is not added to its domain). Task: [3721750](https://www.odoo.com/web#id=3721750&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#155700 Forward-Port-Of: odoo/odoo#153606
Current behaviour - when we access the daterange picker, it was observed that the `apply` button appeared flatter and was not vertically centered. Expected behaviour - add h-100 on buttons container to ensure they are vertically centered and no longer appear flatter - add cancel button in which action is similar to pressing ESC or clicking outside the popover Task-3624556 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: od
Original PR description
Current behaviour - when we access the daterange picker, it was observed that the `apply` button appeared flatter and was not vertically centered. Expected behaviour - add h-100 on buttons container to ensure they are vertically centered and no longer appear flatter - add cancel button in which action is similar to pressing ESC or clicking outside the popover Task-3624556 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148812
In case where display_name is null, the widget contact crash - AttributeError: 'bool' object has no attribute 'split' On odoo.com we have around 3K of partners that have name with null value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155735
Original PR description
In case where display_name is null, the widget contact crash - AttributeError: 'bool' object has no attribute 'split' On odoo.com we have around 3K of partners that have name with null value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155735
In saas-16.2, the `peppol_endpoint` and `peppol_eas` fields were added on the partner. These fields are used to fill the `<cbc:EndpointID` node. Before that, we had to map every localization specific field to this node. For instance, with the norvegian "Bronnoysund" field (see: [1]). To ensure the node was filled, a constraint was checking the existence of this field. Now that we have the `peppol_endpoint` and `peppol_eas`, we no longer have to require the bronnoysund to be filled. [1]
Original PR description
In saas-16.2, the `peppol_endpoint` and `peppol_eas` fields were added on the partner. These fields are used to fill the `<cbc:EndpointID` node. Before that, we had to map every localization specific field to this node. For instance, with the norvegian "Bronnoysund" field (see: [1]). To ensure the node was filled, a constraint was checking the existence of this field. Now that we have the `peppol_endpoint` and `peppol_eas`, we no longer have to require the bronnoysund to be filled. [1] https://github.com/odoo/odoo/blob/saas-16.1/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L119 opw-3763725 Forward-Port-Of: odoo/odoo#155604
Before this commit, if a SelectionField was used in a kanban view alongside the HandleField (enabling re-sequencing, i.e. drag&drop), the "select" element couldn't be edited. This is because the d&d feature calls preventDefault on almost all "pointerdown" events occuring in the card, and the "pointerdown" event is the one that opens the select. There's no usecase in 17.0, but there's one in master, in the product document kanban view. We fix this in 17.0 which is the version that introduce
Original PR description
Before this commit, if a SelectionField was used in a kanban view alongside the HandleField (enabling re-sequencing, i.e. drag&drop), the "select" element couldn't be edited. This is because the d&d feature calls preventDefault on almost all "pointerdown" events occuring in the card, and the "pointerdown" event is the one that opens the select. There's no usecase in 17.0, but there's one in master, in the product document kanban view. We fix this in 17.0 which is the version that introduced the kanban version of the SelectionField. 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#155827
This commits removes the state validation for `l10n_in_edi` for overseas partner and now state will be only required for e-invoicing for partner having country `India` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154118
Original PR description
This commits removes the state validation for `l10n_in_edi` for overseas partner and now state will be only required for e-invoicing for partner having country `India` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154118
Description of the issue/feature this PR addresses: Add country states for Jordan Current behavior before PR: No country states are imported by default for Jordan Desired behavior after PR is merged: Country states are imported by default for Jordan --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155010
Original PR description
Description of the issue/feature this PR addresses: Add country states for Jordan Current behavior before PR: No country states are imported by default for Jordan Desired behavior after PR is merged: Country states are imported by default for Jordan --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155010
On the analytic widget, when putting an Analytic Account, a floppy disk appear on top of the wizard. This button is used to create a new analytic distribution template. It is confusing for users that thinks that the purpose of the button is to save the analytic distribution. This PR will replace the button to be a link called "New model". Also, this pr will fill some field (partner_id, account_prefix and product_id) if there are populated. task: 3736786 --- I confirm I have sign
Original PR description
On the analytic widget, when putting an Analytic Account, a floppy disk appear on top of the wizard. This button is used to create a new analytic distribution template. It is confusing for users that thinks that the purpose of the button is to save the analytic distribution. This PR will replace the button to be a link called "New model". Also, this pr will fill some field (partner_id, account_prefix and product_id) if there are populated. task: 3736786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155611 Forward-Port-Of: odoo/odoo#153588
How to reproduce: - Install CRM with demo data - Configure one activity type to keep done activities - Go to CRM and chose a kanban column with a green status (only planned activities for that state) - On a lead of that column, add an activity of the type chosen above with a deadline in the past - When going back to the kanban view, that column has the overdue status (red) - Mark that activity as done - Reload the kanban view The kanban column has still the status overdue (red) while t
Original PR description
How to reproduce: - Install CRM with demo data - Configure one activity type to keep done activities - Go to CRM and chose a kanban column with a green status (only planned activities for that state)…
How to reproduce: - Install CRM with demo data - Configure one activity type to keep done activities - Go to CRM and chose a kanban column with a green status (only planned activities for that state) - On a lead of that column, add an activity of the type chosen above with a deadline in the past - When going back to the kanban view, that column has the overdue status (red) - Mark that activity as done - Reload the kanban view The kanban column has still the status overdue (red) while there are no more overdue activity in that state. With this fix, after reloading the kanban view, the header displays the correct status summary. In the example above, the kanban column header is green. Technical note: archived activities were returned when grouping by activity_state because that part was done in SQL and not taking into account the recently added active field. While adding it in the "_read_group_groupby" method, we also add it in "_search_activity_state" to avoid the same problem when searching on activity_state. Note that we don't add flush in those methods using raw SQL so flush is needed in the added test. Task-3732333 Forward-Port-Of: odoo/odoo#153274
In this PR, the mobile/phone number is in sync with the partner if the partner is not there then it will be generated based on the applicant information Task-3635976 Forward-Port-Of: odoo/odoo#150820
Original PR description
In this PR, the mobile/phone number is in sync with the partner if the partner is not there then it will be generated based on the applicant information Task-3635976 Forward-Port-Of: odoo/odoo#150820
Issue: ========= Mass produce wizard sometimes appear under the wrong conditions. When clicking on the 'Unreserve' button and then on the 'Produce All' button if the lot/serial number is not assigned to the product, it incorrectly opens the batch production wizard. Resolution: ============= Adjusted behavior to display a UserError message instead of triggering the batch production wizard in such cases. Steps to Reproduce: ======================== 1. Create a BOM of the main product a
Original PR description
Issue: ========= Mass produce wizard sometimes appear under the wrong conditions. When clicking on the 'Unreserve' button and then on the 'Produce All' button if the lot/serial number is not assigned to the product, it incorrectly opens the batch production wizard. Resolution: ============= Adjusted behavior to display a UserError message instead of triggering the batch production wizard in such cases. Steps to Reproduce: ======================== 1. Create a BOM of the main product and its components tracked by lot. 2. Create and confirm MO. 3. Click on the 'Unreserve' button. 4. Click on the 'Produce All' button. 5. Observe the erroneous opening of the batch production wizard. Expected Result: =================== Upon clicking 'Unreserve' and 'Produce All' buttons, a UserError message should appear if the lot/serial number is not assigned to the product. task-3719189 Forward-Port-Of: odoo/odoo#154314
task_id: 3196107 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#155485 Forward-Port-Of: odoo/odoo#155084
Original PR description
task_id: 3196107 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#155485 Forward-Port-Of: odoo/odoo#155084
Since [1], accessing a live chat as a non member does not subscribe the user to the channel events. This results in the user not receiving any messages linked to this channel. This PR restores the previous behavior as removing it was not intentional. [1]: https://github.com/odoo/odoo/pull/154292 Steps to reproduce the issue: - Open a live chat with demo as a visitor - Connect as admin and go to live chat history - Open the chat with demo and the visitor - The thread is displayed in
Original PR description
Since [1], accessing a live chat as a non member does not subscribe the user to the channel events. This results in the user not receiving any messages linked to this channel. This PR restores the previous behavior as removing it was not intentional. [1]: https://github.com/odoo/odoo/pull/154292 Steps to reproduce the issue: - Open a live chat with demo as a visitor - Connect as admin and go to live chat history - Open the chat with demo and the visitor - The thread is displayed in discuss - Send another message as the visitor - Admin does not receive the message Forward-Port-Of: odoo/odoo#155114 Forward-Port-Of: odoo/odoo#154755
The live chat should always be on top of other elements: some sites that embeds it use z-index for various purpose. Currently, the live chat does not uses z-index, thus is it can be hidden by other elements. This PR sets the z-index to the largest value of a signed integer on a 32 bit system which is the theorical maximum value for this property. opw-3732033 e.g. on squarespace (before)  (aft
Original PR description
The live chat should always be on top of other elements: some sites that embeds it use z-index for various purpose. Currently, the live chat does not uses z-index, thus is it can be hidden by other elements. This PR sets the z-index to the largest value of a signed integer on a 32 bit system which is the theorical maximum value for this property. opw-3732033 e.g. on squarespace (before)  (after)  Forward-Port-Of: odoo/odoo#155903
Issue: ===== Clicking on hex color or rbga in colorpicker will reselect the inital selected text and not the value if hex or rgba. Steps to reproduce the issue: ============================= - Create a note , type anything and apply custom color - When clicking on the hex color code , the cursor is alwyas set back to the text. Origin of the issue: ==================== The behavior was introduced by https://github.com/odoo/odoo/commit/033b49e1a810c3decd8988698620616bd927f6c3 In the
Original PR description
Issue: ===== Clicking on hex color or rbga in colorpicker will reselect the inital selected text and not the value if hex or rgba. Steps to reproduce the issue: ============================= - Create…
Issue: ===== Clicking on hex color or rbga in colorpicker will reselect the inital selected text and not the value if hex or rgba. Steps to reproduce the issue: ============================= - Create a note , type anything and apply custom color - When clicking on the hex color code , the cursor is alwyas set back to the text. Origin of the issue: ==================== The behavior was introduced by https://github.com/odoo/odoo/commit/033b49e1a810c3decd8988698620616bd927f6c3 In the click listener, we always reset the comuted selection wich reselects the original text. When clicking on empty space on the dropdown menu, it happens too but it doesn't matter since the menu closes anyway, but clicking on text input fields that you want to update will be a problem since the menu doesn't close but the text get reselected. Solution: ========= To overcome the problem of resetting when clicking on the dropdown, we first check if the click is on the colorpicker or not, if Yes do nothing and skip this. task-3648629 Forward-Port-Of: odoo/odoo#149480
### Steps to reproduce: - Create two companies: - (ex. Daughter Company) - (ex. Mother Company) - Install **Inventory** app and **stock_dropshipping** module - In the settings of both companies: - enable **Multi-Step Routes** - enable **Dropshipping** option - Using the **Daughter Company**, go to **Routes** > **Dropship** route - When You try to set Company to Daughter Company, it's _**possible**_ to do so even thought the rules belonging to the Dropship route belon
Original PR description
### Steps to reproduce:
- Create two companies:
- (ex. Daughter Company)
- (ex. Mother Company)
- Install **Inventory** app and **stock_dropshipping** module
- In the settings of both companies:
- enable **Multi-Step Routes**
- enable **Dropshipping** option
- Using the **Daughter Company**, go to **Routes** > **Dropship** route
- When You try to set Company to Daughter Company, it's _**possible**_ to do so even thought the rules belonging to the Dropship route belongs to two companies: Daughter Company and Mother Company which is **_NOT_** consistent
### Discuss
- We constraint the route company to always be consistent with the rule(s) company and vice verca
opw-3648535
Forward-Port-Of: odoo/odoo#155484
Forward-Port-Of: odoo/odoo#149894Since the PR [1] changed the rendering engine of qweb, the default "selected" value set on selects field on the form snippet were lost once the page is saved. This commit builds upon the changes made in [this commit] by reinstating the default "selected" value. Steps to replicate: - Go to Website -> Edit. - Drop a Form snippet onto the page. - Click on the 'Company' field. - In Field > Type, opt for "Selection". - Choose option 3 from the options list to establish it as the defau
Original PR description
Since the PR [1] changed the rendering engine of qweb, the default "selected" value set on selects field on the form snippet were lost once the page is saved. This commit builds upon the changes made in [this commit] by reinstating the default "selected" value. Steps to replicate: - Go to Website -> Edit. - Drop a Form snippet onto the page. - Click on the 'Company' field. - In Field > Type, opt for "Selection". - Choose option 3 from the options list to establish it as the default. - Save the modifications. Issue: The expected default value for the selection field is not retained after saving. [1]: https://github.com/odoo/odoo/pull/130467 [this commit]: https://github.com/odoo/odoo/commit/b42e9cc686e7d3ccf82cd091a5dc24028fff8a2b task-3767819 Forward-Port-Of: odoo/odoo#155838
When a crawler (eg Googlebot) come to visit your website, it grants you a limited amount of time and ressources, it's called "Crawler budget". If you have millions of URLs, it won't go through each one of them in a single go. The best you can help those crawler, the better. The sitemap `lastmod` attribute, despite not being fully respected and trusted by crawlers, is one of the way you can still try to help them. For website.pages, it's already done. But for controllers, it's not an easy t
Original PR description
When a crawler (eg Googlebot) come to visit your website, it grants you a limited amount of time and ressources, it's called "Crawler budget". If you have millions of URLs, it won't go through each…
When a crawler (eg Googlebot) come to visit your website, it grants you a limited amount of time and ressources, it's called "Crawler budget". If you have millions of URLs, it won't go through each one of them in a single go.
The best you can help those crawler, the better. The sitemap `lastmod` attribute, despite not being fully respected and trusted by crawlers, is one of the way you can still try to help them.
For website.pages, it's already done. But for controllers, it's not an easy thing to do as we have no way to automatically figure what are the relevant records/fields to look at to know the last update date. For instance, on the event pages, some pages content are mostly stored inside an `ir.ui.view`, but the title, hours etc are part of the event itself.
We can't just say "we take the last write_date of the record", it's wrong in 2 ways:
- The first one I just explained where we wouldn't be able to easily get all the elements part of the page rendering and would miss a possible element write_date, leaving an outdated date in `lastmod`.
- Then, there is another issue (which is more problematic in stable): the `write_date` is often updated for non website related purposes. For instance, on /partners/<partner>, we wouldn't be able to use the write date on odoo.com as the partners shown there (having a grade) are update every weeks in average, because of many fields, for instance: commission_plan_id, partner_weight, grade_id, ...
Still, there is a quick win possible in stable about forum posts which are not impacted by the 2 issues explained above:
- There is a dedicated `last_activity_date` field which is updated only when relevant information are modified. We can ensure to show a date which is not updated too frequently for no reason.
- All the forum.post information displayed on the page are stored inside the forum.post itself.
This commit is thus adding the `lastmod` on forum.post URLs in the sitemap in hope of not making Google waste time on (very) old posts.
Note: the `lastmod` has to be trustworthy and correct, if you set wrong
or outdated info inside it, Google won't trust you/it anymore.
Forward-Port-Of: odoo/odoo#155197Not a guaranteed fix (not reproducible 1500 attempts), but applying standard fix for `step` failing to use the new step helper. runbot-54560 Forward-Port-Of: odoo/odoo#155925
Original PR description
Not a guaranteed fix (not reproducible 1500 attempts), but applying standard fix for `step` failing to use the new step helper. runbot-54560 Forward-Port-Of: odoo/odoo#155925
When a company's annual inventory day is selected which is higher than the number of days in that month, there are already safeguards in the feature to ensure the latest day possible for that month is selected. Unfortunately the related test forgot to take this into account for leap years, so this commit modifies it to test for this expected safeguard. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155841
Original PR description
When a company's annual inventory day is selected which is higher than the number of days in that month, there are already safeguards in the feature to ensure the latest day possible for that month is selected. Unfortunately the related test forgot to take this into account for leap years, so this commit modifies it to test for this expected safeguard. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155841
Commit 14abe7acb11 (PR #123816) introduced default tax closing accounts for localizations that were so far missing them. However, the mechanism for specifying the default tax closing accounts changed in 16.2: they must now be specified on the tax groups. This was not correctly done in the fw-port, so we fix this in this commit. taskid: 3524378 Forward-Port-Of: odoo/odoo#155911 Forward-Port-Of: odoo/odoo#155074
Original PR description
Commit 14abe7acb11 (PR #123816) introduced default tax closing accounts for localizations that were so far missing them. However, the mechanism for specifying the default tax closing accounts changed in 16.2: they must now be specified on the tax groups. This was not correctly done in the fw-port, so we fix this in this commit. taskid: 3524378 Forward-Port-Of: odoo/odoo#155911 Forward-Port-Of: odoo/odoo#155074
Before this PR, the `bus subscription is refreshed when channel is left` test was sometimes failing. This actually reveals a real issue: if a channel is joined a leave very quickly, the bus subscription is not updated. This occurs because we rely on the last subscription made and the one that should be made to detect if channels differ. Since the `updateBusSubscription` method is debounced, we can miss information. This PR replaces the complicated `updateBusSubscription` method by a `onAdd
Original PR description
Before this PR, the `bus subscription is refreshed when channel is left` test was sometimes failing. This actually reveals a real issue: if a channel is joined a leave very quickly, the bus subscription is not updated. This occurs because we rely on the last subscription made and the one that should be made to detect if channels differ. Since the `updateBusSubscription` method is debounced, we can miss information. This PR replaces the complicated `updateBusSubscription` method by a `onAdd/onDelete`. This is much more reliable and more efficient since there is no need to walk through every channel to detect changes. This PR also remove a test that was redundant that the failing one. fixes runbot-55292,57645,56232 Forward-Port-Of: odoo/odoo#155804 Forward-Port-Of: odoo/odoo#155720
Steps to reproduce the issue: - have an employee with an allocation with an end date - remove the employee's calendar - go on his dashboard - his remaining leaves amount is 0 This commit implements a new method on the resource mixin to fetch a calendar for the record even though it might not have one. The default behaviour is to fall back on the company's calendar to ensure a value. This is overrided in the `hr_contract` module so that the calendar of the contract is prioritized. task-
Original PR description
Steps to reproduce the issue: - have an employee with an allocation with an end date - remove the employee's calendar - go on his dashboard - his remaining leaves amount is 0 This commit implements a new method on the resource mixin to fetch a calendar for the record even though it might not have one. The default behaviour is to fall back on the company's calendar to ensure a value. This is overrided in the `hr_contract` module so that the calendar of the contract is prioritized. task-3609738 Forward-Port-Of: odoo/odoo#155753 Forward-Port-Of: odoo/odoo#144418
Commit [1] refactored the tabs snippets options, in doing so, it introduced a selector which could also target a tabs snippet from within its own tab. This leads to very weird behaviour on clone. Commit [2] introduced a new MultipleItems abstract option, and with it, added a selector which could cause the same issue as above. This commit fixes this by properly restricting the selectors to the direct children. Steps to reproduce: - Create a new web page - Add a "Tabs" block - Put some
Original PR description
Commit [1] refactored the tabs snippets options, in doing so, it introduced a selector which could also target a tabs snippet from within its own tab. This leads to very weird behaviour on clone.…
Commit [1] refactored the tabs snippets options, in doing so, it introduced a selector which could also target a tabs snippet from within its own tab. This leads to very weird behaviour on clone. Commit [2] introduced a new MultipleItems abstract option, and with it, added a selector which could cause the same issue as above. This commit fixes this by properly restricting the selectors to the direct children. Steps to reproduce: - Create a new web page - Add a "Tabs" block - Put some text in each tab in other to identify which text belongs to which tab - In the first tab, add a new "Tabs" block, so that you will have tabs and sub-tabs - Put some text in sub tabs in order to identify which text belongs to which sub tab - try to add a new tab in your main tab block => look at the beautiful mess it creates. [1]: https://github.com/odoo/odoo/commit/7572cc150d5469af92138533a024cffbd57d878e [2]: https://github.com/odoo/odoo/commit/ebfa28638b47a7be45b96d561bdf144c3487f366 opw-3730155 Forward-Port-Of: odoo/odoo#154695
Prior to this commit, in cases with a large number of customers in the database, we loaded a limited number of customers. This could potentially exclude the PoS user partner, causing issues during cash in/out operations. This commit ensures the PoS user partner is always loaded to prevent such issues. opw-3767023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155382
Original PR description
Prior to this commit, in cases with a large number of customers in the database, we loaded a limited number of customers. This could potentially exclude the PoS user partner, causing issues during cash in/out operations. This commit ensures the PoS user partner is always loaded to prevent such issues. opw-3767023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155382
Before this commit, if multiple employees were enabled in a session, performing cash in/out operations would cause an error. This was due to a recent refactor where the 'work_contact_id' was changed to an object. opw-3764015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155556
Original PR description
Before this commit, if multiple employees were enabled in a session, performing cash in/out operations would cause an error. This was due to a recent refactor where the 'work_contact_id' was changed to an object. opw-3764015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155556
Versions -------- - 17.0+ Steps ----- 1. Use iOS app; 2. click on red dot on top; 3. click check in. Issue ----- Nothing happens. Cause ----- The iOS app cannot request the user's location. Commit 1acd0b6c5d7ce292f670882f6ff48a2ff9db05f0 attempted to fix this by first checking whether `navigator.geolocation` exists, but the cause is likely with its `getCurrentPosition` method instead of its existence. Solution -------- Instead of checking for `navigator.geolocation`, u
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use iOS app; 2. click on red dot on top; 3. click check in. Issue ----- Nothing happens. Cause ----- The iOS app cannot request the user's location. Commit 1acd0b6c5d7ce292f670882f6ff48a2ff9db05f0 attempted to fix this by first checking whether `navigator.geolocation` exists, but the cause is likely with its `getCurrentPosition` method instead of its existence. Solution -------- Instead of checking for `navigator.geolocation`, use `isIosApp` to skip the geolocation part when using the iOS app. opw-3734385 Forward-Port-Of: odoo/odoo#155932 Forward-Port-Of: odoo/odoo#155588
If booth exists for this event, bot will discover it via crawling. Don't need to ask to crawler to check for each event if a booth exists. 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#156022
Original PR description
If booth exists for this event, bot will discover it via crawling. Don't need to ask to crawler to check for each event if a booth exists. 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#156022
Steps to reproduce: - Open POS session - Sell a consumable product in POS (no invoice) - Close session Bug: an expense entry is added to the Account move opw-3705156 Forward-Port-Of: odoo/odoo#153657
Original PR description
Steps to reproduce: - Open POS session - Sell a consumable product in POS (no invoice) - Close session Bug: an expense entry is added to the Account move opw-3705156 Forward-Port-Of: odoo/odoo#153657
Problem --------- Due to commit 8d77045b46a1b4a9d7fffd1111e53749d51d81e2, restrictions were added to taxes that were used in transactions. However, this behavior worsens user experience; users that would like to modify a tax would have to duplicate it, update the duplicated version and modify the tax usage where necessary. For such reason, this process is being reverted (we keep the tracking of the modification). The tracking of repartition lines now also includes the sequence of the li
Original PR description
Problem --------- Due to commit 8d77045b46a1b4a9d7fffd1111e53749d51d81e2, restrictions were added to taxes that were used in transactions. However, this behavior worsens user experience; users that…
Problem --------- Due to commit 8d77045b46a1b4a9d7fffd1111e53749d51d81e2, restrictions were added to taxes that were used in transactions. However, this behavior worsens user experience; users that would like to modify a tax would have to duplicate it, update the duplicated version and modify the tax usage where necessary. For such reason, this process is being reverted (we keep the tracking of the modification). The tracking of repartition lines now also includes the sequence of the lines since it is not restricted anymore. Furthermore, `_message_log_repartition_lines` has been updated to log messages when new repartition lines are added or repartition lines are removed. It also has been update to track changes of lines by comparing their position in the tax (rel. sequence) and not their IDs. Doing so allows to remove unnecessary logging when, for example, users remove a repartition line and immediately add a new one similar to the one deleted. It also allows to not log reordering event of two similar lines. original-commit: 8d77045b46a1b4a9d7fffd1111e53749d51d81e2 task-3450002 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155055
When QWeb templates became cached and compiled in [1], the list of default cache key elements did not contain `inherit_branding_auto` (but it included the old `inherit_branding`). Because of this the cache was shared between restricted editors and public users, which could lead to problems such as missing the branding on edited fields. Steps to reproduce: - Use a single browser instance and do not log any user out. - Start with `website_sale`. - Make "demo" user a restricted editor and
Original PR description
When QWeb templates became cached and compiled in [1], the list of default cache key elements did not contain `inherit_branding_auto` (but it included the old `inherit_branding`). Because of this the cache was shared between restricted editors and public users, which could lead to problems such as missing the branding on edited fields. Steps to reproduce: - Use a single browser instance and do not log any user out. - Start with `website_sale`. - Make "demo" user a restricted editor and a sales administrator. - Connect on 127.0.0.1 as "demo" and go to a product website page. - Go to 127.0.0.2 as a visitor and go to the same product page. => The product name field of the visitor page was branded. If you swap the last two steps, the "demo" user's page lacks the branding. [1]: https://github.com/odoo/odoo/commit/7ede9bcb2de9d52994b3a6fcb84edc3f81d60284 task-3482439 Forward-Port-Of: odoo/odoo#155264
Currently, if you install the Mexican localization, you are no longer able to create a new account in the chart of accounts. ### Steps to reproduce * install `l10n_mx` * attempt to create a new account in the chart of accounts You should be met with a traceback: `TypeError: AccountAccount.create() missing 1 required positional argument: 'vals_list'` ### Cause The `@api.model` and `@api.model_create_multi` decorators in indicate that a method is intended to operate at the model
Original PR description
Currently, if you install the Mexican localization, you are no longer able to create a new account in the chart of accounts. ### Steps to reproduce * install `l10n_mx` * attempt to create a new…
Currently, if you install the Mexican localization, you are no longer able to create a new account in the chart of accounts. ### Steps to reproduce * install `l10n_mx` * attempt to create a new account in the chart of accounts You should be met with a traceback: `TypeError: AccountAccount.create() missing 1 required positional argument: 'vals_list'` ### Cause The `@api.model` and `@api.model_create_multi` decorators in indicate that a method is intended to operate at the model level rather than on specific record instances. Without these decorators, the system defaults to treating methods as if they are meant to be executed on the record level. This distinction significantly impacts how methods are invoked through RPC. In RPC scenarios, Odoo's default expectation for record-level methods is that the RPC call will include the IDs of the records to which the method applies, alongside any actual method arguments necessary for the operation. Here, `create()` is called through RPC, as a model-level method (i.e, without record IDs). This makes sense because `create()` is always a model-level method. However, in our case, create is a record-level method, so the system expects the RPC call to contain record IDs. This mismatch produces a traceback. Issue introduced by 858bf9efdd9fcc29a73336863a51227c15cc19f0 opw-3772520 opw-3772469 opw-3772287 opw-3771854 opw-3771361 Forward-Port-Of: odoo/odoo#155848
At the moment, QRIS is not returning an error message when you try to generate a QR code with a country that is not Indonesia. It will instead skip all checks and return no errors. This fix will ensure that we arise an error if we try to generate the QR code with a bank account from another country. Task id # 3758668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154958
Original PR description
At the moment, QRIS is not returning an error message when you try to generate a QR code with a country that is not Indonesia. It will instead skip all checks and return no errors. This fix will ensure that we arise an error if we try to generate the QR code with a bank account from another country. Task id # 3758668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154958
## Description Deleting planning slots can be slow on some databases that make heavy usage of the Timesheet/WorkEntries from shifts feature and/or they have large tables for their `account.analytic.line` and/or `hr.work. entry`. It can be especially felt when deleting all recurrences of a shifts. This is due to the missing indexes on the FKey to the `planning.slot` model on large models. Without an index on the FKey, deleting a `planning.slot` will trigger Seq.Scans on the tables that referenc
Original PR description
## Description Deleting planning slots can be slow on some databases that make heavy usage of the Timesheet/WorkEntries from shifts feature and/or they have large tables for their `account.analytic.line` and/or `hr.work. entry`. It can be especially felt when deleting all recurrences of a shifts. This is due to the missing indexes on the FKey to the `planning.slot` model on large models. Without an index on the FKey, deleting a `planning.slot` will trigger Seq.Scans on the tables that references the `planning.slot` model to set the field to NULL or trigger the SQL `ON DELETE` constrains. ## Fix Add the missing indexes. Partial on nulls because it's a sparse relationship. ## Reference task-3747131 Forward-Port-Of: odoo/enterprise#56681
Steps to reproduce: 1. set up a shipping method with UPS rest module 2. enable "generate return label" on the shipping method 3. make a shipping and validate it A return label will be generated that has the customer's address as the receiver and the seller's address as the sender. This is conceptually wrong as the return label will be used to ship from the customer to the seller. This commit uses the correct addresses when generating labels. Also the name of the arguments are added whe
Original PR description
Steps to reproduce: 1. set up a shipping method with UPS rest module 2. enable "generate return label" on the shipping method 3. make a shipping and validate it A return label will be generated that has the customer's address as the receiver and the seller's address as the sender. This is conceptually wrong as the return label will be used to ship from the customer to the seller. This commit uses the correct addresses when generating labels. Also the name of the arguments are added when calling `_send_shipping` method for better readability. opw-3756731 Forward-Port-Of: odoo/enterprise#57477 Forward-Port-Of: odoo/enterprise#57037
The annual changes to the intrastat code lists have occured. In order to synchronise with these new standards, we have to add the new codes, and remove the old ones. This commit adds the new codes in into the relevant csv. We also add expiry dates for the removed codes, and start dates for the new codes. In forward ports, these should be added directly on the account.intrastat.code.csv (since the modules account_intrastat and account_intrastat_expiry were merged after v15.0) One of the cod
Original PR description
The annual changes to the intrastat code lists have occured. In order to synchronise with these new standards, we have to add the new codes, and remove the old ones. This commit adds the new codes in into the relevant csv. We also add expiry dates for the removed codes, and start dates for the new codes. In forward ports, these should be added directly on the account.intrastat.code.csv (since the modules account_intrastat and account_intrastat_expiry were merged after v15.0) One of the codes (50072060) has a supplementary unit, so we add that to the relevant dictionary, though in the forward ports this will be added directly in the data. task-id: 3747808 Forward-Port-Of: odoo/enterprise#57633 Forward-Port-Of: odoo/enterprise#57124
This commit ensures that non-UK companies using a UK fiscal position are correctly handled, using the foreign VAT when connecting and sending reports to the HMRC. Additionally, the need to input the VAT without the 'GB' prefix has been eliminated by automatically stripping the prefix before sending. task-3765235 Forward-Port-Of: odoo/enterprise#57570
Original PR description
This commit ensures that non-UK companies using a UK fiscal position are correctly handled, using the foreign VAT when connecting and sending reports to the HMRC. Additionally, the need to input the VAT without the 'GB' prefix has been eliminated by automatically stripping the prefix before sending. task-3765235 Forward-Port-Of: odoo/enterprise#57570
**Current behavior:** Selecting the pre-loaded 'My Team' filter from the search bar in the Timesheets view grid will list, in addition to employees managed by the current user, employees who have no assigned manager nor time sheet approver. **Expected behavior:** This filter will list exclusively employees who the current user is either the manager of or is the time sheet approver of. **Steps to reproduce:** 1. In the Timesheets application, select the My Team filter **Cause of the i
Original PR description
**Current behavior:** Selecting the pre-loaded 'My Team' filter from the search bar in the Timesheets view grid will list, in addition to employees managed by the current user, employees who have no assigned manager nor time sheet approver. **Expected behavior:** This filter will list exclusively employees who the current user is either the manager of or is the time sheet approver of. **Steps to reproduce:** 1. In the Timesheets application, select the My Team filter **Cause of the issue:** The filter's domain includes these aforementioned un-managed employees. **Fix:** Remove that part of the domain. This commit is a partial revision to one of the changes made by https://github.com/odoo/enterprise/commit/60dc8c38519b75b5383a54e923135d557e3737e0 (see log chatter on Odoo for associated ticket for justification) opw-3708825 Forward-Port-Of: odoo/enterprise#57049
Add the Bank Negara Malaysia as a live exchange rate service for malaysia. This is common practice in the country to get exchange rates from it. Task id # 3724397 Forward-Port-Of: odoo/enterprise#57694 Forward-Port-Of: odoo/enterprise#56030
Original PR description
Add the Bank Negara Malaysia as a live exchange rate service for malaysia. This is common practice in the country to get exchange rates from it. Task id # 3724397 Forward-Port-Of: odoo/enterprise#57694 Forward-Port-Of: odoo/enterprise#56030
### [I18N] l10n_fr_reports: add tax rounding terms A few of translations relating to 03ce6ce were not included with the original commit. This commit adds the terms to the l10n_fr_reports.pot file, and the translations to the fr.po file. Thank you Antoine (andu) for the Frenchification of the terms. task-id: 3717388 ### [I18N] l10n_fr_reports: restructure po/pot files Add the missing terms to the pot file. When the terms are missing from the pot file, but present in the po file,
Original PR description
### [I18N] l10n_fr_reports: add tax rounding terms A few of translations relating to 03ce6ce were not included with the original commit. This commit adds the terms to the l10n_fr_reports.pot file, and the translations to the fr.po file. Thank you Antoine (andu) for the Frenchification of the terms. task-id: 3717388 ### [I18N] l10n_fr_reports: restructure po/pot files Add the missing terms to the pot file. When the terms are missing from the pot file, but present in the po file, they get marked as "obsolete". This happens during the merge function that is called within tools/translate.py. In order to avoid this, the pot and po files have been re-generated and restructured in order to make future additions easier to merge. Forward-Port-Of: odoo/enterprise#57718 Forward-Port-Of: odoo/enterprise#56590
Steps to reproduce: ------------------- - go to Sales; - click on a sale order with tickets assigned to it; - click on the "Tickets" smart button; - group by stage. Issue: ------ A traceback appears. Cause: ------ The query formed is incorrect. We are using a Query object in the domain instead of the team id. Which has been placed in context beforehand. Solution: --------- Place the team id in the context. Note: ----- This will automatically be converted to a list if ne
Original PR description
Steps to reproduce: ------------------- - go to Sales; - click on a sale order with tickets assigned to it; - click on the "Tickets" smart button; - group by stage. Issue: ------ A traceback appears. Cause: ------ The query formed is incorrect. We are using a Query object in the domain instead of the team id. Which has been placed in context beforehand. Solution: --------- Place the team id in the context. Note: ----- This will automatically be converted to a list if necessary when generating the query with a domain using the `IN` operator (relation). opw-3759882 Forward-Port-Of: odoo/enterprise#57798 Forward-Port-Of: odoo/enterprise#57502
Make sure to use the resource calendar of the employee. Indeed, it is possible that the resource calendar set on the user is different than the one on the employee. Which can leads to a traceback if the resource calendar was not in the unavailabilities_by_calendar. As we base previous computation on employee, we also use the employee here. task-3698586 Forward-Port-Of: odoo/enterprise#57712
Original PR description
Make sure to use the resource calendar of the employee. Indeed, it is possible that the resource calendar set on the user is different than the one on the employee. Which can leads to a traceback if the resource calendar was not in the unavailabilities_by_calendar. As we base previous computation on employee, we also use the employee here. task-3698586 Forward-Port-Of: odoo/enterprise#57712
Due to a change in the base UBL template, the `<PriceAmount>` is no longer rounded to the number of decimals of the product price. Since the SUNAT only accepts numbers with a maximum of 10 decimals, we round the computed product price for Peru specifically to 10 decimals. [Issue reported by Fernando Vazquez (fvz)](https://www.odoo.com/web#id=3415758&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#57578
Original PR description
Due to a change in the base UBL template, the `<PriceAmount>` is no longer rounded to the number of decimals of the product price. Since the SUNAT only accepts numbers with a maximum of 10 decimals, we round the computed product price for Peru specifically to 10 decimals. [Issue reported by Fernando Vazquez (fvz)](https://www.odoo.com/web#id=3415758&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#57578
If you create an upsell for a subscription, when the upsell is confirmed the non-recurring products are copied into the parent subscription which trigger the creation of 2 delivery orders (one on upsell, one on parent sub) and also as there are 2 SOL in the report the product is considered sold twice. This commit fixes this by not creating lines for non recurring products in _subscription_update_line_data. task-3689908 Forward-Port-Of: odoo/enterprise#55613
Original PR description
If you create an upsell for a subscription, when the upsell is confirmed the non-recurring products are copied into the parent subscription which trigger the creation of 2 delivery orders (one on upsell, one on parent sub) and also as there are 2 SOL in the report the product is considered sold twice. This commit fixes this by not creating lines for non recurring products in _subscription_update_line_data. task-3689908 Forward-Port-Of: odoo/enterprise#55613
In some countries the journal report is used as a section of the tax report to provide details about the computed tax amounts. One such detail is the split between the deductible and non-deductible part of the tax computed. In order to provide these details, we add two new columns to the tax overview in the journal report that indicate the amounts of the tax that are deductible or non-deductible. [task-3696656](https://www.odoo.com/web#id=3696656&cids=1&menu_id=4720&action=333&active_id
Original PR description
In some countries the journal report is used as a section of the tax report to provide details about the computed tax amounts. One such detail is the split between the deductible and non-deductible part of the tax computed. In order to provide these details, we add two new columns to the tax overview in the journal report that indicate the amounts of the tax that are deductible or non-deductible. [task-3696656](https://www.odoo.com/web#id=3696656&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#57657 Forward-Port-Of: odoo/enterprise#55010
Fix test after Community change, 1xxx accounts should have been debit tag, thus Natur='D'. Community: https://github.com/odoo/odoo/pull/119485 Forward-Port-Of: odoo/enterprise#57666 Forward-Port-Of: odoo/enterprise#57531
Original PR description
Fix test after Community change, 1xxx accounts should have been debit tag, thus Natur='D'. Community: https://github.com/odoo/odoo/pull/119485 Forward-Port-Of: odoo/enterprise#57666 Forward-Port-Of: odoo/enterprise#57531
**Before:** In the modified code, parts of the PivotController have been moved to PivotRenderer. However, the 'button template' is not extended in the pivot view, leading to issues rendering the validate button. **After:** By extending the correct class (PivotRenderer instead of PivotController) in the `TimesheetValidationPivotController`, we now have access to methods that were previously unavailable. Additionally, extending the `buttonTemplate` allows us to access the validate button, res
Original PR description
**Before:** In the modified code, parts of the PivotController have been moved to PivotRenderer. However, the 'button template' is not extended in the pivot view, leading to issues rendering the validate button. **After:** By extending the correct class (PivotRenderer instead of PivotController) in the `TimesheetValidationPivotController`, we now have access to methods that were previously unavailable. Additionally, extending the `buttonTemplate` allows us to access the validate button, resolving the rendering issue. This modification ensures that the TimesheetValidationPivotController now extends PivotRenderer, allowing it to access the necessary methods and resolve the rendering issue for the validate button. **Task**-3623493 Forward-Port-Of: odoo/enterprise#57656 Forward-Port-Of: odoo/enterprise#53165
Starshipit is the leading provider of integrated and automated fulfillment solutions for online businesses integrating with the leading carriers used in Australia and New Zealand, such as Australia Post, DHL, Aramex, CouriersPlease, and more This PR will add support to integrate with starshipit directly in Odoo, providing rates and shipping for users who need it. Task ID # 3041982 Forward-Port-Of: odoo/enterprise#57654 Forward-Port-Of: odoo/enterprise#47569
Original PR description
Starshipit is the leading provider of integrated and automated fulfillment solutions for online businesses integrating with the leading carriers used in Australia and New Zealand, such as Australia Post, DHL, Aramex, CouriersPlease, and more This PR will add support to integrate with starshipit directly in Odoo, providing rates and shipping for users who need it. Task ID # 3041982 Forward-Port-Of: odoo/enterprise#57654 Forward-Port-Of: odoo/enterprise#47569
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3: notification order 3, exclusive, has a responsible Obviously, each validation should be done by a different user (and not an admin), because all rules are exclusive. Also, each rule has a responsible in the example below, but really only rule 3's is part of the real use case and is the object of the fix.
Original PR description
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3:…
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3: notification order 3, exclusive, has a responsible Obviously, each validation should be done by a different user (and not an admin), because all rules are exclusive. Also, each rule has a responsible in the example below, but really only rule 3's is part of the real use case and is the object of the fix. Validate 0: 1 and 2 receives an activity Validate 1: activity of 1 is removed validate 2: activity of 2 is removed, 3 receives an activity (<=====) Before this commit, 3 did not receive an activity. This was because, in this flow the rule 3 is evaluated for validation because every rule before it had been validated. However, in that part of the code, we ensure that no rule below it in notification order is not validated, but we do it in the context of the current user. So, when validating rule 3, we couldn't see the validations for at least of previous rule that another part of the code had seen before. After this commit, the rule 3 receives an activity, and the whole flow works as expected. opw-3752133 Forward-Port-Of: odoo/enterprise#57644 Forward-Port-Of: odoo/enterprise#57604
Fix the fetching of the appointment types which was triggering an Access Error for public and portal users as they didn't have the read access on the appointment.type model. Instead of calling the search method directly without sudo to apply the user access rules, rolling back to the 17.0 version where the search was performed using a sudo and the resulting recordset was then filtered based on the user access rules. This guarantees an access to the appointment.type model and always returns th
Original PR description
Fix the fetching of the appointment types which was triggering an Access Error for public and portal users as they didn't have the read access on the appointment.type model. Instead of calling the search method directly without sudo to apply the user access rules, rolling back to the 17.0 version where the search was performed using a sudo and the resulting recordset was then filtered based on the user access rules. This guarantees an access to the appointment.type model and always returns the appropriate recordset. related commit: 05a1080a66cefc1b0724e23c72dd2bf06343e4e3 Task-3765016 Forward-Port-Of: odoo/enterprise#57374
**Steps to reproduce:** 1- Install Helpdesk, Website module 2- Login using portal user 3- Navigate to tickest and search by assignees **Current behavior before PR:** When searching by assignees using a portal user you will not get any results. This is happening because the portal user seems to not have the access to search in 'res.users' so when the orm parse the user_id assigned to the ticket to a name it will not be able to parse it for the portal user. **Desired behavior after PR
Original PR description
**Steps to reproduce:** 1- Install Helpdesk, Website module 2- Login using portal user 3- Navigate to tickest and search by assignees **Current behavior before PR:** When searching by assignees using a portal user you will not get any results. This is happening because the portal user seems to not have the access to search in 'res.users' so when the orm parse the user_id assigned to the ticket to a name it will not be able to parse it for the portal user. **Desired behavior after PR is merged:** We search first for the users that are matching the search key in 'res.users' using 'sudo()' then get their ids and search in 'helpdesk.ticket' using those ids opw-3719387 Forward-Port-Of: odoo/enterprise#56716
Based on last runbot counters Forward-Port-Of: odoo/enterprise#57731
Original PR description
Based on last runbot counters Forward-Port-Of: odoo/enterprise#57731
the headers of the xlsx report were not translated this commit fixes that by adding the missing translations into the controller task-3718923 Forward-Port-Of: odoo/enterprise#55761
Original PR description
the headers of the xlsx report were not translated this commit fixes that by adding the missing translations into the controller task-3718923 Forward-Port-Of: odoo/enterprise#55761
steps to reproduce: 1. Go to approvals with no rights 2. create a new approval request 3. add an approver -> the approver cannot be selected because the line is readonly expected behavior: the approver can be selected Explaination of the issue: The field can_edit_user_id is set to False when no user is selected because when you add a line no user is selected by default. behavior after the fix: the approver can be selected task-3602617 Forward-Port-Of: odoo/enterprise#54822
Original PR description
steps to reproduce: 1. Go to approvals with no rights 2. create a new approval request 3. add an approver -> the approver cannot be selected because the line is readonly expected behavior: the approver can be selected Explaination of the issue: The field can_edit_user_id is set to False when no user is selected because when you add a line no user is selected by default. behavior after the fix: the approver can be selected task-3602617 Forward-Port-Of: odoo/enterprise#54822
### Cause When validating an address, we take for granted that Avatax returns latitude and longitude, while it's optional. We started using Avatax's returned geocoordinates in `saas-16.2`, https://github.com/odoo/enterprise/commit/282b878d8c441aaf546e6ce5d5c7dbe9f831d5b2 ### Steps to reproduce * install `account_avatax` * in the settings, enable and setup Avatax. Make sure to enable Address Validation. * create a partner with the following address: - Street 1: 999 Canada Pl - Cit
Original PR description
### Cause When validating an address, we take for granted that Avatax returns latitude and longitude, while it's optional. We started using Avatax's returned geocoordinates in `saas-16.2`, https://github.com/odoo/enterprise/commit/282b878d8c441aaf546e6ce5d5c7dbe9f831d5b2 ### Steps to reproduce * install `account_avatax` * in the settings, enable and setup Avatax. Make sure to enable Address Validation. * create a partner with the following address: - Street 1: 999 Canada Pl - City: Vancouver - State: British Columbia (CA) - Zip: V6C 3B5 - Country: Canada * click the 'Validate' button, next to the country You should be met with a traceback: `KeyError: 'latitude'` Ticket link: https://www.odoo.com/web#model=project.task&id=3752775 opw-3752775 Forward-Port-Of: odoo/enterprise#57612
Bug === Currently, we can not login to Instagram, because a permission is missing. This commit adds the missing permission, and we upgrade from 10.0 to 17.0. Task-3761561 Forward-Port-Of: odoo/enterprise#57693 Forward-Port-Of: odoo/enterprise#57218
Original PR description
Bug === Currently, we can not login to Instagram, because a permission is missing. This commit adds the missing permission, and we upgrade from 10.0 to 17.0. Task-3761561 Forward-Port-Of: odoo/enterprise#57693 Forward-Port-Of: odoo/enterprise#57218
This commit(https://github.com/odoo/enterprise/commit/217594fe8ba00329b3eb5c68e3eca3b556127cde) removed a filter on products that are services and that shouldn't be in the intrastat report (for now). This commit adds again this filter. opw-3763306 opw-3764904 opw-3730803 Forward-Port-Of: odoo/enterprise#57701 Forward-Port-Of: odoo/enterprise#57607
Original PR description
This commit(https://github.com/odoo/enterprise/commit/217594fe8ba00329b3eb5c68e3eca3b556127cde) removed a filter on products that are services and that shouldn't be in the intrastat report (for now). This commit adds again this filter. opw-3763306 opw-3764904 opw-3730803 Forward-Port-Of: odoo/enterprise#57701 Forward-Port-Of: odoo/enterprise#57607
At the moment, when auto sending the customer statement, it will always send the values for the current month. This means that if you send it bi-weekly, the first sending will contain the values for the first two weeks of the month, while the second will contain the values for the whole month. But this does not work well when you can have custom frequency, as there will be cases, where you will want the values of the last x weeks/months, or when a two-week period is between two months.
Original PR description
At the moment, when auto sending the customer statement, it will always send the values for the current month. This means that if you send it bi-weekly, the first sending will contain the values for the first two weeks of the month, while the second will contain the values for the whole month. But this does not work well when you can have custom frequency, as there will be cases, where you will want the values of the last x weeks/months, or when a two-week period is between two months. To have a more flexible system, we will now compute the start date by taking into account the set frequency. The end date of the statement will always be the day before the sending date, while the start date will be the end date minus the frequency (so minus two weeks if set to bi-weekly). Task id # 3713352 Forward-Port-Of: odoo/enterprise#56893
- Adds an option/filter to display amount in different units, i.e, 'decimals', 'units', 'thousands', 'lakhs' and 'millions'. - Makes 'format_value' a private python method and creates a new public 'format_value' method that should be called from the client. This change was made because we can not pass records from the client to the server. For example for currency, we can pass the currency_id to the server, but then we need to fetch the currency before continuing. task-3626894 Forwar
Original PR description
- Adds an option/filter to display amount in different units, i.e, 'decimals', 'units', 'thousands', 'lakhs' and 'millions'. - Makes 'format_value' a private python method and creates a new public 'format_value' method that should be called from the client. This change was made because we can not pass records from the client to the server. For example for currency, we can pass the currency_id to the server, but then we need to fetch the currency before continuing. task-3626894 Forward-Port-Of: odoo/enterprise#56817 Forward-Port-Of: odoo/enterprise#55218