Friday, June 23, 2023
43 changes · master
Enhancements to existing features
Landed cost records are now sorted by recorded date with the newest entries shown first. This makes recent cost updates easier to find and review without scrolling to the bottom of the list.
Original PR description
before this commit, when creating new record in landed cost, the newly added record is coming in the last position in the tree view. after this commit, the records shown in the tree view will be sorted based on the desc order of recorded date in the landed cost. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Developers can now create inherited views without repeating the model name when it is the same as the original view. This reduces boilerplate in customizations and lowers the chance of small configuration mistakes, with no expected change for end users.
Original PR description
It slightly decreases the amount of needed boilerplate code when creating inheriting views, by simply assuming the model is the same as the inherited one.
For example,
```xml
<!-- The commented line is no longer required -->
<record id="view_partner_form" model="ir.ui.view">
<!-- <field name="model">res.partner</field> -->
<field name="inherit_id" ref="base.view_partner_form" />
<field name="arch" type="xml">
<field name="name" position="after">
<field name="id" />
</field>
</field>
</record>
```
NOTE: A similar technique is already used to guess the view type. In the same spirit, it's extended to also guess the model.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe Point of Sale printer settings now show product categories as easy-to-read tags. This makes category selection clearer for users configuring printer rules.
Original PR description
before this commit, in pos.printer model the product_categories_ids is displayed without many2many_tags widget. after this commit, for product_categories_ids field many2many_tags widget is added Before:  After:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Newly created employees and resources now display an avatar based on their initials instead of a generic grey placeholder. This makes employee selection fields easier to scan and gives records a more polished appearance from the moment they are created.
Original PR description
Before this commit, when the user creates new resource and employee on the fly in many2one field, the default avatar of Initial name should be set instead of placeholder (grey icon). The reason why a grey icon is displayed is because the `_compute_avatar` for employee set that icon when avatar or image is not found. This commit add default avatar of initial name when new resource and employee is created. task-3251689
This update aligns Enterprise tests with a community change that shows quick visual feedback when users switch menus before the full screen loads. It helps keep automated checks reliable while supporting a smoother perceived navigation experience.
Original PR description
The PR https://github.com/odoo/odoo/pull/124068/files changes the action and menu services so that each menu item changes will (almost) immediately displays an empty screen, to provide some quick feedback to the user, before showing the actual action, once it is loaded. As a result, a few tests have to be adapter, since the actual action is displayed a tick later in tests.
Helpdesk customer emails for ticket receipt and closure were updated with clearer wording and a more polished tone. These emails will also be automatically deleted after sending, reducing unnecessary database storage while keeping customers informed.
Original PR description
Purpose: make the 'ticket closed' email template sexier - change the 'helpdesk: ticket closed' email template as follows: - Subject: Ticket Closed - Reference 15 - Dear [Customer Name], - We would…
Purpose: make the 'ticket closed' email template sexier - change the 'helpdesk: ticket closed' email template as follows: - Subject: Ticket Closed - Reference 15 - Dear [Customer Name], - We would like to inform you that we have closed your ticket (reference 15). We trust that the services provided have met your expectations and that you have found a satisfactory resolution to your issue. - However, if you have any further questions or comments, please do not hesitate to reply to this email to re-open your ticket. Our team is always here to help you and we will be happy to assist you with any further concerns you may have. - Thank you for choosing our services and for your cooperation throughout this process. We truly value your business and appreciate the opportunity to serve you. - Kind regards, - [Name] Helpdesk Team. - don't forget to add linebreaks to make the message breathable - https://nimb.ws/ShGmkL 'helpdesk: request acknowledgment' email template: change the name to: 'helpdesk: ticket received' - change the template description to: "Send customers a confirmation email to notify them that their helpdesk ticket has been received and is currently being reviewed by the helpdesk team. Automatically send an email to customers when a ticket reaches a specific stage in a helpdesk team by setting this template on that stage." Purpose: these emails are not worth taking storage space in the database, especially since there might be a lot of them + be consistent with the other email templates that are almost all in auto_delete - set auto_delete to true on the following email templates: helpdesk: request acknowledgment + helpdesk: ticket closed Task-3251713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Projects can now enable the Documents feature without manually selecting a folder first; the system creates one automatically when needed. Demo data for document-related projects was also cleaned up to reuse existing task stages, making sample environments more consistent.
Original PR description
This PR brings two minor improvements to the Project/Documents bridges: - In order to make enabling the "Documents" feature on existing projects easier, make folder field non required in all cases, and generate a new folder if the field is left empty while the feature is enabled. - Make the demo data a bit cleaner by using the existing task stages from other demo projects for the generated documents demo project. Task-3251627
Resolved issues and error corrections
This fix ensures analytic account aggregate amounts include the needed currency information. It helps prevent incorrect or missing monetary totals in analytic views, improving reliability for financial analysis.
Original PR description
Forward port of a0a7119f0090ed64c1bd89a1321123dc3e80dde0 opw-3316448
Miscellaneous changes
In the course fullscreen view, a black overlay is hovering the content on medium screen size and lower when the sidebar is active. Fix the black overlay which is still showing after closing the sidebar. When the sidebar is close the overlay shouldn't be displayed. As the content is translated to the right and still fully visible on medium screen size, a black overlay isn't needed. Only show the black overlay for small screen size and lower. Task-3371743 --- I confirm I have signed
Original PR description
In the course fullscreen view, a black overlay is hovering the content on medium screen size and lower when the sidebar is active. Fix the black overlay which is still showing after closing the sidebar. When the sidebar is close the overlay shouldn't be displayed. As the content is translated to the right and still fully visible on medium screen size, a black overlay isn't needed. Only show the black overlay for small screen size and lower. Task-3371743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#125036
This fixes a missing currency reference in Swedish point-of-sale aggregate reporting. It helps ensure totals are displayed or calculated with the correct currency, reducing reporting errors for affected businesses.
Original PR description
Forward port of 506c906c58a7d1b5e1592ccf0575194e0f387854 opw-3316448
The Helpdesk team settings now clearly show the 'Accept Emails From' label for the related email alias option. This fixes a missing label so users can better understand and configure who may send emails to a helpdesk team.
Original PR description
This PR address following Issue: - The label 'accept emails from' is missing from the alias_contact field. Cause: - The string applied to the field is not visible because it is inherited through another model. Therefore, the string is not functioning as intended. FIx: - To resolve this issue, a label needs to be applied to the field. task-3318851
Add a lot of hook to allow a custom module to reuse the standard sale_purchase module. Forward-Port-Of: odoo/odoo#121537
Original PR description
Add a lot of hook to allow a custom module to reuse the standard sale_purchase module. Forward-Port-Of: odoo/odoo#121537
**Before this PR** Remove button is shown when the view of our field is in kanban mode. When our field is one2many it will delete the record and when our field is many2one it will remove the record. So many times user get confuse that they are deleting the record or removing the record. **After this PR** So to clear out the confusion this commit changes the label of remove to to delete if the field is one2many. A test was added to ensure this ux change. Task-3185967 Forw
Original PR description
**Before this PR** Remove button is shown when the view of our field is in kanban mode. When our field is one2many it will delete the record and when our field is many2one it will remove the record. So many times user get confuse that they are deleting the record or removing the record. **After this PR** So to clear out the confusion this commit changes the label of remove to to delete if the field is one2many. A test was added to ensure this ux change. Task-3185967 Forward-Port-Of: odoo/odoo#118702
Before this commit, due to the milk design, there was a gap between the buttons in btn-group. However, in certain modules, it was necessary to have a negative margin-left to achieve an edge-to-edge appearance. To address this issue, I introduced a CSS variable called `--btn-group-gap` to control the margin-left property for the elements. This change allows for customization of the margin-left value, with a fallback value of `$btn-border-width` by default, when needed. required-by: -
Original PR description
Before this commit, due to the milk design, there was a gap between the buttons in btn-group. However, in certain modules, it was necessary to have a negative margin-left to achieve an edge-to-edge appearance. To address this issue, I introduced a CSS variable called `--btn-group-gap` to control the margin-left property for the elements. This change allows for customization of the margin-left value, with a fallback value of `$btn-border-width` by default, when needed. required-by: - https://github.com/odoo/enterprise/pull/41357 task-3336458 part of task-3326263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122126
PR odoo/odoo#115197 refactored how a field's domain is read. Unfortunately it incorrectly parses a lambda domain which can lead to a "Invalid domain AST" client error when the domain is read in certain cases. Steps to reproduce: - Install mrp_workorder and quality_control - Open Quality app - Quality Control > Control Points > New - Click on `product_ids` field => Error is thrown. Issue is due to `product_ids` domain being: https://github.com/odoo/enterprise/blob/d2b0eacd68d6558aa93769
Original PR description
PR odoo/odoo#115197 refactored how a field's domain is read. Unfortunately it incorrectly parses a lambda domain which can lead to a "Invalid domain AST" client error when the domain is read in…
PR odoo/odoo#115197 refactored how a field's domain is read. Unfortunately it incorrectly parses a lambda domain which can lead to a "Invalid domain AST" client error when the domain is read in certain cases. Steps to reproduce: - Install mrp_workorder and quality_control - Open Quality app - Quality Control > Control Points > New - Click on `product_ids` field => Error is thrown. Issue is due to `product_ids` domain being: https://github.com/odoo/enterprise/blob/d2b0eacd68d6558aa9376985a72a350e20d7619d/mrp_workorder/models/quality.py#L101 which isn't correctly parsed into an AST and which results in this call throwing the error https://github.com/odoo/odoo/blob/75c71ccfa8b5daa79f82af1e492831c565ee54f3/addons/web/static/src/views/fields/many2many_tags/many2many_tags_field.js#L153-L154C13 Note that the type check is needed because sometimes the domain is passed as an array and other times as a string and we should only evalExpr on strings. Also for safety we ensure that we do not pass a domain of "undefined" as well. 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#125144
product variable used in the rounding precision come from the upper loop and won't work for all the quantites. opw-3229080 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#121262 Forward-Port-Of: odoo/odoo#120680
Original PR description
product variable used in the rounding precision come from the upper loop and won't work for all the quantites. opw-3229080 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#121262 Forward-Port-Of: odoo/odoo#120680
Multiple fixes targeting the new 'Re-order from portal' feature. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#123555
Original PR description
Multiple fixes targeting the new 'Re-order from portal' feature. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#123555
When we create a project stage (project task type), it is essential that we link it to a project. Otherwise, the record created will never be accessible. opw-3322992 Forward-Port-Of: odoo/odoo#126153 Forward-Port-Of: odoo/odoo#122614
Original PR description
When we create a project stage (project task type), it is essential that we link it to a project. Otherwise, the record created will never be accessible. opw-3322992 Forward-Port-Of: odoo/odoo#126153 Forward-Port-Of: odoo/odoo#122614
Current behavior: When the text for the button in the cash in/out popup is too long, the first number of the amount is hidden behind the currency symbol. Steps to reproduce: - Install l10n_bo and PoS - Switch language to Spanish - Create and open a PoS with a cash payment method - Open the cash in/out popup, enter a value. - The first number of the amount is hidden behind the currency symbol. Without fix:  With fix:  With fix (when symbol is on right):  opw-3324406 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#126060 Forward-Port-Of: odoo/odoo#124875
We want be able to click on the button right at the stock move creation Task: 3256447 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#123869
Original PR description
We want be able to click on the button right at the stock move creation Task: 3256447 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#123869
Prior to this commit, when a filter or a dropdown item had a long name, the layout was broken on mobile, the item went out of the viewport and wasn't readable : https://drive.google.com/file/d/1nkj7i6jXPgqNP9d_zJ0TDmUTj9QM1qlL/view https://github.com/odoo/odoo/pull/125719 This commit fixes this issue. task-3378207 Part of task-3326263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#125719
Original PR description
Prior to this commit, when a filter or a dropdown item had a long name, the layout was broken on mobile, the item went out of the viewport and wasn't readable : https://drive.google.com/file/d/1nkj7i6jXPgqNP9d_zJ0TDmUTj9QM1qlL/view https://github.com/odoo/odoo/pull/125719 This commit fixes this issue. task-3378207 Part of task-3326263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#125719
The `waitfont.js` module depends on the presence of the `document.body` and it's possible that during loading of the services, it is still `null`, which results to indeterministic random error in the test. In this commit, we make sure to use the module (calling `waitForWebfonts`) only when the pos app is about to be mounted, such that `document.body` is already present. Runbot Error: 22519 (and probably others) Forward-Port-Of: odoo/odoo#125943
Original PR description
The `waitfont.js` module depends on the presence of the `document.body` and it's possible that during loading of the services, it is still `null`, which results to indeterministic random error in the test. In this commit, we make sure to use the module (calling `waitForWebfonts`) only when the pos app is about to be mounted, such that `document.body` is already present. Runbot Error: 22519 (and probably others) Forward-Port-Of: odoo/odoo#125943
This reverts commit [1]. It broke all snippet button colors, making them invisible. Besides that, the fix seems not obvious to make properly and would thus require some more testing, thus the need of reverting this urgently. There is probably more things to consider when remaking that fix: - mass_mailing scss code in web_editor should not be a thing. Even if the comment about variables not being accessible is true, there are definitely other ways to do it (make them accessible, add
Original PR description
This reverts commit [1]. It broke all snippet button colors, making them invisible. Besides that, the fix seems not obvious to make properly and would thus require some more testing, thus the need of…
This reverts commit [1]. It broke all snippet button colors, making them invisible. Besides that, the fix seems not obvious to make properly and would thus require some more testing, thus the need of reverting this urgently. There is probably more things to consider when remaking that fix: - mass_mailing scss code in web_editor should not be a thing. Even if the comment about variables not being accessible is true, there are definitely other ways to do it (make them accessible, add those rules generically with a custom selector and fill that custom selector when mass_mailing is installed, etc etc) - More than scss code, we really do not want mass_mailing *CSS* rules in website pages, especially in that code that generates *many* CSS rules. Of course web_editor.common.scss contains many things that should not be there and mass_mailing has probably already a lot of useless code in the frontend assets... but the goal is to fix those inconsistencies in the future. - The fix impacts buttons which are not hovered while the goal seemed to be to have their hover style disabled... - The fix impacts buttons which are in o_ccX environments only (?) but seemed to be about disabling all hover styles. - Much doubt on the need of an at-root instruction, especially since it creates a bug in frontend pages without o_mail_wrapper containers so it probably does not work as intended. - The fix should probably not be about overriding/duplicating the CSS rules but rather post-processing the mass_mailing assets to remove all hover rules. I guess it is even possible to do in JS removing the :hover CSS rules, at worst by moving all CSS rules to inline <style> rules or something like that. Note: the main bug about button text being invisible is apparently from 16.0 and up only. This still reverts the code at its root (15.2) for all mentioned reasons above. [1]: https://github.com/odoo/odoo/commit/55aff2dcdf5537e16bdaf01ee68d776510572171 task-3376724 Forward-Port-Of: odoo/odoo#126048
pos_*: l10n_ae_pos,l10n_co_pos,l10n_fr_pos_cert In many pos l10n addons, we assume that country is present in the company, and this is a wrong assumption. Thanks to the runbot error that we are able to detect these mistakes in the code. In this commit, we fix the issue by checking the presence of country first before actually accession the country code. Runbot Error: 20917 Linked PR: https://github.com/odoo/enterprise/pull/43009 Forward-Port-Of: odoo/odoo#126043
Original PR description
pos_*: l10n_ae_pos,l10n_co_pos,l10n_fr_pos_cert In many pos l10n addons, we assume that country is present in the company, and this is a wrong assumption. Thanks to the runbot error that we are able to detect these mistakes in the code. In this commit, we fix the issue by checking the presence of country first before actually accession the country code. Runbot Error: 20917 Linked PR: https://github.com/odoo/enterprise/pull/43009 Forward-Port-Of: odoo/odoo#126043
Currently we skip the lot_id assignment if move.quantity_done is set, which causes issues when using "Mass Produce" option. Task: 3370869 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#126066
Original PR description
Currently we skip the lot_id assignment if move.quantity_done is set, which causes issues when using "Mass Produce" option. Task: 3370869 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#126066
… field to improve performance The index is being added because when processing a large PoS session, the method consume_specific_qty is called a large number of times if the product categories are set to automatic valuations. This method has the line: tmp_value += qty_taken_on_candidate * ((candidate.value + sum(candidate.stock_valuation_layer_ids.mapped('value'))) / candidate.quantity) This line, when running upwards of 20,000 times, can cause large performance issues, due to the stock_va
Original PR description
… field to improve performance
The index is being added because when processing a large PoS session, the method consume_specific_qty is called a large number of times if the product categories are set to automatic valuations. This method has the line: tmp_value += qty_taken_on_candidate * ((candidate.value + sum(candidate.stock_valuation_layer_ids.mapped('value'))) / candidate.quantity)
This line, when running upwards of 20,000 times, can cause large performance issues, due to the stock_valuation_layer_ids being a related field on stock_valuation_layer_id. This causes a doubling of the number of sql queries which causes slowdowns in performance. Adding this index drastically improves the performance of the queries generated by this line of code.
opw-3295560
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#123818Current behavior: When computing the discountable values of an order, the discount of the program where not taken into account if you used specific discountable products. Steps to reproduce: - Create products A and B with a price of 20$ - Create a loyalty program - Rule: - Minimum qty : 2 - Apply on specific products : Product A and Product B - Reward : 5 points per order - Reward: - 10$ per order - In exchange of 2 points - Apply on specific products : Product A and Pr
Original PR description
Current behavior: When computing the discountable values of an order, the discount of the program where not taken into account if you used specific discountable products. Steps to reproduce: - Create products A and B with a price of 20$ - Create a loyalty program - Rule: - Minimum qty : 2 - Apply on specific products : Product A and Product B - Reward : 5 points per order - Reward: - 10$ per order - In exchange of 2 points - Apply on specific products : Product A and Product B - Open PoS and add Product A and Product B to the order - A reward should be added automatically with a value of -10$ - Click on the reward button, another reward should be added but it has the wrong value. It should be -10$ but it is not. opw-3232565 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#125699 Forward-Port-Of: odoo/odoo#121209
Removing ps-0 class that was breaking the default button padding To deal with the possible aligment issue when `btn-link` is used alone (as this button style has no background), we are switching the second possible type of buttons to `btn-secondary`. It also matches with the `btn` combinations used in modals Issue: [RES] https://i.imgur.com/JUmMFgW.png Notif > padding on refresh button when page needs a refresh Forward-Port-Of: odoo/odoo#125710
Original PR description
Removing ps-0 class that was breaking the default button padding To deal with the possible aligment issue when `btn-link` is used alone (as this button style has no background), we are switching the second possible type of buttons to `btn-secondary`. It also matches with the `btn` combinations used in modals Issue: [RES] https://i.imgur.com/JUmMFgW.png Notif > padding on refresh button when page needs a refresh Forward-Port-Of: odoo/odoo#125710
Previously, copy-pasted tables from other spreadsheet editors did not keep their style once in our editor. This is simply because the way style information is embedded in the HTML is not inter-compatible across editors. Google Sheets places all the cell's style on <td> tags, which can't be styled in Odoo 15. This has been fixed by moving all possible style attributes to a direct <span> children, which is created if necessary. Microsoft Excel defines the style in the standard <style> t
Original PR description
Previously, copy-pasted tables from other spreadsheet editors did not keep their style once in our editor. This is simply because the way style information is embedded in the HTML is not…
Previously, copy-pasted tables from other spreadsheet editors did not keep their style once in our editor. This is simply because the way style information is embedded in the HTML is not inter-compatible across editors. Google Sheets places all the cell's style on <td> tags, which can't be styled in Odoo 15. This has been fixed by moving all possible style attributes to a direct <span> children, which is created if necessary. Microsoft Excel defines the style in the standard <style> tag, using custom CSS classes on <td> tags. We parse that <style> and copy it to the style attribute of <td> tags with matching classes. Those styled <td> tags are later handled as described above. Libre Office makes use of a deprecated <font> tag and its specific attributes. Those attributes are mapped to equivalent values for the standard style attribute. We add 'normal' as a default value for 'font-weight' so that this specific style-value pair is discarded, as it has no impact on the style (being the default). task-3255167 Forward-Port-Of: odoo/odoo#126103 Forward-Port-Of: odoo/odoo#119357
Current behavior: When you refund a downpayment in the PoS, the downpayment is not added to the original order. Steps to reproduce: - Create an order in the sales app - Open the PoS and make a downpayment for the order - Refund the downpayment you just made - Go back to the original order in the sales app, the downpayment is correctly added, but the refund of the downpayment is not added. - The order should contain : The original product, the downpayment and the refund of the downpaymen
Original PR description
Current behavior: When you refund a downpayment in the PoS, the downpayment is not added to the original order. Steps to reproduce: - Create an order in the sales app - Open the PoS and make a downpayment for the order - Refund the downpayment you just made - Go back to the original order in the sales app, the downpayment is correctly added, but the refund of the downpayment is not added. - The order should contain : The original product, the downpayment and the refund of the downpayment. opw-3275708 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#126121 Forward-Port-Of: odoo/odoo#121160
Reproduction: 1. Install Event, Sales, Webiste 2. Login as Admin, go to Website -> Go to website -> Events 3. Click the Open wood event, Register, buy one VIP ticket 4. In Address step, Edit the billing address, change the name to “Test Name”, click next 5. The user name “Mitchell Admin” is changed to “Test Name”, we shouldn’t be able to change the info Reason: In the fix to block name change here: https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644 we use th
Original PR description
Reproduction: 1. Install Event, Sales, Webiste 2. Login as Admin, go to Website -> Go to website -> Events 3. Click the Open wood event, Register, buy one VIP ticket 4. In Address step, Edit the…
Reproduction: 1. Install Event, Sales, Webiste 2. Login as Admin, go to Website -> Go to website -> Events 3. Click the Open wood event, Register, buy one VIP ticket 4. In Address step, Edit the billing address, change the name to “Test Name”, click next 5. The user name “Mitchell Admin” is changed to “Test Name”, we shouldn’t be able to change the info Reason: In the fix to block name change here: https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644 we use the can_edit_vat to check if we have existing invoice(s) or SO(s). However, we should block the route that an employee changes the billing address when placing an order. If they are placing an order for external people, it should be done from the back end. Fix: add an extra error case when it's an employee trying to change the name or email address when editing billing address. This is the case when an employee tries to order for external people. They should do it from the back end. They can still buy for themselves without changing the billing address. Also added translation in pot. Edited the test for editing address of log in user, added tests for portal user. Reformat the invoice exsits check for name change to have better readability In website, add render on MockRequest that return a supported type (string e.g.) The adding of can_edit_vat: https://github.com/odoo/odoo/commit/f8b05f52f5ea7f31135f700b0e240ff563204085 Related fix to block the name change: https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644 A patch to not block the checkout process when name is not set: https://github.com/odoo/odoo/commit/781dbeaccac76a6ec4f4b8cac1b607810697e394 opw-3126325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#126020 Forward-Port-Of: odoo/odoo#111708
Edited the names cities of in Turkey: Afyon: Afyonkarahisar İçel: Mersin K.maraş: Kahramanmaraş Description of the issue/feature this PR addresses: Turkey has 81 cities, at the Odoo 78 cities' names are correct but 3 cities' names are incorrect. Current behaviour before PR: When you search Mersin you can't see because it's name is İçel (İçel is the centre of Mersin) and other two cities: Afyon (Afyonkarahisar), K.maraş (Kahramanmaraş) Desired behaviour after PR is merged: All of t
Original PR description
Edited the names cities of in Turkey: Afyon: Afyonkarahisar İçel: Mersin K.maraş: Kahramanmaraş Description of the issue/feature this PR addresses: Turkey has 81 cities, at the Odoo 78 cities' names are correct but 3 cities' names are incorrect. Current behaviour before PR: When you search Mersin you can't see because it's name is İçel (İçel is the centre of Mersin) and other two cities: Afyon (Afyonkarahisar), K.maraş (Kahramanmaraş) Desired behaviour after PR is merged: All of the name cities of Turkey will be correct. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#126122
**Before this commit:** Duplicating the contact that is linked to an attendee of a course also creates a copy of an attendee as well. **After this commit:** It does not create duplicate attendee in course. Task-3253983 Forward-Port-Of: odoo/odoo#125488 Forward-Port-Of: odoo/odoo#118015
Original PR description
**Before this commit:** Duplicating the contact that is linked to an attendee of a course also creates a copy of an attendee as well. **After this commit:** It does not create duplicate attendee in course. Task-3253983 Forward-Port-Of: odoo/odoo#125488 Forward-Port-Of: odoo/odoo#118015
To reproduce (V16): 0. Install Accounting (can also be reproduced with just Invoicing, but there is no "journal item" menu that will ease the process to show the issue) 1. (In debug), change the dollar currency rounding to 0.0001 (instead of 0.01) 2. Go to Accounting > Customers > Invoices 3. Create a first invoice with: - a partner P1 - set an invoice date - make sure that there is a payment term set (for example "30 days") - at least one invoiced line (the product does not
Original PR description
To reproduce (V16): 0. Install Accounting (can also be reproduced with just Invoicing, but there is no "journal item" menu that will ease the process to show the issue) 1. (In debug), change the…
To reproduce (V16): 0. Install Accounting (can also be reproduced with just Invoicing, but there is no "journal item" menu that will ease the process to show the issue) 1. (In debug), change the dollar currency rounding to 0.0001 (instead of 0.01) 2. Go to Accounting > Customers > Invoices 3. Create a first invoice with: - a partner P1 - set an invoice date - make sure that there is a payment term set (for example "30 days") - at least one invoiced line (the product does not matter) with the tax 15 % and the price to 12.36 DO NOT confirm the invoice 4. Create another invoice with - ANOTHER partner P2 - set an invoice date - make sure that there is a payment term set (for example "30 days") - at least one invoiced line (the product and the price does not matter) 5. Go back to the Invoices list view and select the 2 new (unposted) invoices then Action > Post entries. 6. Check Force and "Post Journal Entries" 7. Go to Accounting > Reporting > Journal Items 8. Group by "Journal Entry" and unfold the 2 last invoices (that should be the one validated in 6.) => The "Partner" set on the Debit Line is the one of the other invoice (and vice versa) Analyse: This issue is a mix of different sub-issues. Solving any of this sub-issue would solve the issue but as other sub-issues may exists we will fix each of them individually. Sub-issue 1: The account.move.line (=AML) partner is set correctly before the post (6.), this is during the "mass posting" process that the issue happens. The partner is changed because of this line: https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2094-L2096 The value written to AML of id `line_id` include `move_id` which overwrite the account.move that was originally set on the AML. As the `partner` is computed only in certain circumstances, if the `move_id` written differ from the one of the AML, most of the values will be updated with the write values, but the `partner_id` will keep its value (this is why the swap of partner happen). In other words, this issue happen as `line_id.move_id` order is different from `key["move_id"]`. So we write on the "wrong" AML. Sub-issue 2: In theory, this issue should not have happened in the first place. The line: https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2061 should have prevent the re-edition of the AML (as actually no relevant datas are written). But the equality between the dictionaries fail due to some rounding errors. Here: - needed_after[<key Invoice 1>]["balance"] --> 14.214000000000002 - needed_before[<key Invoice 1>]["balance"] -> 14.213999999999999 N.B: if we don't set an "invoice date" on the invoice, a rewrite is done before which would prevent our issue to reproduce. Sub-issue 3: If we try to reproduce the issue without setting a "payment term", the issue would not reproduce. By setting a "payment term" the `to_delete` computation change at: https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2067 This happens as the `existing_before` keys and `needed_after` keys are different: - existing_before[<key Invoice 1>]["discount_date"] -> False - needed_after[<key Invoice 1>]["discount_date"] ----> None As the values are different, Odoo all the AML to the `to_delete` which then trigger their overwrite. In other words, if no "payment terms" were set on the invoices, the issue would not happen either opw-3270471,3292931,3333799 Forward-Port-Of: odoo/odoo#125605 Forward-Port-Of: odoo/odoo#124517
Forward-Port-Of: odoo/enterprise#42952 Forward-Port-Of: odoo/enterprise#41808
Original PR description
Forward-Port-Of: odoo/enterprise#42952 Forward-Port-Of: odoo/enterprise#41808
Prior this PR: In knowledge, when you insert another view below it in article, there is conflict in thead while opening menu drop down. After this PR: No conflict in thead, while opening menu drop down. **Task**- 3340979 Forward-Port-Of: odoo/enterprise#42988
Original PR description
Prior this PR: In knowledge, when you insert another view below it in article, there is conflict in thead while opening menu drop down. After this PR: No conflict in thead, while opening menu drop down. **Task**- 3340979 Forward-Port-Of: odoo/enterprise#42988
Steps: - Install timeshhet and timeoff app. - Set a task on timeoff type. Issue: - User able to create timesheets on timeoff tasks directly from timesheet app. Casue: - In PR [1] forgot to call super to check validation on creation of timehseets. Fix: - Call super to check validation on creation. [1] https://github.com/odoo/enterprise/pull/31689 task-3205260 Forward-Port-Of: odoo/enterprise#42981 Forward-Port-Of: odoo/enterprise#37521
Original PR description
Steps: - Install timeshhet and timeoff app. - Set a task on timeoff type. Issue: - User able to create timesheets on timeoff tasks directly from timesheet app. Casue: - In PR [1] forgot to call super to check validation on creation of timehseets. Fix: - Call super to check validation on creation. [1] https://github.com/odoo/enterprise/pull/31689 task-3205260 Forward-Port-Of: odoo/enterprise#42981 Forward-Port-Of: odoo/enterprise#37521
In many pos l10n addons, we assume that country is present in the company, and this is a wrong assumption. Thanks to the runbot error that we are able to detect these mistakes in the code. In this commit, we fix the issue by checking the presence of country first before actually accession the country code. Runbot Error: 20917 Linked PR: https://github.com/odoo/odoo/pull/126043 Forward-Port-Of: odoo/enterprise#43009
Original PR description
In many pos l10n addons, we assume that country is present in the company, and this is a wrong assumption. Thanks to the runbot error that we are able to detect these mistakes in the code. In this commit, we fix the issue by checking the presence of country first before actually accession the country code. Runbot Error: 20917 Linked PR: https://github.com/odoo/odoo/pull/126043 Forward-Port-Of: odoo/enterprise#43009
Obsolete token is not something we need to fix. Level `warning` should be enough. The issue was caught by sentry https://online.sentry.io/issues/4208088178 Forward-Port-Of: odoo/enterprise#42166
Original PR description
Obsolete token is not something we need to fix. Level `warning` should be enough. The issue was caught by sentry https://online.sentry.io/issues/4208088178 Forward-Port-Of: odoo/enterprise#42166
Before this commit starting timer on invoiced timesheet raise user error and because of that user can't able to stop timer or start timer on other timesheets. So this commit add new timesheet on timer stop instead of tring to update invoiced timesheet this way user can add start and stop timer on invoiced timesheets. task-3205260 Forward-Port-Of: odoo/enterprise#37609
Original PR description
Before this commit starting timer on invoiced timesheet raise user error and because of that user can't able to stop timer or start timer on other timesheets. So this commit add new timesheet on timer stop instead of tring to update invoiced timesheet this way user can add start and stop timer on invoiced timesheets. task-3205260 Forward-Port-Of: odoo/enterprise#37609
Some fields are needed for SEPA Direct Debit and SEPA Credit Transfer but we generate those values in two different ways without clear reference to the official specs Example: in account_sepa the company name is used in the id fields MsgID, PmtInfId, EndtoEndId, but mixed with random number and record ids. This is confusing for the user when this data appear in the bank interface and seems to reference to a wrong company name This commit align the behavior of account_sepa to the newer acco
Original PR description
Some fields are needed for SEPA Direct Debit and SEPA Credit Transfer but we generate those values in two different ways without clear reference to the official specs Example: in account_sepa the company name is used in the id fields MsgID, PmtInfId, EndtoEndId, but mixed with random number and record ids. This is confusing for the user when this data appear in the bank interface and seems to reference to a wrong company name This commit align the behavior of account_sepa to the newer account_sepa_direct_debit https://www.europeanpaymentscouncil.eu/document-library/implementation-guidelines/sepa-credit-transfer-scheme-customer-psp-implementation https://www.europeanpaymentscouncil.eu/what-we-do/epc-payment-schemes/sepa-direct-debit/sepa-direct-debit-core-rulebook-and-implementation opw-3245049 Forward-Port-Of: odoo/enterprise#42987
Before this commit, we were juggling with `z-index`between systray's dropdowns, documents' inspector and selection button. This commit simplifies (and fix) this issue by only slightly raising the documents' selection button above the kanban's records and letting the DOM order do the rest. Steps to reproduce (on small screen): - On an enterprise database with Notes app installed - Open the systray activities' dropdown - Click "Add a new note" - Try to select a date ==> the datepicker is
Original PR description
Before this commit, we were juggling with `z-index`between systray's dropdowns, documents' inspector and selection button. This commit simplifies (and fix) this issue by only slightly raising the documents' selection button above the kanban's records and letting the DOM order do the rest. Steps to reproduce (on small screen): - On an enterprise database with Notes app installed - Open the systray activities' dropdown - Click "Add a new note" - Try to select a date ==> the datepicker is hidden behind the dropdown opw-3336072 Forward-Port-Of: odoo/enterprise#42887 Forward-Port-Of: odoo/enterprise#42632
Prior to this commit, and due to milk changes, a few issues need to be fixed or adapted: - The topbar of the chatter in Documents was positioned too close to the top and required adjustment. - The icons at the top of the inspector (btn-group) were no longer centered properly within their button/container. Also by having a default margin-left of 1px, spacing between buttons needs to be removed. see: https://github.com/odoo/odoo/pull/122126 for the latter - Elements such as link colo
Original PR description
Prior to this commit, and due to milk changes, a few issues need to be fixed or adapted: - The topbar of the chatter in Documents was positioned too close to the top and required adjustment. - The icons at the top of the inspector (btn-group) were no longer centered properly within their button/container. Also by having a default margin-left of 1px, spacing between buttons needs to be removed. see: https://github.com/odoo/odoo/pull/122126 for the latter - Elements such as link colors, tags icons, and other components using brand-primary lacked sufficient contrast against the dark background. This commit resolves these issues. requires: - https://github.com/odoo/odoo/pull/122126 task-3336458 part of task-3326263  Forward-Port-Of: odoo/enterprise#41357