Daily updates from Odoo
Navigate
Branch
Wednesday, November 6, 2019
43 changes
New functionality added to Odoo
Adds the core accounting setup needed for Chilean companies to work under local tax authority rules, including partner fiscal details, official document types, tax data, banks, currencies, products, and reporting structures. This provides a practical baseline for small businesses and prepares the localization for future electronic invoicing support.
Original PR description
### Module: l10n_cl This commit includes important updates and basic accounting features for the Chilean localization, which represent the MVP that small company will need to operate under the SII…
### Module: l10n_cl This commit includes important updates and basic accounting features for the Chilean localization, which represent the MVP that small company will need to operate under the SII (Servicio de Impuestos Internos) regulations and guidelines. This commits also aims to prepare the base models and fields that will be eventually used for the electronic invoice module. Here is a summary of the main features: **Partner** _Identification Type:_ Selection field that includes the identification documents used by the partners. This field is a common requirement on customers for the sales/purchase transactions. _Tax Payer Type:_ Indicates the fiscal regime related to the partner which is a key factor in Chilean accounting to determine the most frequently used document type applicable on the invoicing process. **Dependencies:** 10n_latam_base **Document Type** When creating Invoices and Vendor Bills, a specific document type will be added, the next document types are included by default as part of the localization. Factura Electrónica (33) Factura no Afecta o Exenta Electrónica (34) Boleta Electrónica (39) Nota de Débito Electrónica (56) Nota Credito Electrónica (61) In case that additional Journal is required the user can enable them on the menu _Document Type_. **Dependencies:** 10n_latam_invoice_document **Journal** As general practice in Chile the sequences for the same document are usually shared between more than journal, specially sales Journals, so the next features are added on the journal : _User documents:_ Enables the option to add more than one sequence for the journal. Option to add sequences previously created so the can be shared between more than journal. _Button for New Sequences:_ When a particular set of sequence is required for a journal, this button creates a new sequence on for each of the document types active. **Sequences** - Journal: A many to many relations to the Journal was added in order to share the same sequence between several journals. - Document type: Relation to the document type mode. **Invoices** Document type: Indicates the type applicable for the transaction, the value is autopulated based on the SII Code of the partner and the document types available for the journal. **Master Data:** - Chart of Account - Predefined Taxes - Fiscal Positions -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update expands and refreshes the Chilean localization in Odoo, including accounting templates, taxes, tax reports, fiscal data, document types, banks, currencies, partners, products, and related setup data. Businesses operating in Chile benefit from more complete local compliance configuration and improved readiness for accounting and invoicing workflows.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds Chilean regions to Odoo’s standard country and state data. Businesses operating in Chile can now use accurate regional information in addresses, contacts, and localization-related workflows.
Original PR description
Description of the issue/feature this PR addresses: Add Chilean regions as states -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Recruitment teams now get a dedicated dashboard with dynamic reporting to track hiring activity and refusal reasons. This makes it easier for managers to understand recruitment performance, spot bottlenecks, and make data-driven hiring decisions.
Original PR description
Description of the issue/feature this PR addresses: Add dashboard in recruitment id=2003841
Enhancements to existing features
Sales teams can now edit the phone number on a CRM lead even when a customer is linked. This avoids unintentionally changing the customer's main phone number while still allowing lead-specific contact details to be updated.
Original PR description
Before this commit, the user could not edit the lead phone field when a customer was assigned. The phone field was related to the phone of that customer. Now, the field related to the phone of the customer is removed. We can edit the phone field of the lead without modifying the customer one. task-2083470 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users who gain enough karma after completing a course quiz now see a clearer level-up animation and updated progress information. The change also corrects course completion display on user profiles and makes rank handling more consistent, improving reliability around gamification rewards.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Recruiters can now record a reason when refusing an applicant through a dedicated wizard. This improves recruitment reporting and helps teams track why candidates are declined, supporting better hiring insights and dashboard metrics.
Original PR description
Description of the issue/feature this PR addresses: When we refuse an applicant, open a wizard to add a refuse reason. id=2003841 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The leave calendar now visually highlights unusual working days, making schedule exceptions easier to spot when planning time off. This helps employees and managers better understand calendar context before approving or requesting leave.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The test suite was updated so it can run reliably without relying on preloaded demo data. This improves confidence in future changes, makes testing faster, and also includes fixes so internal users can access their own invoices and sales orders.
Original PR description
Purpose ======= This is the first huge step to improve the test suite in several ways: - Make them demo data independent, allowing to modify the demo data without having to adapt the tests depending on it. It also allows to have a beautiful + convenient demo dataset to make a demonstration, and to configure complex data in the tests to manage the corner cases. - Improve the test performances by converting them into SavepointCase. Each test will be rollbacked to it's initial state, after the setUpClass call. That way the different data are not re-created at each test for nothing. - Introduce several test classes in base/tests/common.py to launch a TransactionCase, HttpCase or SavepointCase test with an available demo user, portal user or a large set of partners. - This is the first step to tend to a rolling release process, allowing to execute the tests (or a subset of the tests) on a migrated base, for example. TaskID: 2075739
Learners now see a more obvious celebration when passing a quiz moves them to a new level. The quiz success window animates the progress bar, updates the level message, and refreshes motivational text so the achievement feels clearer and more rewarding.
Original PR description
PURPOSE If a user levels up after passing a quiz, we want to clearly show him in the success modal that he actually passed a level instead of just showing his new rank and xp gauge. This commit introduces an animation with the progress bar when the user is levelling up. After reaching the upper bound of the next level: - The progress bar goes back to 0 ; - The lower/upper bounds change to reflect the new reached level bounds ; - The message "Amazing!" becomes "Level Up!" ; - The motivational phrase changes with a fade out/fade in animation. LINKS PR : #39421 Task ID : 2032649
Timesheet-related records are now created in batches instead of one at a time. This improves performance when creating many timesheet entries, especially in workflows involving projects, holidays, sales timesheets, or accounting links.
Original PR description
**Creation of records will be done in batches.** - Used model_create_multi - Reworked on related functions(for eg: _timesheet_postprocess) so as to make it work in batches. This optimization is done in order to speed up the creation. Task Link- https://www.odoo.com/web?debug#id=1971460&action=327&model=project.task&view_type=form&menu_id=4720 Pad Link- https://pad.odoo.com/p/r.3817b8906a9ee8d5ebbf45b55b89a845 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change disables a problematic accounting test that was already marked as disabled. It helps keep development and validation workflows stable while the underlying test issue can be addressed separately.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Planning calendar now shows days when employees are unavailable in the My Planning view. This helps users understand availability at a glance and plan work more accurately without switching contexts.
Original PR description
id=2088873
Timesheet grid entries are now created in batches instead of one by one. This should make creating multiple timesheet records faster and improve responsiveness for users working with larger timesheet updates.
Original PR description
**Creation of records will be done in batches.** - Used model_create_multi and changed the code accordingly for creation in batches This optimization is done in order to speed up the creation. Task Link- https://www.odoo.com/web?debug#id=1971460&action=327&model=project.task&view_type=form&menu_id=4720 Pad Link- https://pad.odoo.com/p/r.3817b8906a9ee8d5ebbf45b55b89a845
The test suite was updated so accounting-related tests create the data they need instead of depending on preloaded demo records. This makes future demo data changes safer, improves test speed, and supports more reliable validation across migrated databases.
Original PR description
Purpose ======= This is the first huge step to improve the test suite in several ways: - Make them demo data independent, allowing to modify the demo data without having to adapt the tests depending on it. It also allows to have a beautiful + convenient demo dataset to make a demonstration, and to configure complex data in the tests to manage the corner cases. - Improve the test performances by converting them into SavepointCase. Each test will be rollbacked to it's initial state, after the setUpClass call. That way the different data are not re-created at each test for nothing. - Introduce several test classes in base/tests/common.py to launch a TransactionCase, HttpCase or SavepointCase test with an available demo user, portal user or a large set of partners. - This is the first step to tend to a rolling release process, allowing to execute the tests (or a subset of the tests) on a migrated base, for example. TaskID: 2075739
Helpdesk SLA policies can now include a deadline for assigning tickets within a specific timeframe. This helps teams monitor how quickly new tickets are picked up, improving accountability and response management.
Original PR description
SLA Policies: get tickets assigned id=1974097
Resolved issues and error corrections
Fixes an intermittent issue where changing the date of a bank statement could leave neighboring statements linked to the wrong previous statement. This improves reliability of bank statement records and reduces sporadic errors when statements are reordered.
Original PR description
…tement Let's assume the following order of bank statement: 1 - 2 - 3 - 4 and now we change the date of statement 2 to be at the end 1 - 3 - 4 - 2 Changing the date triggers the recompute on record…
…tement Let's assume the following order of bank statement: 1 - 2 - 3 - 4 and now we change the date of statement 2 to be at the end 1 - 3 - 4 - 2 Changing the date triggers the recompute on record 2, that will correctly change it's previous_statement_id to 4, however we also have to change to value of record 3 so that it points towards record 1. This was previously done inside the recompute function by use of a simple search and an assignation on record 3. However this caused some random issues as if we try to access the record 3 value just after having change record 2 value, the ORM might not have yet call the method to recompute record 2 (this is called when we try to access record 2 value but we didn't do it in this case). Therefore the value in record 3 might not have changed yet. Hence the error spotted. The reason why this error only happen some of the time is probably due to some method inside the ORM where we read the value on record and those value are in a set meaning that it is not ordered and sometimes when we were lucky the recompute happened before we tried to read the value of the other record. The solution to this problem is to move the logic of other statements to recompute (in the example record 3) inside the create/write method. And instead of assigning the value directly only mark those record as needing to be recompute. That way whenever we try to access the value of such record (record 3 in this case), if it was not yet recomputed, it will be done at that time
Receipt validation no longer crashes when a tracked product uses expiration dates but has no default expiration period set. This helps warehouse teams process incoming goods with manually entered expiration dates reliably.
Original PR description
How to reproduce: - Create a tracked product using expiration dates and don't set the `expiration_time` field; - Create a receipt for this product (using "Create New Lots/Serial Numbers") and confirm it; - Create a move line for this product and define an expiration date; - Valid the picking -> Traceback. The issue was as `expiration_time` isn't set on product, the production lot created on the receipt's validation don't have an `expiration_date`. So, if the `expiration_date` is set on the receipt move line, the production lot will try to get a time delta with its unset `expiration_date`, causing the traceback. task-2119330
Code cleanup and technical improvements
Website carousel and quote carousel blocks were reorganized to behave more consistently in the page editor. This reduces editing glitches, allows separate backgrounds for carousels and slides, and improves duplicated carousel handling.
Original PR description
Previously, the carousel and quotes carousel snippets were the only ones that were not enclosed in section blocks. This had a number of undesirable side effects, such as editing the anchor on the…
Previously, the carousel and quotes carousel snippets were the only ones that were not enclosed in section blocks. This had a number of undesirable side effects, such as editing the anchor on the carousel breaking the carousel functionality, and the inability to separately choose a background for the carousel itself and individual slides. I also used this opportunity to move controls relative to the entire carousel onto the carousel itself rather than the individual slides. The sizing_y (vertical padding) will however keep targeting individual slides, as the carousel uses the height of its tallest slide, and also because padding on the carousel will not get covered by slide backgrounds and saty blank, which is unwanted. Lastly, most of the snippet options for the carousel were rewritten, as they were quite broken. There was some compatibility code for saas-3 left, some useless events were bound to the controls, even though they were already handled through event-delegation at the document level. Finally, most of the edition features were broken on duplicated carousels since the onClone method wasn't reassigning most of the things it needed to. task-2090180
Attachment access checks were simplified so the system directly verifies whether the current user is an internal employee, administrator, or superuser. This reduces internal complexity while keeping responsibility for granting attachment access with the relevant business flow or controller.
Original PR description
/cc @ryv-odoo
This change simplifies how Odoo checks access to file attachments. It removes an overly broad employee-user requirement and leaves access decisions to the specific screens or features that use each attachment, reducing unnecessary access issues.
Original PR description
Since the commit 62c9dedafda0cbdc618641eaa80c49535ab0b5f6, the attachment required always a employee user access. Simplify corner case of attachment access check definition. It is the role of controller/model using attachment to give the rigth access for attachements. TASK_ID: 2004031 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
Pulled list directly from https://github.com/odoo/odoo/blob/13.0/odoo/addons/base/models/ir_module.py#L278 ## Description of the issue/feature this PR addresses: The documentation for `__manifest__.py` does not make it clear that the value of `license` must be one value from a set list of values, and not just any string. In addition, the docs for this does not list the actual values. ## Current behavior before PR: No Odoo product behavior changes ## Desired behavior after PR is me
Original PR description
Pulled list directly from https://github.com/odoo/odoo/blob/13.0/odoo/addons/base/models/ir_module.py#L278 ## Description of the issue/feature this PR addresses: The documentation for…
Pulled list directly from https://github.com/odoo/odoo/blob/13.0/odoo/addons/base/models/ir_module.py#L278 ## Description of the issue/feature this PR addresses: The documentation for `__manifest__.py` does not make it clear that the value of `license` must be one value from a set list of values, and not just any string. In addition, the docs for this does not list the actual values. ## Current behavior before PR: No Odoo product behavior changes ## Desired behavior after PR is merged: No Odoo product behavior changes ## Related * See #39270 for my signature addition * In #39273 I was asked to have this against 11.0 * This patch applies to 11.0, 12.0, and 13.0 * https://github.com/odoo/odoo/blob/11.0/odoo/addons/base/module/module.py#L279 * https://github.com/odoo/odoo/blob/12.0/odoo/addons/base/models/ir_module.py#L281 * https://github.com/odoo/odoo/blob/13.0/odoo/addons/base/models/ir_module.py#L278 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39354
Task: https://www.odoo.com/web?#id=2116040&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.59f598d9dd7bab55708a5098288eff79 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#39578
Original PR description
Task: https://www.odoo.com/web?#id=2116040&action=327&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.59f598d9dd7bab55708a5098288eff79 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#39578
…tton This commit fixes the "quiz finish" modal display by correctly hiding it when the user clicks on the "Next" button in the modal. Without this fix, the user could run into an issue where the "modal backdrop" would stay on the screen, locking all actions and forcing a manual refresh. Task#2118532 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
Original PR description
…tton This commit fixes the "quiz finish" modal display by correctly hiding it when the user clicks on the "Next" button in the modal. Without this fix, the user could run into an issue where the "modal backdrop" would stay on the screen, locking all actions and forcing a manual refresh. Task#2118532 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#39746
This commit: https://github.com/odoo/odoo/commit/0eba50dd1c33a08f8862a5718149e61b822e1b5a introduced a 'return' in the survey.js script: return load_chart(chartConfig, '#scoring_results_chart'); This makes the rest of the script completely skipped and bypasses all the filter features. task-2116078 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39555
Original PR description
This commit: https://github.com/odoo/odoo/commit/0eba50dd1c33a08f8862a5718149e61b822e1b5a introduced a 'return' in the survey.js script: return load_chart(chartConfig, '#scoring_results_chart'); This makes the rest of the script completely skipped and bypasses all the filter features. task-2116078 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39555
Fixed a bug where you got a traceback when trying to join a course on a quiz preview not in fullscreen mode. Task ID : 2079476 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#38051
Original PR description
Fixed a bug where you got a traceback when trying to join a course on a quiz preview not in fullscreen mode. Task ID : 2079476 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#38051
When a pos order is sent to the server, the field 'to_invoice' is never sent to the server which lead to always having a value to 'false'. We are now sending correctly this value to the server, and we can also base the fact to create an invoice on the value of each order. Because beeing offline could lead to create an order that should be invoiced as one that should not be. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR
Original PR description
When a pos order is sent to the server, the field 'to_invoice' is never sent to the server which lead to always having a value to 'false'. We are now sending correctly this value to the server, and we can also base the fact to create an invoice on the value of each order. Because beeing offline could lead to create an order that should be invoiced as one that should not be. 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#39843
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#39855
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39855
Task : https://www.odoo.com/web?#id=1883428&action=333&active_id=131&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.4bdc2c8043f94f2ef5c3d476e430e1cb Forward-Port-Of: odoo/odoo#39849
Original PR description
Task : https://www.odoo.com/web?#id=1883428&action=333&active_id=131&model=project.task&view_type=form&menu_id=4720 Pad: https://pad.odoo.com/p/r.4bdc2c8043f94f2ef5c3d476e430e1cb Forward-Port-Of: odoo/odoo#39849
Fixes #39688 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39721
Original PR description
Fixes #39688 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39721
The commit 3c4bb08 fixed an issue about reservation from transit location for versions from 11.0 to 12.0 by soften the record rule on stock.move From 12.3, we need to additionnaly soften the stock.move.line rule to have the same result as this model has a record rule too since that version 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
Original PR description
The commit 3c4bb08 fixed an issue about reservation from transit location for versions from 11.0 to 12.0 by soften the record rule on stock.move From 12.3, we need to additionnaly soften the stock.move.line rule to have the same result as this model has a record rule too since that version 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#39809 Forward-Port-Of: odoo/odoo#39791
- In the sales or accounting module, create some invoices. - Select them then click on `action > send & print` - The wizard opens but not in the mass mail mode. It creates some inconsistency and if you click on send, the invoices are sent to the wrong customer. Sometimes, the invoices are not sent at all. I think the problem comes from the `_compute_composition_mode` method who set the value of `composition_mode` on the wizard instead of on the composer. OPW-2085837 Descripti
Original PR description
- In the sales or accounting module, create some invoices. - Select them then click on `action > send & print` - The wizard opens but not in the mass mail mode. It creates some inconsistency and if you click on send, the invoices are sent to the wrong customer. Sometimes, the invoices are not sent at all. I think the problem comes from the `_compute_composition_mode` method who set the value of `composition_mode` on the wizard instead of on the composer. OPW-2085837 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#39738
Followup for d22866f8427c5500014b6502cbfe127b678204a8 Without this fix the rendering associated with this view would crash because after the replace the field became a string and it crash when retrieving it with t-field -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39753 Forward-Port-Of: odoo/odoo#39732
Original PR description
Followup for d22866f8427c5500014b6502cbfe127b678204a8 Without this fix the rendering associated with this view would crash because after the replace the field became a string and it crash when retrieving it with t-field -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#39753 Forward-Port-Of: odoo/odoo#39732
* The purchase import template was never updated to reflect the Big Demo Data Changes (58fc4e440952bde533c8aa1dc8b6fc2440a05337). * The employees template apparently never worked: "married (or similar)" was removed before that task was merged. Forward-Port-Of: odoo/odoo#39800
Original PR description
* The purchase import template was never updated to reflect the Big Demo Data Changes (58fc4e440952bde533c8aa1dc8b6fc2440a05337). * The employees template apparently never worked: "married (or similar)" was removed before that task was merged. Forward-Port-Of: odoo/odoo#39800
Forward-Port-Of: odoo/odoo#39249 Forward-Port-Of: odoo/odoo#38766
Original PR description
Forward-Port-Of: odoo/odoo#39249 Forward-Port-Of: odoo/odoo#38766
Before this commit, only `account.move` of type `in_invoice` were covered by the settings of documents. A restriction that was introduced with the refactor of accounting. This commit fixes this issue and allows all 4 types of invoices to be covered by the settings of `documents_account`. opw:2118941 Forward-Port-Of: odoo/enterprise#6573
Original PR description
Before this commit, only `account.move` of type `in_invoice` were covered by the settings of documents. A restriction that was introduced with the refactor of accounting. This commit fixes this issue and allows all 4 types of invoices to be covered by the settings of `documents_account`. opw:2118941 Forward-Port-Of: odoo/enterprise#6573
Fix grey zone, in case of precision: half and scale = week or month id=2088873 Forward-Port-Of: odoo/enterprise#6306
Original PR description
Fix grey zone, in case of precision: half and scale = week or month id=2088873 Forward-Port-Of: odoo/enterprise#6306
Forward-Port-Of: odoo/enterprise#6232
Original PR description
Forward-Port-Of: odoo/enterprise#6232
Add some tests, - Tests the priority on post 1. Image, if the user add images, they should be displayed on LinkedIn 2. URLs, if the user writes URLs in the message, but doesn't add an image, we must display a preview of the URL on LinkedIn 3. Text - Test if the post is marked as success/failure regarding the API response - Test if the accounts are marked as "disconnected" if the post failed Task #2081643 Forward-Port-Of: odoo/enterprise#5995
Original PR description
Add some tests, - Tests the priority on post 1. Image, if the user add images, they should be displayed on LinkedIn 2. URLs, if the user writes URLs in the message, but doesn't add an image, we must display a preview of the URL on LinkedIn 3. Text - Test if the post is marked as success/failure regarding the API response - Test if the accounts are marked as "disconnected" if the post failed Task #2081643 Forward-Port-Of: odoo/enterprise#5995
With a web_gantt view, if we click on a slot quickly after writing, values in the dialog box may be not updated. To fix this problem, we add mutex on the write function and before opening the dialog, we wait for this mutex. Forward-Port-Of: odoo/enterprise#6560
Original PR description
With a web_gantt view, if we click on a slot quickly after writing, values in the dialog box may be not updated. To fix this problem, we add mutex on the write function and before opening the dialog, we wait for this mutex. Forward-Port-Of: odoo/enterprise#6560
Fine-tuning of 1530d31dd3c25ffd520819d90e4d904e0a22b865 Before this commit, the value in the EC sales list report was always 0. It was adding the balance of the move lines, and each move has two move lines one with an amount in the credit and one with an amount in the debit. Now, the value is the sum of the invoices (moves) opw-2081572 Forward-Port-Of: odoo/enterprise#6558
Original PR description
Fine-tuning of 1530d31dd3c25ffd520819d90e4d904e0a22b865 Before this commit, the value in the EC sales list report was always 0. It was adding the balance of the move lines, and each move has two move lines one with an amount in the credit and one with an amount in the debit. Now, the value is the sum of the invoices (moves) opw-2081572 Forward-Port-Of: odoo/enterprise#6558
In version 12.0 the portal report assets were stored in the `assets_common` bundle, in version 13.0 the report assets are properly set in it's own bundle `report_assets_common`. This commit moves the assets for e-invoicing to `report_assets_common` bundle so the QR Code and the Original String are properly rendered in all reports. Before change: 
Original PR description
In version 12.0 the portal report assets were stored in the `assets_common` bundle, in version 13.0 the report assets are properly set in it's own bundle `report_assets_common`. This commit moves the assets for e-invoicing to `report_assets_common` bundle so the QR Code and the Original String are properly rendered in all reports. Before change:  After:  Forward-Port-Of: odoo/enterprise#6534
When requesting an appraisal, if no recipient is given in the wizard there is a traceback. An message cannot be sent to nobody. This commit makes the recipient field required in the view. Should be required at the model level in master branch (can't do that in stable 13.0) Forward-Port-Of: odoo/enterprise#6453
Original PR description
When requesting an appraisal, if no recipient is given in the wizard there is a traceback. An message cannot be sent to nobody. This commit makes the recipient field required in the view. Should be required at the model level in master branch (can't do that in stable 13.0) Forward-Port-Of: odoo/enterprise#6453