Monday, November 16, 2020
25 changes · master
Security fixes and vulnerability patches
Odoo now has a standard way to store sensitive values such as passwords, API tokens, and PINs so they remain hidden from regular users while still allowing updates when needed. This improves protection for payment, email, LDAP, and point-of-sale credentials, and also prevents costly grouping or sorting on fields that can slow down the system.
Original PR description
Passwords, tokens, pins and other secret values have always been stored in Char fields with limited accesses usually restricted to the superuser. Such values are sensitive yet there was no standard easy way to prevent unauthorized access. We introduce a new `Secret` field type behaving just like the standard `Char` field it inherits from. The notable difference is that the secret field value is empty to all users except the super user. On other words, for regular users, it behaves like a write-only field. -- There are some fields that are quite expensive to group by or to order by, such field include relational fields (Many2many and One2many) and binary fields (both large blob of data and filesystem-stored attachments). In order to prevent non-efficient operations on those fields, we introduce a new `groupby` field attribute. This attribute is a boolean value controlling whether the field can be grouped by or ordered by.
Enhancements to existing features
Mobile status bar dropdown options now appear grey when users cannot change the stage, matching the desktop experience. This makes unavailable actions easier to recognize and helps avoid confusion when reviewing records on smaller screens.
Original PR description
Before this commit we didn't notice when the dropdown buttons were disabled or not. Now, we do the same as on desktop: The text color is gray when you aren't able to change the stage. Task ID: 2348528
Resolved issues and error corrections
Google reCAPTCHA will no longer be installed automatically and can instead be enabled from the general settings when needed. This gives administrators more control, including the option to protect login forms without forcing the feature on every database.
Original PR description
You can enable it in base_setup when you need it. Depends of base_setup and not ir_http or website because you need to be able to enable it for login form e.g. 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
Miscellaneous changes
The variable fee (Var) and fixed fee (Fix) indicated by paypal must be subtracted from the transaction amount (Am). So let's consider that Am = 100€, Var = 2.9% and Fix = 0.3€ Total fee = 100€ * (2.9/100) + 0.3€ = 3.20€ So in this case, the merchant will get 96.80€ and Paypal will get 3.20€ This computation can be verified with the simulator here: https://salecalc.com/paypal?p=100&l=us&r=0&e=0&f=0&m=2&c=0. So the idea here is to compute Am such that the merchant will get 100€ if
Original PR description
The variable fee (Var) and fixed fee (Fix) indicated by paypal must be subtracted from the transaction amount (Am). So let's consider that Am = 100€, Var = 2.9% and Fix = 0.3€ Total fee = 100€ * (2.9/100) + 0.3€ = 3.20€ So in this case, the merchant will get 96.80€ and Paypal will get 3.20€ This computation can be verified with the simulator here: https://salecalc.com/paypal?p=100&l=us&r=0&e=0&f=0&m=2&c=0. So the idea here is to compute Am such that the merchant will get 100€ if he set his price to 100€ fees = amount_fees_included * percentage / 100 + fixed fees = (amount + fees) * percentage / 100 + fixed fees = (amount * percentage / 100 + fixed) / (1 - percentage / 100) if the merchant needs to keep 100€, Am will be equal to 103.30€. That way, paypal takes 103.30 * 2.9% + 0.30 = 3.30 and the merchant takes 103.30 - 3.30 = 100 opw:2369557 Co-authored-by: AdrienHorgnies <aho@odoo.com> Forward-Port-Of: odoo/odoo#61569
The survey session join page is easier to use, with a larger code entry field and clearer error messages shown in a more helpful location. Survey editors also get a more intuitive order for adding questions and sections.
Original PR description
PURPOSE - improve the UX of the page mydb.odoo.com/s by changing the font size and error position - interchange the place of add a question and section SPECIFICATIONS - change the place of add a question and add a section - change the font size in session code page - show session expired error at bottom of the input box LINKS Task: https://www.odoo.com/web#id=2345907&action=4043&model=project.task&view_type=form&cids=2&menu_id=4720 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Toast notifications in the web interface have been simplified by removing icons and separate headers, placing the title directly in the message area, and moving action buttons to the bottom. This makes notifications more consistent and easier to read across Odoo.
Original PR description
Remove the icon of the toast elements. Remove the header and move the title in the body, as simple text. Move buttons at the bottom instead of at the right side. Note: this will be refactored with OWL anyway but this is a first step towards more consistent tips across backend and frontend. task-2311554
Mobile barcode scanning now selects a product automatically when the scan returns only one match, removing an extra tap from a common workflow. The mobile product lookup was also simplified behind the scenes, making the flow easier to maintain while keeping the same behavior when multiple products match.
Original PR description
This merge simplifies the FieldMany2One implementation on mobile by avoiding reimplementing the `_search()` function and directly using the search view creation helper for this feature. Also, it improves the barcode scanning flow on mobile by auto-selecting the product when there is only one matching the barcode. Task-ID : 2150991
This fixes an issue where course completion emails were not sent correctly when processing multiple eLearning courses at once. It helps ensure learners receive the right completion notifications and adds a test to prevent the problem from returning.
Original PR description
PURPOSE Fix the 'multi' behavior when sending completion emails for slide.channels. SPECS There was a typo in the 'slide.channel#_send_completed_mail' method that prevented it from correctly working in "multi" mode. A new test was introduced to ensure the fix is working. LINKS Task 2170708
The website editor now shows the parallax visual effect while a page is being edited. This helps users accurately adjust page blocks without needing to switch to preview mode, reducing trial and error when designing pages.
Original PR description
Bug report :
[JKE] Drop block / parallax / block
╰─[JKE] parralax effect is not visible in edit mode - make it difficult to have what you want if you don't have the preview
╰─[JKE] https://drive.google.com/file/d/1VBhJu3xSZ-nZwkMbbHmz36AbsOgjzOfy/viewThe website editor now keeps the blue editing overlay aligned when an image or snippet is resized or moved using the toolbar. This removes visual confusion for editors and makes content editing feel more accurate and reliable.
Original PR description
The overlay is now edited on each Jabberwock commit. Description of the issue/feature this PR addresses: The blue overlay on the snippet currently being edited did not update when the size or place of the element changed when using the jabberwock toolbar. Current behavior before PR: The blue overlay on the snippet currently being edited did not update when the size or place of the element changed when using the jabberwock toolbar. Desired behavior after PR is merged: The blue overlay on the snippet currently being edited does update when the size or place of the element changes when using the jabberwock toolbar. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Facebook, LinkedIn, and Twitter social modules now include the missing app icons. This improves visual consistency in the module list while keeping user-facing social network brand assets unchanged.
Original PR description
In social_facebook, social_twitter and social_linkedin modules icons were missing. to solve this perticular task, in each module we have static directory, In that i have created description directory. I have put icon.png and icon.svg on that description directory. **Task:id : 2372492**
The overrides in l10n_ modules are broken since 14.0 because the hook no longer exists. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#61564
Original PR description
The overrides in l10n_ modules are broken since 14.0 because the hook no longer exists. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#61564
Steps to reproduce the bug: - Install invoicing - Create an invoice and confirm it - Click Send & Print above the invoice - Click Send & Print again in the modal Bug: The modal stays open after having downloaded the PDF Explanation: `close_on_report_download` was cleaned out here: https://github.com/odoo/odoo/blob/2fd4e48cbb673175323fb866d87e654c5c9e05ac/addons/web/controllers/main.py#L332-L337 and wasn't forwarded to the frontend. opw:2375920 Forward-Port-Of: odoo/odoo#61635
Original PR description
Steps to reproduce the bug: - Install invoicing - Create an invoice and confirm it - Click Send & Print above the invoice - Click Send & Print again in the modal Bug: The modal stays open after having downloaded the PDF Explanation: `close_on_report_download` was cleaned out here: https://github.com/odoo/odoo/blob/2fd4e48cbb673175323fb866d87e654c5c9e05ac/addons/web/controllers/main.py#L332-L337 and wasn't forwarded to the frontend. opw:2375920 Forward-Port-Of: odoo/odoo#61635
When the user clicks outside of the kanban quick create element, it's closing itself automatically. However, the "hit box" of this behavior is not entirely accurate and clicking on the very edge of the box would also close the element. This commit fixes the click behavior and allows clicking anywhere inside the quick create element. Task 2373095 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I
Original PR description
When the user clicks outside of the kanban quick create element, it's closing itself automatically. However, the "hit box" of this behavior is not entirely accurate and clicking on the very edge of the box would also close the element. This commit fixes the click behavior and allows clicking anywhere inside the quick create element. Task 2373095 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#61519 Forward-Port-Of: odoo/odoo#61024
…ercial partner Before this commit, if a customer/supplier have an invoice address, when creating an invoice/bill it's the invoice address that will be identified as the customer/supplier and that will have it's rank increased and not the commercial partner. Now, the rank increment is done to the commercial partner. opw-2377870 Forward-Port-Of: odoo/odoo#61734 Forward-Port-Of: odoo/odoo#61680
Original PR description
…ercial partner Before this commit, if a customer/supplier have an invoice address, when creating an invoice/bill it's the invoice address that will be identified as the customer/supplier and that will have it's rank increased and not the commercial partner. Now, the rank increment is done to the commercial partner. opw-2377870 Forward-Port-Of: odoo/odoo#61734 Forward-Port-Of: odoo/odoo#61680
Activate units of measure and workcenters (work operations) Create Product C, uom Kg Create Product F, uom Kg Create BoM for F, 2000g manufactured from 5000g of C Set 1 operation/work order in the BoM: processing Create MO to produce 2kg (change the uom in the MO) of Product F from 5000g Product C Confirm MO and go to the work order put the quantity of Product F to 1 Kg then click Record Production/Mark as Done The manufacturing backorder is automatically created but is not showing t
Original PR description
Activate units of measure and workcenters (work operations) Create Product C, uom Kg Create Product F, uom Kg Create BoM for F, 2000g manufactured from 5000g of C Set 1 operation/work order in the BoM: processing Create MO to produce 2kg (change the uom in the MO) of Product F from 5000g Product C Confirm MO and go to the work order put the quantity of Product F to 1 Kg then click Record Production/Mark as Done The manufacturing backorder is automatically created but is not showing the components. This occur because of a mismatch between the uoms, `move._split` expect the parameter `qty` to be based on the product uom, instead it is the quant uom because the BoM was created using a different UoM than the one defined in products opw-2376217 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#61707
PURPOSE This commit fixes the behavior of archiving and un-archiving slide.channels. SPECS When archiving a slide.channel, you could run into an issue where the associated slide.channel.partners would be marked as "completed" even though the related slides were NOT completed by the user. This happened because when computing the completion, it's searching for slide.slide.channels marked as completed, and then comparing it with the count of slide.slides in the channel, which would
Original PR description
PURPOSE This commit fixes the behavior of archiving and un-archiving slide.channels. SPECS When archiving a slide.channel, you could run into an issue where the associated slide.channel.partners…
PURPOSE This commit fixes the behavior of archiving and un-archiving slide.channels. SPECS When archiving a slide.channel, you could run into an issue where the associated slide.channel.partners would be marked as "completed" even though the related slides were NOT completed by the user. This happened because when computing the completion, it's searching for slide.slide.channels marked as completed, and then comparing it with the count of slide.slides in the channel, which would always return 0 since all slides are archived when the channel is archived. Marking channels as completed when they should not triggers undesired side-effects (karma increase, completion email sent, ...). Now, when the slide.channel is not active, we don't mark associated slide.channel.partners as completed anymore. The ordering in which we archive channel and slides was also altered, see method docstring of 'slide.channel#toggle_active' for more info. A new test ensures the correct behavior of archiving. LINKS Task 2170708 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#61003
The `_update` of some components must take place before the `_update` of other (usually sibling) components that might directly influence their layout. This is in particular the case for `_update` that are relying on height. Prevent force save of scroll position if there are pending hints to adjust it, and prevent pending hints from overriding new scroll value. Prevent flicker with message date. This should fix all known issues related to incorrectly saving or restoring scroll posit
Original PR description
The `_update` of some components must take place before the `_update` of other (usually sibling) components that might directly influence their layout. This is in particular the case for `_update` that are relying on height. Prevent force save of scroll position if there are pending hints to adjust it, and prevent pending hints from overriding new scroll value. Prevent flicker with message date. This should fix all known issues related to incorrectly saving or restoring scroll position. task-2344226 task-2358066 task-2369332 task-2372339 task-2373741 Forward-Port-Of: odoo/odoo#61054
Events coming from the IoT Box were lost in two cases: 1. Create a listener for device 1 2. Send an action to device 1 --> If the action arrives before the listener the event is never sent to the DB 1. Setup up two listeners for devices 1 & 2 2. After a few seconds, send two consecutive actions to devices 1 & 2 --> Everytime a longpolling request arrives, a new threading.Event object is created. The first action sets the event, then, before the new longpolling request arrives, the s
Original PR description
Events coming from the IoT Box were lost in two cases: 1. Create a listener for device 1 2. Send an action to device 1 --> If the action arrives before the listener the event is never sent to the DB…
Events coming from the IoT Box were lost in two cases: 1. Create a listener for device 1 2. Send an action to device 1 --> If the action arrives before the listener the event is never sent to the DB 1. Setup up two listeners for devices 1 & 2 2. After a few seconds, send two consecutive actions to devices 1 & 2 --> Everytime a longpolling request arrives, a new threading.Event object is created. The first action sets the event, then, before the new longpolling request arrives, the second action sets the same event, which is overwritten once the new longpolling request arrives. We now maintain a list of events, and when a longpolling request arrives on the IoT Box, we make sure that all events that occured in the last 5 seconds were received by the DB. If no events were pending, we wait 50 seconds to check if a new one pops up. TaskID: 2320958 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#61420
Forward-Port-Of: odoo/odoo#61787
Original PR description
Forward-Port-Of: odoo/odoo#61787
Events coming from the IoT Box were lost in two cases: 1. Create a listener for device 1 2. Send an action to device 1 --> If the action arrives before the listener the event is never sent to the DB 1. Setup up two listeners for devices 1 & 2 2. After a few seconds, send two consecutive actions to devices 1 & 2 --> Everytime a longpolling request arrives, a new threading.Event object is created. The first action sets the event, then, before the new longpolling request arrives, the s
Original PR description
Events coming from the IoT Box were lost in two cases: 1. Create a listener for device 1 2. Send an action to device 1 --> If the action arrives before the listener the event is never sent to the DB 1. Setup up two listeners for devices 1 & 2 2. After a few seconds, send two consecutive actions to devices 1 & 2 --> Everytime a longpolling request arrives, a new threading.Event object is created. The first action sets the event, then, before the new longpolling request arrives, the second action sets the same event, which is overwritten once the new longpolling request arrives. We now maintain a list of events, and when a longpolling request arrives on the IoT Box, we make sure that all events that occured in the last 5 seconds were received by the DB. If no events were pending, we wait 50 seconds to check if a new one pops up. TaskID: 2320958 Forward-Port-Of: odoo/enterprise#14612
task-2344226 task-2358066 task-2369332 Forward-Port-Of: odoo/enterprise#14736
Original PR description
task-2344226 task-2358066 task-2369332 Forward-Port-Of: odoo/enterprise#14736
Behavior prior to this commit: When we use "Send Schedule" with a shift created with a template, and the employee takes it without logging in (from the email), the system uses GMT to compute the timezone for the shift start / end time, and the shift ends up with the wrong timezone for the employee. This happens because in that case, the planning class uses the user's timezone, rather than the browser's, to determine the timezone to use for the shift, and since the user is not logged in
Original PR description
Behavior prior to this commit: When we use "Send Schedule" with a shift created with a template, and the employee takes it without logging in (from the email), the system uses GMT to compute the…
Behavior prior to this commit: When we use "Send Schedule" with a shift created with a template, and the employee takes it without logging in (from the email), the system uses GMT to compute the timezone for the shift start / end time, and the shift ends up with the wrong timezone for the employee. This happens because in that case, the planning class uses the user's timezone, rather than the browser's, to determine the timezone to use for the shift, and since the user is not logged in the public user's timezone is used (which is not set, so it defaults to UTC) Behavior after this commit: When an employee assigns themselves to a slot created with a template, they will have the time set in the template, in their own local timezone (as set on their employee record) The commit consistently uses the same method to determine the timezone to use: - first try the logged in user timezone - then the employee timezone - then the timezone passed in from the browser - and as a fallback, UTC opw-2373171 Forward-Port-Of: odoo/enterprise#14566
I try to make the tranlsation in Transifex but in Transifex there is no l10n_ modules, for that reason I make the PR to add translation @mart-e Could you help me to see if you can add that modules to transifex. Thanks in advance. Forward-Port-Of: odoo/enterprise#14727
Original PR description
I try to make the tranlsation in Transifex but in Transifex there is no l10n_ modules, for that reason I make the PR to add translation @mart-e Could you help me to see if you can add that modules to transifex. Thanks in advance. Forward-Port-Of: odoo/enterprise#14727
To allow excluding some journals, like IFRS, by default. Forward-Port-Of: odoo/enterprise#14694
Original PR description
To allow excluding some journals, like IFRS, by default. Forward-Port-Of: odoo/enterprise#14694