Daily updates from Odoo
Friday, December 20, 2019
20 changes · master
Enhancements to existing features
The CRM lost opportunity flow no longer opens an extra create/edit window when users add a new lost reason. This makes the process quicker and avoids an unnecessary interruption during opportunity management.
Original PR description
Remove the create_edit option when creating a new lost reason to avoid displaying an unnecessary wizard. 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
The timesheet timer file was renamed to avoid issues on macOS systems that do not distinguish between uppercase and lowercase filenames. This helps prevent setup or loading problems for users and developers working with the timesheet feature on affected machines.
Original PR description
- Before this commit file name is Timer.js which create issue in macOS due to non case-sensitive harddisk partition. So file renamed to timer_mixin.js
The quiz reward attempt fields are now grouped together when exporting data and when creating custom filters. This makes reward-related settings easier for users to locate and manage consistently.
Resolved issues and error corrections
This fix adjusts an internal web testing helper so automated tests wait for screen updates in the correct order. It reduces random test failures, helping developers validate changes more reliably without affecting everyday users.
Original PR description
Revision on [1]. Commit above made changes to test helper `nextTick()`, so that it waits for `window.nextAnimationFrame()` (shorten, 'rAF'). This was useful to wait for OWL rendering, since OWL…
Revision on [1]. Commit above made changes to test helper `nextTick()`, so that it waits for `window.nextAnimationFrame()` (shorten, 'rAF'). This was useful to wait for OWL rendering, since OWL renders on next animation frame. From a theoretical standpoint, the helper should wait at least as much time as before, as it adds either no slowdown (rAF is readily available), or a few milliseconds wait (rAF waits for next available animation frame). However, some old tests show non-deterministic behaviours, resulting to crashes [2]. It suggested, for some reasons, that `nextTick()` did not wait long enough for re-render... Which is surprising considering explanation above! Some of these tests have been fixed, assuming it was caused by un- guaranteed order of successive `setTimeout(0)` [3]. Unfortunately, this does not explain why it never crashed before the change on `nextTick()`... After investigation, we think that this behaviour comes from rAFs having their own task queue, which no longer guarantees that queued tasks happen after queued micro-tasks: When the requested next animation frame is readily available, the callback of `requestAnimationFrame()` is immediately called and waits for `setTimeout(0)`. The `setTimeout(0)` await is resolved before any other queued async micro-tasks, so that `nextTick()` is resolved sooner than expected. This would explain how `nextTick()` does not wait long enough for rendering from the loads of resolved Promises, even though there is a promise resolution after `setTimeout(0)`. This commit fixes the issue by moving the await `setTimeout(0)` before the rAF call, so that it correctly waits render from chain of resolved promises (since the `setTimeout(0)` is awaited in the same main task queue). [1] https://github.com/odoo/odoo/commit/b0941d19a07b08fabc64a284b58e57edc46203dd [2] http://runbot.odoo.com/runbot/build/771505 and http://runbot.odoo.com/runbot/build/752855 [3] https://github.com/odoo/odoo/commit/6cbfdbce2d0f1b567b6a6d6f637fe2a476980acc
This fixes how Marketing Automation determines the mailing type linked to a campaign. It helps ensure campaigns use the correct mailing information, reducing errors or inconsistencies when managing automated mailings.
Original PR description
Oversight of cf06cabd9743d955cbf700fdee1dea28a7c65cae Task #2088158
Code cleanup and technical improvements
The quiz completion popup in Website Slides was reorganized into its own reusable component. This keeps the course quiz code simpler and easier to maintain without changing the learner experience.
Original PR description
This commit moves the finished quiz modal into a dedicated dialog widget. It will lessen the "slide_course_quiz.js" code length and simplify the dialog template. Task ID : 2126621 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
This update records the corporate contributor license agreement signature for Serenite24h24. It helps ensure their contributions are properly covered by Odoo's legal contribution process.
Original PR description
Corporate CLA signature for Serenite24h24.
Miscellaneous changes
When an attachment is linked to a record (res_id and res_model are set) we check the access rights and access rules of that record. The access we check on linked record has changed as follow: - 15905e78 (2013) => we check `write` access right/rule for `create` - f5ebc50 (2014) => we check `write` access right for all mode - 66644e8 (2015) => we check write access right for all but create mode So currently we check on the linked record for each mode: - create: write access right /
Original PR description
When an attachment is linked to a record (res_id and res_model are set) we check the access rights and access rules of that record. The access we check on linked record has changed as follow: - 15905e78 (2013) => we check `write` access right/rule for `create` - f5ebc50 (2014) => we check `write` access right for all mode - 66644e8 (2015) => we check write access right for all but create mode So currently we check on the linked record for each mode: - create: write access right / write access rule - read: read access right / read access rule - write: write access right / write access rule - unlink: write access right / unlink access rule The behavior is not expected for `unlink`, we should check if we have write access through access rules instead of checking unlink access. Without the change, the added test failed with a `unlink` access rule AccessError on the linked record. opw-2154448 Forward-Port-Of: odoo/odoo#42236 Forward-Port-Of: odoo/odoo#41814
Description of the issue/feature this PR addresses: Don't crash if there is an issue during the loading of a manual field Current behavior before PR: Odoo crashes and stops Desired behavior after PR is merged: Odoo continues and starts -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42011
Original PR description
Description of the issue/feature this PR addresses: Don't crash if there is an issue during the loading of a manual field Current behavior before PR: Odoo crashes and stops Desired behavior after PR is merged: Odoo continues and starts -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42011
Assume F and G are computed by the same method on a missing record R. During recomputation of F on R, the compute method is called but fails because R is missing. Both fields are re-marked to compute (because computation failed), then F is discarded (because R is missing). Then comes G's turn: G is accessed on R and the computation fails. Both fields are re-marked to compute (because computation failed), then G is discarded (because R is missing). Now F is marked again to compute: the
Original PR description
Assume F and G are computed by the same method on a missing record R. During recomputation of F on R, the compute method is called but fails because R is missing. Both fields are re-marked to compute (because computation failed), then F is discarded (because R is missing). Then comes G's turn: G is accessed on R and the computation fails. Both fields are re-marked to compute (because computation failed), then G is discarded (because R is missing). Now F is marked again to compute: the process never ends. To avoid this situation, discard all fields to recompute on missing records. Forward-Port-Of: odoo/odoo#42202
To reproduce the bug: 1. Install `crm`. 2. Uninstall `iap`. 3. Go to any `res.config.settings` view. Odoo will crash because the `iap_buy_more_credits` JS widget doesn't exist. I'm moving the part that uses that widget from `crm` to `crm_iap_lead_enrich`. Anyways, it didn't have sense to buy credits if you didn't have installed the module, and that section was hidden if the module wasn't installed. Since `crm_iap_lead_enrich` depends on `iap`, this problem will not happen anymore.
Original PR description
To reproduce the bug: 1. Install `crm`. 2. Uninstall `iap`. 3. Go to any `res.config.settings` view. Odoo will crash because the `iap_buy_more_credits` JS widget doesn't exist. I'm moving the part that uses that widget from `crm` to `crm_iap_lead_enrich`. Anyways, it didn't have sense to buy credits if you didn't have installed the module, and that section was hidden if the module wasn't installed. Since `crm_iap_lead_enrich` depends on `iap`, this problem will not happen anymore. @Tecnativa TT20916 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41307
I make a Pull Request for signature CLA. Company: Vmax Ltd,.Co Name: Vmax -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42212
Original PR description
I make a Pull Request for signature CLA. Company: Vmax Ltd,.Co Name: Vmax -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42212
Channels uses tags allowing to categorize and filter content. For that purpose a m2m exists between channels (slide.channel) and tags (slide.channel .tag). The 2many relationship from tags to channels holds however a wrong comodel name. It has no impact on code since relationship table is correctly defined and current code does not use the channel_ids fields from tags. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merge
Original PR description
Channels uses tags allowing to categorize and filter content. For that purpose a m2m exists between channels (slide.channel) and tags (slide.channel .tag). The 2many relationship from tags to channels holds however a wrong comodel name. It has no impact on code since relationship table is correctly defined and current code does not use the channel_ids fields from tags. 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#42230
Activate a Fiscal position with a defined tax mapping(i.e. 15%). Add to a product the same tax. Set the tax to be included in price. In POS Settings add the default fiscal position as the one from before. Now open POS and add the product. The total price calculated will be wrong: the tax is added twice, one from the product line and one from the localization. Filtering out already considered taxes avoid the issue on the assumption that there is no tax which should be calculated multip
Original PR description
Activate a Fiscal position with a defined tax mapping(i.e. 15%). Add to a product the same tax. Set the tax to be included in price. In POS Settings add the default fiscal position as the one from before. Now open POS and add the product. The total price calculated will be wrong: the tax is added twice, one from the product line and one from the localization. Filtering out already considered taxes avoid the issue on the assumption that there is no tax which should be calculated multiple times for the same order line. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42180 Forward-Port-Of: odoo/odoo#41913
Since the name updates are done in onchanges, the relational values may be newIds records and therefore we have to use their _origin for comparisons. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42201
Original PR description
Since the name updates are done in onchanges, the relational values may be newIds records and therefore we have to use their _origin for comparisons. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#42201
The `color` attribute allows specifying a field by which the calendar view will color the event entries in the view. In views where this attribute is not defined, the event was instead given the `text-white` class, which rendered the event invisible in the calendar, save for a slight left-border. This commit just use the 1st color class by default in such cases, ensuring all events are visible. opw-2145652 Forward-Port-Of: odoo/odoo#42185
Original PR description
The `color` attribute allows specifying a field by which the calendar view will color the event entries in the view. In views where this attribute is not defined, the event was instead given the `text-white` class, which rendered the event invisible in the calendar, save for a slight left-border. This commit just use the 1st color class by default in such cases, ensuring all events are visible. opw-2145652 Forward-Port-Of: odoo/odoo#42185
…ate_invoices The function was renamed in f808f36f3843875f0b87ab191277970564201429 Forward-Port-Of: odoo/enterprise#7372
Original PR description
…ate_invoices The function was renamed in f808f36f3843875f0b87ab191277970564201429 Forward-Port-Of: odoo/enterprise#7372
Before this commit, when an attachment was rendered and appended, there was no notification of any kind to allow the list to recompute its size. Now, when an attachment is rendered in a form, it triggers "DOM_updated" which will notify the list that it should render itself anew. Bug noticed on pad http://pad.odoo.com/p/feedback Forward-Port-Of: odoo/enterprise#7318
Original PR description
Before this commit, when an attachment was rendered and appended, there was no notification of any kind to allow the list to recompute its size. Now, when an attachment is rendered in a form, it triggers "DOM_updated" which will notify the list that it should render itself anew. Bug noticed on pad http://pad.odoo.com/p/feedback Forward-Port-Of: odoo/enterprise#7318
This makes a "fix" from the "workaround" from: https://github.com/odoo/odoo/issues/20986#issuecomment-345975748 A downpayment is created as a positive invoice, and then subtracted from the regular invoice. Since negative lines are ignored, it means downpayment are counted twice. The workaround is to set the deposit product TIC category as "Gift card" since no tax is applied on such products. So in TaxCloud we automatically check that the correct category is set on the deposit product
Original PR description
This makes a "fix" from the "workaround" from: https://github.com/odoo/odoo/issues/20986#issuecomment-345975748 A downpayment is created as a positive invoice, and then subtracted from the regular invoice. Since negative lines are ignored, it means downpayment are counted twice. The workaround is to set the deposit product TIC category as "Gift card" since no tax is applied on such products. So in TaxCloud we automatically check that the correct category is set on the deposit product, so that no configuration is needed to make it work properly. opw 2079677 Forward-Port-Of: odoo/enterprise#7294
Issue - Install social - Add a facebook account - Create a post - Synchronize The "Posts page: x" is not translated The popovers are not translated The placeholder is not translated when you add a comment Cause The "posts page" term is stored in the database like products' name. The popovers have the "data-content" attribute which is not translated The placeholder use t-att-placeholder which is not translated Cause Make th
Original PR description
Issue
- Install social
- Add a facebook account
- Create a post
- Synchronize
The "Posts page: x" is not translated
The popovers are not translated
The placeholder is not translated when you add a comment
Cause
The "posts page" term is stored in the database like products' name.
The popovers have the "data-content" attribute which is not
translated
The placeholder use t-att-placeholder which is not translated
Cause
Make the posts page term translatable like products
Use t-value and t-att-data-content for the popover content
Replace t-att-placeholder by placeholder
OPW-2153168
Forward-Port-Of: odoo/enterprise#7259