Sunday, September 1, 2024
16 changes · saas-17.4
Miscellaneous changes
Before this commit, the user was not able to see the caret icon to indicate autocomplete dropdown in many2one and many2many values. Steps to reproduce: - open documents and then navigate to actions from the configuration. - click on any action and add a rule for any many2many field. - then try to add many2many values to that rule. Observed behavior: No caret is displayed when adding the many2many values. Expected behavior: Now a caret is displayed on hover indicating a dropdown
Original PR description
Before this commit, the user was not able to see the caret icon to indicate autocomplete dropdown in many2one and many2many values. Steps to reproduce: - open documents and then navigate to actions from the configuration. - click on any action and add a rule for any many2many field. - then try to add many2many values to that rule. Observed behavior: No caret is displayed when adding the many2many values. Expected behavior: Now a caret is displayed on hover indicating a dropdown while adding many2many and many2one values. After this commit, the user will be able to see the caret icon to indicate autocomplete dropdown in many2one and many2many values. Task-3777903 Forward-Port-Of: odoo/odoo#178263 Forward-Port-Of: odoo/odoo#158292
In case a user logs an internal note on an invoice and pings another internal user, who happens to manage notifications by email, the link to the document inside the email was directing to the portal instead of the backend. This happens because of the override of _notify_get_groups in the account module adds an extra recipient group 'additional_intended_recipient' in the first position of the groups list. This group is based on 'portal_customer' but its validation function will evaluate to Tr
Original PR description
In case a user logs an internal note on an invoice and pings another internal user, who happens to manage notifications by email, the link to the document inside the email was directing to the portal…
In case a user logs an internal note on an invoice and pings another internal user, who happens to manage notifications by email, the link to the document inside the email was directing to the portal instead of the backend. This happens because of the override of _notify_get_groups in the account module adds an extra recipient group 'additional_intended_recipient' in the first position of the groups list. This group is based on 'portal_customer' but its validation function will evaluate to True for internal users. In any case, the recipient group for user must be considered first as only internal user will be validated through its function. The recipient group portal_customer can then be added in the second position, ie after user but before portal, and the eventual additional_intended_recipient can be set before portal_customer as it is the case now. Description of the issue/feature this PR addresses: Steps to reproduce: 1. Have a internal user that manages notifications by email 2. On a customer invoice log a note and ping this user using '@' Current behavior before PR: The email contains a link to the portal Desired behavior after PR is merged: The email contains a link to the backend --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178105 Forward-Port-Of: odoo/odoo#176818
With negative unit price it was possible to have a zero division error when ventilating the analytic distributions. Example: Create a new sale order, set the business partner and other header data. Add a line, with a VAT of 15% for example. With a product, It doesn't matter which one. a price. To this line, add 2 analytics distributions. Add a second line whit an other product, a price and an other VAT 7% for example. Add the same analytic distribution. Add a third line, a discount one, same pr
Original PR description
With negative unit price it was possible to have a zero division error when ventilating the analytic distributions. Example: Create a new sale order, set the business partner and other header data. Add a line, with a VAT of 15% for example. With a product, It doesn't matter which one. a price. To this line, add 2 analytics distributions. Add a second line whit an other product, a price and an other VAT 7% for example. Add the same analytic distribution. Add a third line, a discount one, same price * -1 then then second. same VAT then the second. Add analytic distribution. Make a down payment This fix also remove the 0 amount down payment line this would create. opw-4140669 Forward-Port-Of: odoo/odoo#178668 Forward-Port-Of: odoo/odoo#178043
If nobody gave a global discount (fixed amount/on SO) in a given company before, the first user to give a global discount through the dedicated wizard would create the dedicated Discount product for that company. Nevertheless, it was not done in sudo, so the user would get a traceback if he didn't have admin rights (for company update) or manager rights (for the product creation). opw-4048403 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-
Original PR description
If nobody gave a global discount (fixed amount/on SO) in a given company before, the first user to give a global discount through the dedicated wizard would create the dedicated Discount product for that company. Nevertheless, it was not done in sudo, so the user would get a traceback if he didn't have admin rights (for company update) or manager rights (for the product creation). opw-4048403 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178361
Mouse hovering on channel member list item had no background color change. This happens because `bg-view` had more specificity than the SCSS rule. This commit fixes the issue by replacing `bg-view` by `bg-inherit`, which makes background unchanged (matches global channel member list background) but inherit is necessary for proper IM status background in all cases. `bg-inherit` also has less specificity because it hasn't the `!important` like `bg-view`. In dark theme, color is adjusted beca
Original PR description
Mouse hovering on channel member list item had no background color change. This happens because `bg-view` had more specificity than the SCSS rule. This commit fixes the issue by replacing `bg-view` by `bg-inherit`, which makes background unchanged (matches global channel member list background) but inherit is necessary for proper IM status background in all cases. `bg-inherit` also has less specificity because it hasn't the `!important` like `bg-view`. In dark theme, color is adjusted because `bg-view` and `gray-200` are the same. Before (hover on Marc Demo) <img width="405" alt="Screenshot 2024-08-29 at 15 23 54" src="https://github.com/user-attachments/assets/6ae8815e-9c0c-41d2-b369-9d9c78b920b1"> After <img width="402" alt="Screenshot 2024-08-29 at 15 18 49" src="https://github.com/user-attachments/assets/2a0f04e6-4dd6-4c63-aa0e-882f7b54d8b7"> Forward-Port-Of: odoo/odoo#178460 Forward-Port-Of: odoo/odoo#178387
Before this commit, when opening a form view of record containing an activity on 2 different tabs, one of tab showed the user avatar while the other doesn't. Steps to reproduce: - open Contact form view - schedule an activity - open this form view on another tab => the new tab has user avatar on activity while previous tab doesn't This happens because the state of activities is shared between tabs, and the newer tab shares its state to other tabs. However, activity state was not pro
Original PR description
Before this commit, when opening a form view of record containing an activity on 2 different tabs, one of tab showed the user avatar while the other doesn't. Steps to reproduce: - open Contact form…
Before this commit, when opening a form view of record containing an activity on 2 different tabs, one of tab showed the user avatar while the other doesn't. Steps to reproduce: - open Contact form view - schedule an activity - open this form view on another tab => the new tab has user avatar on activity while previous tab doesn't This happens because the state of activities is shared between tabs, and the newer tab shares its state to other tabs. However, activity state was not properly passing relational field values notably for the author: instead of passing `type` and `id` identifying values, it only passes `id`. This comes from a typo in code where the `toIdData()` was used on current model (Activity) rather than the target model (Persona), thus only persona id was retrieved. This commit fixes the issue by properly using `toIdData` on target model of relational field. Also the date and datetime fields were not properly serialized, which also result in breaking the datetime in other tabs. This commit also fixes this issue. Task-4143781 Before / After <img width="300" alt="Screenshot 2024-08-28 at 17 10 25" src="https://github.com/user-attachments/assets/e4422b69-8800-4dc3-ba16-515ea6b7392d"> <img width="369" alt="Screenshot 2024-08-28 at 17 10 30" src="https://github.com/user-attachments/assets/4d5783bd-2935-4630-8ea1-d94264b739bf"> Forward-Port-Of: odoo/odoo#178274
When a widget is destroyed before it is fully initialized, it should not crash. When the widget implementation was merged into the public widget one at [1], that bug was created for public widgets. No existing flow was found to be broken because of this but it would not be a surprise if this actually fixes issues. [1]: https://github.com/odoo/odoo/commit/51b1808ebedf9b810f83d264bb7e9204cab45e4a Found while working on task-3930204 Forward-Port-Of: odoo/odoo#178618
Original PR description
When a widget is destroyed before it is fully initialized, it should not crash. When the widget implementation was merged into the public widget one at [1], that bug was created for public widgets. No existing flow was found to be broken because of this but it would not be a surprise if this actually fixes issues. [1]: https://github.com/odoo/odoo/commit/51b1808ebedf9b810f83d264bb7e9204cab45e4a Found while working on task-3930204 Forward-Port-Of: odoo/odoo#178618
In the accounting reconciliation tool: - Click in one of the 2 search inputs - Start typing - Single click on the second search input - Start typing - Notice it still types in the first search input instead of the second. The search input you choose first doesn't matter. You can start with the upper one or the bottom one, the issue is the same, just reversed. Before:  After:  After:  Forward-Port-Of: odoo/odoo#178462 Forward-Port-Of: odoo/odoo#178238
This commit adds a localization module for Jordan. It includes the following: 1. Chart of accounts. 2. Accounts groups. 3. Taxes. 4. Tax report. task-2732319 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176683
Original PR description
This commit adds a localization module for Jordan. It includes the following: 1. Chart of accounts. 2. Accounts groups. 3. Taxes. 4. Tax report. task-2732319 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176683
Steps to reproduce: - Payroll > Contracts > Contracts - Pick a running contract - Add a new line to the working schedule such that: -- It starts exactly when the previous entry ends -- Both it and the previous entry have a work entry type -- They both have different types - Work Entries > Work entries - Regenerate work entries for the employee whose contract you editted - It appears as a singular block of the first entry's type For example Monday afernoon has an entry from 13:00 to 17:
Original PR description
Steps to reproduce: - Payroll > Contracts > Contracts - Pick a running contract - Add a new line to the working schedule such that: -- It starts exactly when the previous entry ends -- Both it and…
Steps to reproduce: - Payroll > Contracts > Contracts - Pick a running contract - Add a new line to the working schedule such that: -- It starts exactly when the previous entry ends -- Both it and the previous entry have a work entry type -- They both have different types - Work Entries > Work entries - Regenerate work entries for the employee whose contract you editted - It appears as a singular block of the first entry's type For example Monday afernoon has an entry from 13:00 to 17:00, give it type attendance then create a new line from 17:00 to 18:00 with type ovetime hours. This is interpreted as a singular work entry of type attendance spanning from 13:00 to 18:00. Work entries of different type should be kept separate or at least show all encompassed wok entry types. Preventing the merge is difficult as other modules likely want this behavior in resource.calendar hence the post processing method used here. opw-4053366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177755
During refactoring of hr_holidays for 17.0 (commit https://github.com/odoo/odoo/commit/8f87e102a95412aa7dd1b0ce07365d9d3bbdba6a) a typo was introduced. Forward-Port-Of: odoo/odoo#177814 Forward-Port-Of: odoo/odoo#177563
Original PR description
During refactoring of hr_holidays for 17.0 (commit https://github.com/odoo/odoo/commit/8f87e102a95412aa7dd1b0ce07365d9d3bbdba6a) a typo was introduced. Forward-Port-Of: odoo/odoo#177814 Forward-Port-Of: odoo/odoo#177563
* STEP TO REPRODUCE: create an application then change to the stage which we will hire he/she -> Duplicate that application -> the new one already display ribbon 'Hired' * SOLUTION: make copy=False to date_close to avoid this 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#177606 Forward-Port-
Original PR description
* STEP TO REPRODUCE: create an application then change to the stage which we will hire he/she -> Duplicate that application -> the new one already display ribbon 'Hired' * SOLUTION: make copy=False to date_close to avoid this 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#177606 Forward-Port-Of: odoo/odoo#176879
Steps to reproduce: - Go to a product page - Enable "Discussions and rating" in the eCommerce - Add some comments and ratings on the product - Use the filtering tool on the left => It does not work anymore task-4149745 Forward-Port-Of: odoo/odoo#178661 Forward-Port-Of: odoo/odoo#178524
Original PR description
Steps to reproduce: - Go to a product page - Enable "Discussions and rating" in the eCommerce - Add some comments and ratings on the product - Use the filtering tool on the left => It does not work anymore task-4149745 Forward-Port-Of: odoo/odoo#178661 Forward-Port-Of: odoo/odoo#178524
This commit ensures that the caret is not displayed on hover in `RecordSelector` , `MultiRecordSelector` components when they are present in sidebars and report editors. Displaying the caret in sidebar RecordSelectors creates an awkward and visually unappealing effect. This issue arises because, in sidebars, the entire input area is a RecordAutocomplete with padding and margin. Task-3777903 Forward-Port-Of: odoo/enterprise#68980 Forward-Port-Of: odoo/enterprise#68772
Original PR description
This commit ensures that the caret is not displayed on hover in `RecordSelector` , `MultiRecordSelector` components when they are present in sidebars and report editors. Displaying the caret in sidebar RecordSelectors creates an awkward and visually unappealing effect. This issue arises because, in sidebars, the entire input area is a RecordAutocomplete with padding and margin. Task-3777903 Forward-Port-Of: odoo/enterprise#68980 Forward-Port-Of: odoo/enterprise#68772
Forward-Port-Of: odoo/enterprise#69207
Original PR description
Forward-Port-Of: odoo/enterprise#69207
Since odoo/enterprise#38575, portal users can create/edit knowledge articles. However, the test that checks that feature is not correct: - it does not call `check_access_rights()` (for ACLs); - it uses a `res.partner` instead of a `res.users` in `with_user()`. Because the test only checks access rules with a non-existing user, no rules are found, and the check is therefore trivial. In other words, the test passes by accident :-( The fix consists in creating a portal user for the corr
Original PR description
Since odoo/enterprise#38575, portal users can create/edit knowledge articles. However, the test that checks that feature is not correct: - it does not call `check_access_rights()` (for ACLs); - it uses a `res.partner` instead of a `res.users` in `with_user()`. Because the test only checks access rules with a non-existing user, no rules are found, and the check is therefore trivial. In other words, the test passes by accident :-( The fix consists in creating a portal user for the corresponding "customer" contact, and add the expected calls to `check_access_rights()`. Forward-Port-Of: odoo/enterprise#69157