Tuesday, February 1, 2022
47 changes · master
New functionality added to Odoo
This change adds a command-line option to neutralize copied databases before investigation, helping prevent accidental emails, payments, external service calls, or tax reporting submissions. It also updates several business modules so their sensitive external integrations are disabled during this irreversible neutralization process.
Original PR description
When debugging a database, it's sometimes desirable to neutralize it to avoid undesired side effects like sending emails. This PR adds a generic method on models to neutralize the current database. This method have to be overridden by modules models. The neutralize operation cannot be reversed should only be used on a database copy.
Businesses can now require users to confirm logins with a code sent by email when they have not set up an authenticator app. Administrators can enforce this extra login protection for employees only or for all users, including portal users.
Original PR description
Add the possibility to force the two-factor authentication for all users, using a two-factor authentication by email when the 2FA using an Authenticator app is not configured for the user. Two possibilities: - Force the 2FA only for employee users using the system parameter `auth_totp.policy=employee_required` - Force the 2FA for all users, employees and portals, using the system parameter `auth_totp.policy=all_required`
Enhancements to existing features
The mail app now includes a database optimization that helps retrieve the latest channel messages more quickly. This can reduce waiting time in discussions or messaging areas, especially on larger systems with many messages.
Original PR description
Before this PR, the query from _channel_last_message_ids could take a significant amount of time. This add an index to speed up the query. task-2746108
Resolved issues and error corrections
This change updates an internal accounting test so it correctly handles a newly added calculated field. It helps keep development checks reliable and prevents unrelated test failures from slowing future accounting updates.
Original PR description
In master, the tax template consistency test is broken since 8fb53c53c3128e8cea7ef20b9ab4946ac2f9b7d9 Fix this to make sure we add an exception for that new computed field as it should not be in the template. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This update removes several old, unused internal mechanisms and simplifies how records are saved in Odoo. The change reduces maintenance overhead and supports more efficient future database operations, with little expected direct impact on day-to-day users.
Original PR description
Several changes to simplify CRUD, to avoid maintain unused feature and to be able to make a clean bulk insert (PR: https://github.com/odoo/odoo/pull/80961) ### [REM] base: remove _sequence attribute…
Miscellaneous changes
With [1] in 13.0, the blog post layouts were reviewed. At the same time, new demo data was introduced. By default, with demo data, you have now two different blogs. The JS tour was adapted so that when you create a new blog post, a step explains you have to select the blog you want to create the post in with the dialog that opens. The main problem that this PR aims to solve is that all users start without demo data and thus with only one blog... so with the current tour, the users are bloc
Original PR description
With [1] in 13.0, the blog post layouts were reviewed. At the same time, new demo data was introduced. By default, with demo data, you have now two different blogs. The JS tour was adapted so that…
Odoo now handles large batches of newly created records more efficiently by grouping database inserts instead of processing each record separately. This can improve performance for imports, data generation, and other operations that create many records at once, while also simplifying some internal database cursor handling.
Original PR description
# POC: Batch `INSERT INTO` of `_create` method (`BaseModel`) ## Idea When we create several of record in database, we make one "INSERT INTO" (one sql request) by values (by record) which isn't…
# POC: Batch `INSERT INTO` of `_create` method (`BaseModel`)
## Idea
When we create several of record in database, we make one "INSERT INTO" (one sql request) by values (by record) which isn't efficient. Then make a bulk insert instead.
The goal is to batch the insertion of record and by extension speed up `create` method when we give it many values.
## HOW TO
Make a batched version of our INSERT INTO loop in the `_create` method.
### Performance testing
To test, we use the "populate script" of odoo-bin and by changing the batch size of it to get data depending on the number of values/record to create (check the branch `master-create-insert-batch-with-measurements-ryv`).
Because we know that the drawback of this approach is when values_list are sparse (we need to fill a lot of DEFAULT value). Then create a model ('worst.case') with 100 fields and with a "populate script" which create most sparse as possible values_list.
## `create` vs `_create` vs insertion loop vs 'insert into'
- `create` measure the time of the all `create` method of `BaseModel` (then not calculate the time of inherited create)
- `_create` measure the time of the all `_create` method of `BaseModel`
- 'Insertion loop' measure the time of the insertion loop: convert_to_column + creation of query + the 'INSERT INTO'. (we focus on this one)
- 'INSERT INTO' measure only the time made by the insert into queries.
Then `create` contains `_create`, `_create` contains 'Insertion loop' and 'Insertion loop' contains 'INSERT INTO'.
### Time figures
#### Before
#### After
### % Time figures
It is the % of time of the `create` method of each step (we try to improve the red and green ones) :
#### Before
#### After
## Focus on the 'insertion loop' time (what we change)
### Graph
### Table Results
#### `create`
#### `_create`
#### 'insertion loop'
#### 'insert into'
## Note
- The result are noisy, then is hard to conclude anything when the difference is small and the variance is high.
- The `mail.follower` aren't created in batch (fix in https://github.com/odoo/odoo/pull/80954), it is why we have only the data for mono create.
## Conclusion
It is clearly worth it for small model where the time of `create` method is mainly due to the insertion in DB. Also, the test was done on my compute where the database is local and the psql use a SSD: we can expect better result with a remote psql server and/or traditional hard disk.
In another hand, it increases a bit the complexity of the code.Employee sample data now includes working schedules for all employees and links some employees to users across multiple companies. This helps appointment planning reflect real employee availability when schedules are used.
Original PR description
Previously for `appointment`, now for `appointment_hr`, the computation of users' availability for appointment slots can be dependent on that person's work schedule if: * The user is linked to an employee * The user's employee has working hours defined (resource calendar) This commit provides working hours to all employees and a user to some, within a multi-company setup. Task-2728093 See odoo/enterprise#22642 See Task-2631088
The mail server setup screens now use existing authentication choices to identify Gmail connections, reducing extra options and making configuration clearer. Administrators also get a settings option to install Gmail integration more directly from the main settings area.
Original PR description
Purpose ======= A field `use_google_gmail_service` has been used in stable to define a mail server which use Gmail authentication. But now that the field `smtp_authentication` exists, we want to use it to simplify the mail server form view. For the incoming mail server, the field `server_type` will be used for the same purpose. Add a new field to have the option to install `google_gmail` in the main settings page. Task-2170676
Manufacturing teams can now divide a manufacturing order into several smaller orders or combine compatible orders for the same product and bill of materials. This gives planners more flexibility to adjust production quantities and consolidate work when priorities or capacity change.
Original PR description
Split a manufacturing order in several parts using the back order mechanism Merge several manufacturing orders related to the same product/bom by cancelling all of them and creating a new one task: 2662566 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
Appointment sample data now includes more work-hours appointment types and more available time slots. The data also better reflects common business setups by matching appointment users with the same company, supporting more realistic testing and performance validation.
Original PR description
Add some appointment_types with category 'work_hours'. Also ensures users from an appointment type are from the same company as it is the most common use case. Finally, to increase computing load, more slots are added per appointment type. Task-2728093 See odoo/odoo#80688
Vendor bill resets now handle related draft and posted assets more consistently, preventing outdated asset records and clearer error messages. Expense accounts also clear incompatible disallowed expense categories automatically, reducing hidden configuration mistakes and duplicate chatter entries.
Original PR description
The goal is to improve the following: - When trying to reset a Vendor Bill to draft that already has one or more posted asset(s) related, the UserError text was not correct. - When resetting a Vendor Bill to draft that already has one or more draft asset(s) related, those were left and not updated after re-posting the Vendor Bill. Now they will be unlinked a created again. - When changing an account type that already has a Disallowed Expenses Category, and setting a type that is not compatible with Disallowed Expenses, the field disappears from the view, but the value remains set. That is no longer the case. - Corrects a small bug that posted the non-deductible tax value twice in the chatter when an asset was created automatically. task-2747209
Several country-specific invoicing, tax, point-of-sale certification, and mobile messaging components now support database neutralization. This helps companies prepare copied databases for testing or staging by disabling or replacing sensitive live-service settings and reducing the risk of accidental real-world transactions.
Original PR description
A _neutralize model method was added in order to neutralize a database. This commit adds the implementation of this method for various models. Companion of https://github.com/odoo/odoo/pull/67825 Task id: 1818795
This fix ensures archived records still load their related chatter information, such as followers, activities, and suggested recipients. Business users can now view and use communication details on archived documents without missing data or errors.
Original PR description
With a recent commit[1], we now gather the chatter related data with a single controller ('/mail/thread/data') which was a bit scattered previously. With this controller, instead of searching in…
With a recent commit[1], we now gather the chatter related data with a
single controller ('/mail/thread/data') which was a bit scattered
previously. With this controller, instead of searching in dedicated
model, we now simply use the main document/record itself and it's
fields whenever possible. For example, previously for the followers,
we used to search data from 'mail.followers' model, but now we simply
use `message_follower_ids` field of the record itself.
The problem with this approach is, if the record is archived, we won't
be able to fetch the related data. That leads to empty follower list/
activities and a trackback while getting suggested recipients.
This PR fixes the issue by loading the record even if it's
archived, and thus fetching the data required by chatter.
commit[1] - https://github.com/odoo/odoo/commit/e0913197ac84b25b40e7599a6432362141d104c9
TaskID-2748030
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe payment registration process now automatically uses the partner's bank account and prevents users from changing or creating a different recipient account for inbound and cash-related payments. This helps reduce payment mistakes and hides the bank account field when it is not relevant for cash journals.
Original PR description
Currently: the "register payment" wizard allows selecting different bank accounts or even creating one when registering a payment on customer invoice/vendor refund. Should be: the field should be set to partner_bank_id and be set as readonly. Task ID: 2710936 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change temporarily turns off unreliable automated tests in the sales stock area until they can be fixed properly. It helps keep development checks stable and avoids false failures that could slow down future work, with no expected impact on users.
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents activities and mailing traces from being saved without a valid linked business record. It improves data reliability and avoids follow-up items or mailing history entries pointing to missing records, including in sales workflows.
Original PR description
Activities and mailing trace models are linked to records through a model and a many2one reference field. The latter one is required but is implemented like an integer field, meaning writing 0 is actually a valid value for 'required'. In this commit we add a constraint to ensure we never update activities with a void res_id value. Same for mailing traces. Source: internal feedback about activities with 0 as res_id Task-2694133
This fix reverts an unintended change to labels on the payment form in Accounting. It restores the expected wording so users see clearer, familiar field names while working with payments.
Original PR description
The part of 9311b087e1cdcfd2e1c4ab4a559a55d517b542fa affecting field labels on account.payment's form view was mistakenly merged. The actual fix regarding those labels is done in 15.0 here https://github.com/odoo/odoo/pull/83674 .
Improved how Odoo finds failed outgoing mail, SMS, and letters for the current user. This prevents long waits in failure-related views or actions, reducing response time from potentially over 20 seconds to near-instant in affected cases.
Original PR description
We are currently lacking an index with (author, failure) due to the information being spread out in two different tables which are both rather big (there are a lot of non-failure messages for the current user, as well as a lot of failure messages for other users), so the fetch of failures for the current user can become extremely slow (> 20s). With this new index, the query takes less than 1ms. task-2742946
Saving a record now avoids sending unchanged selection data to the server. This prevents unrelated sales order lines from being recalculated, reducing unexpected price changes and improving save behavior.
Original PR description
Following recent conversion of onchanges to computes in the sale scope, it was observed that updating one line triggered price recomputation in other lines (which isn't expected). After investigation, it seems that the `product_packaging_id` field is considered modified and sent on SO save for all the lines, which triggers the `product_uom_qty` record computation, then the whole price computation is triggered, since it depends on that quantity field. This commit aims to fix this case by only considering a m2o field as modified if its value was effectively changed. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes visual inconsistencies when adding text fields during signing and restores pinch-to-zoom behavior on mobile. It improves the signing experience by making text fields look consistent and preventing mobile errors while users zoom documents.
Original PR description
This task fixes some UI issues found in sign while testing v15.1 and v15.2 - [FIX] sign: fix edit while signing text type handlers and font-size When a text sign item is added while signing, its font-size and handlers have different size than an item created in the template editor. This commit fixes the css of the sign item and also fixes the default width and height of text sign items. - [FIX] sign: fix pinching in mobile In mobile version of sign, pinching the screen while signing should zoom-in/ zoom-out. However, after refactoring the js code in task-2664886, pinching started causing an error. This commit fixes this issue, preventing the error caused from the loss of context when calling `PinchItemMixin.init`.
Several changes to simplify CRUD, to avoid maintain unused feature and to be able to make a clean bulk insert (PR: https://github.com/odoo/odoo/pull/80961) ### [REM] base: remove _sequence attribute of BaseModel The `_sequence` was only used for the insertion of data in the DB for the `id` value. But in Odoo, the `id` is always a `SERIAL`, then the PostgreSQL fill already the value by the right SQL sequence. Then, avoid doing the job of the DB by ourselves. Sadly, we need to manage the case when we create an empty record to always get a valid query. ### [REM] base: remove column_format of Field class The `column_format` of the `Field` class was unused and create useless noise in the ORM. Then remove it and simplify some flows. ### [REF] base: simplify the _write Issue: `_write` checked that the number of modified row in DB was equal to the number of ids in the RecordSet (raise `MissingError` if not). This behavior was only used by the ORM to retry (with exists() on the RecordSet before) if the Missing Error raised. Then it makes the job a second time (for no reason). Then: - Remove the check of number of row (and simplify the call of `_write`) - Remove the useless return value (always `True`) - Remove the `set(` before the `split_for_in_conditions`, it adds randomness for nothing because the `_write` should be call without duplicate id (even if it is not the case, we don't care). ### [REM] base: remove deprecated field attribute It was only used one time on a unused field. We don't want to keep useless fields anymore, the migration is done for that. odoo/upgrade#3194 task-2735546
Odoo now uses its built-in conversion for creating plain-text versions of HTML content, including email messages when no plain-text alternative is provided. This reduces reliance on an external library and keeps email formatting behavior more consistent across the platform.
The mail activity completion popover has been tidied as part of a broader style optimization effort. This keeps the interface easier to maintain while preserving the same user experience.
Original PR description
Part of the overall v16 SCSS optimization/restyle, #2704984 task: #2731819 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the styling and markup used for attachment image previews in Odoo's mail features. It removes unused elements and adds shared opacity styling helpers, making the interface code easier to maintain with minimal visible impact for users.
Original PR description
Part of the overall v16 SCSS optimization/restyle, #2704984 task: #2731819 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
With [1] in 13.0, the blog post layouts were reviewed. At the same time, new demo data was introduced. By default, with demo data, you have now two different blogs. The JS tour was adapted so that when you create a new blog post, a step explains you have to select the blog you want to create the post in with the dialog that opens. The main problem that this PR aims to solve is that all users start without demo data and thus with only one blog... so with the current tour, the users are blocked very early in the tour as they do not have the dialog to select the blog in which to create their blog post. The simple solution that was chosen is to set the step as "auto", meaning it will only be used in runned tours (like via python tests), allowing to still test the blog selection dialog in our python test. Users will not be guided via a tip for this specific modal but this is not a problem as this is very straightforward to understand in the case the user explicitely created multiple blogs before creating blog posts. This commit also partially backports [2] which made that python test more robust by not relying on the demo data. That backport was improved with explanations and got rid of the step_delay that does not seem needed (and potentially ignores real bugs). However, allowing the tour to go further than the blog post creation for the user... revealed that the rest of the tour was still blocking the user: A) the very next step is to modify the blog post title. That step was simply not possible to consume. Indeed the tour system asks for a click event on the title... which is never detected because our old editor removes all click handlers on that specific top-level editable area. The cleanest way of fixing that is actually to not wait for a click but wait that the user actually types text. For this purpose a feature was introduced in 14.0 with [3]. Unfortunately, that commit was not well split. This commit backports only the relevant one-line change with the "consumeEvent" config. Unfortunately again... that 14.0 feature is currently buggy during test tours as choosing the "input" consumeEvent alongside the "text" run method... changes the behavior of that "text" run method when the affected element is a contenteditable element. That should be fixed but this will be done in a further update. Meanwhile, this commit chooses to use the consumeEvent 'mouseup' which circles around both issues. B) the next step after that simply induced an invisible tip, hidden by the editor panel that was introduced in that 13.0 version. That was fixed changing its position. [1]: https://github.com/odoo/odoo/commit/bb0cdec4594fab8c22265ed8af0c2d431a263b72 [2]: https://github.com/odoo/odoo/commit/f16f2e212a30352ead86c2f876be02b5c5e23b07 [3]: https://github.com/odoo/odoo/commit/a34cd7c662b3753d630d83793ffcb53b4a0a92d2 Bug revealed by testing task-2728994 Forward-Port-Of: odoo/odoo#83710 Forward-Port-Of: odoo/odoo#83698
Recently, a lot of the network infrastructure code was rewritten. A lot of this new code doesn't account for the possibility of being on an external website, and so network requests made with relative URLs would not make their request to the odoo server but to the server serving the external page which would fail. This commit fixes that by replacing the regular rpc service with one that will add the correct prefix, as well as patching the "browser.fetch" method to do the same. Additiona
Original PR description
Recently, a lot of the network infrastructure code was rewritten. A lot of this new code doesn't account for the possibility of being on an external website, and so network requests made with relative URLs would not make their request to the odoo server but to the server serving the external page which would fail. This commit fixes that by replacing the regular rpc service with one that will add the correct prefix, as well as patching the "browser.fetch" method to do the same. Additionally, the localization service is now less fault-tolerant, and won't silently fall back to a default configuration if it cannot get the translations from the server, as such, the tranlsations route is made available cross-origin, which has the added bonus of making translations available to the embeded code. opw-2677184 Forward-Port-Of: odoo/odoo#83461
With commit 7b165cd5, it was incorrectly assumed that PDT notifications sent by PayPal could not be verified with the suggested method (dedicated to PDT notifications) because they were missing some required parameters. The code was thus adapted to have their verification done with the method already in place for IPN notifications, as it seemed to do the job. It turns out that the PayPal sandbox account that was used at that time was not properly configured, and that PayPal was then sendi
Original PR description
With commit 7b165cd5, it was incorrectly assumed that PDT notifications sent by PayPal could not be verified with the suggested method (dedicated to PDT notifications) because they were missing some…
With commit 7b165cd5, it was incorrectly assumed that PDT notifications sent by PayPal could not be verified with the suggested method (dedicated to PDT notifications) because they were missing some required parameters. The code was thus adapted to have their verification done with the method already in place for IPN notifications, as it seemed to do the job. It turns out that the PayPal sandbox account that was used at that time was not properly configured, and that PayPal was then sending IPN-like notifications instead of actual PDT notifications, which is the reason why the swap of methods worked. Actually, once the account is properly configured, PayPal sends correctly populated PDT notifications that must be verified with the method dedicated to PDT notifications, as the one dedicated to IPN notifications stops working in that case. With this commit, the method used to verify the origin and integrity of PDT notifications is replaced by the one that was previously removed. The method is however implemented in a more defensive manner to: 1. accept and process the notification without verification if the account is not properly configured on PayPal. 2. silently discard the notification if the acquirer is not properly configured on Odoo. We then rely on the IPN (webhook) to confirm the transaction. task-2744043 See also: - https://github.com/odoo/documentation/pull/1480 Forward-Port-Of: odoo/odoo#83615 Forward-Port-Of: odoo/odoo#83140
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#82856
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#82856
Step to reproduce: - Go to a project with visibility set on 'Invited portal users and all internal users' - Go a task - Send an follow invitation to Marc Demo (an internal user) Intended behavior: The mail has a 'View task button' Current behavior: No view task button This behaviour is due to the function _get_recipient_data which is supposed to return groups when given pids but doesn't. See _get_recipient_data docstring. opw-2727410 -- I confirm I have signed the CLA a
Original PR description
Step to reproduce: - Go to a project with visibility set on 'Invited portal users and all internal users' - Go a task - Send an follow invitation to Marc Demo (an internal user) Intended behavior: The mail has a 'View task button' Current behavior: No view task button This behaviour is due to the function _get_recipient_data which is supposed to return groups when given pids but doesn't. See _get_recipient_data docstring. opw-2727410 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83460 Forward-Port-Of: odoo/odoo#82601
Remove the duplicated translation for "Cancel" in the .po file introduced in https://github.com/odoo/odoo/commit/51e969c6e04d7a8d699e355dda951b44c53da9dd It caused an error when installing the FR language for the l10n_fr_fec module. Forward-Port-Of: odoo/odoo#83643
Original PR description
Remove the duplicated translation for "Cancel" in the .po file introduced in https://github.com/odoo/odoo/commit/51e969c6e04d7a8d699e355dda951b44c53da9dd It caused an error when installing the FR language for the l10n_fr_fec module. Forward-Port-Of: odoo/odoo#83643
### Expected Behaviour When a user get a mail from the data cleaning about records to examine, the View button should be linked to the same url as the 'here' hyperlink or not be in the e-mail. ### Observed behaviour Clicking the link in the View button lead to an error page Reproducibility This bug can be reproduced following these steps: 1. Duplicate a contact 2. Wait for the scheduled task to launch 3. Click on the View button of the mail you'll get about te duplicate ### Proble
Original PR description
### Expected Behaviour When a user get a mail from the data cleaning about records to examine, the View button should be linked to the same url as the 'here' hyperlink or not be in the e-mail. ### Observed behaviour Clicking the link in the View button lead to an error page Reproducibility This bug can be reproduced following these steps: 1. Duplicate a contact 2. Wait for the scheduled task to launch 3. Click on the View button of the mail you'll get about te duplicate ### Problem Root Cause This issue is coming from the way we create the 'View' and 'View Task' button, and can't be changed easily. The easier way to fix this issue is then to hide these button ### Related Issues/PR - opw-2674138 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83244 Forward-Port-Of: odoo/odoo#80987
In case of a MRP subcontracting, it is not possible to process the delivery with several backorders. To reproduce the issue: 1. Create two products P_compo, P_finished - Both storable - P_compo must have the route "Resupply Subcontractor on Order" 2. Update P_compo's quantity: 5 3. Create a BoM: - Product: P_finished - BoM type: Subcontracting - Subcontractors: a partner P - Components: 1 x P_compo 4. In Inventory, create a planned transfer T: - Operati
Original PR description
In case of a MRP subcontracting, it is not possible to process the delivery with several backorders. To reproduce the issue: 1. Create two products P_compo, P_finished - Both storable - P_compo must…
In case of a MRP subcontracting, it is not possible to process the
delivery with several backorders.
To reproduce the issue:
1. Create two products P_compo, P_finished
- Both storable
- P_compo must have the route "Resupply Subcontractor on Order"
2. Update P_compo's quantity: 5
3. Create a BoM:
- Product: P_finished
- BoM type: Subcontracting
- Subcontractors: a partner P
- Components: 1 x P_compo
4. In Inventory, create a planned transfer T:
- Operation Type: Receipt
- Receive From: P
- Operations: 5 x P_finished
5. Mark as Todo
6. Inventory > Resupply Subcontractor, find the delivery of P_compo for
P and process it
7. Back to T, set the done quantity to 1.25
8. Validate T (with backorder)
9. On the backorder BO1, set the done quantity to 1.0
10. Validate BO1 (with backorder)
11. Open the second backorder BO2 and validate it
Error: a Validation Error is displayed "You can not enter negative
quantities.", which doesn't make sense
The issue comes from the inner method `_get_available_move_lines` in
`_action_assign`. When validating a picking, at some point, we are here,
at the beginning of `/mrp_subcontracting._action_done`:
https://github.com/odoo/odoo/blob/6d6b2c41adfa842c82252373b3dbd1ed0a5ebc92/addons/mrp_subcontracting/models/stock_picking.py#L36-L37
To understand what happens next, we need to note that, in this method,
the associated MO will be marked as done later (on line 76). Back to the
current line (L37), we are calling `super` which leads to the
problematic `_get_available_move_lines`. Suppose we are on step 10 (we
are validating the first backorder), we have
https://github.com/odoo/odoo/blob/58a9f57c0827a51e46ef0f52a3d48ba343667fe0/addons/stock/models/stock_move.py#L1390-L1391
`move_orig_ids` contains two stock moves, each one associated to one MO.
However, as said above, the second MO is not yet marked as done, this
will be done later on in `/mrp_subcontracting._action_done`. Therefore,
`move_lines_in` is only defined with the first SM, from the first MO,
with a quantity of `1.25`
Further in `_get_available_move_lines`, we have:
https://github.com/odoo/odoo/blob/58a9f57c0827a51e46ef0f52a3d48ba343667fe0/addons/stock/models/stock_move.py#L1403-L1405
`move.move_orig_ids.mapped('move_dest_ids') - move` gives two SM, and
here is the issue: the second one is already processed, so both are kept
in `move_lines_out_done` and the sum of their quantity is equal to
`1.25 + 1 = 2.25`
Therefore, at the end of the method, when computing the difference, it
gives a negative difference. This negative value will be used to create
a SML and later on, it will trigger the validation error.
Once the above issue is fixed, there is another "invisible" issue that
need to be fixed: when generating several backorders on the deliveries,
only the first one will trigger the creation of a new MO. Suppose we are
back in `/mrp_subcontracting._action_done` (still on step 10 in the
above case), in the first for-loop:
https://github.com/odoo/odoo/blob/6d6b2c41adfa842c82252373b3dbd1ed0a5ebc92/addons/mrp_subcontracting/models/stock_picking.py#L39-L43
`move._get_subcontract_production()` returns the two MO (from the
initial picking and from the first backorder). However, since the first
one has already been processed, the if-condition is validated.
Therefore, this for-loop is done and the second MO is not processed (the
quantities are not recorded and its field
`subcontracting_has_been_recorded` is not defined to `True`). As a
result, still in `/mrp_subcontracting._action_done`, we are now in the
second for-loop:
https://github.com/odoo/odoo/blob/6d6b2c41adfa842c82252373b3dbd1ed0a5ebc92/addons/mrp_subcontracting/models/stock_picking.py#L71-L72
`_subcontracting_filter_to_done` removes the two MOs because the first
one is done and the second one has not its field
`subcontracting_has_been_recorded` set to `True`. The condition in the
first for-loop is not accurate enough.
OPW-2731658
Forward-Port-Of: odoo/odoo#83602
Forward-Port-Of: odoo/odoo#83333When creating automatic entries for multiple moves on different dates with the automatic entry wizard, the wizard would reconcile all the lines on the accrual account of the destination move with the lines on the accrual account of each accrual move. As this would imply reconciling the same lines multiple times, it triggers a reconciliation error. What must be done is, for each accrual move, reconcile it’s lines with only the related lines on the destination move. Task: 2717578 Forward-Port
Original PR description
When creating automatic entries for multiple moves on different dates with the automatic entry wizard, the wizard would reconcile all the lines on the accrual account of the destination move with the lines on the accrual account of each accrual move. As this would imply reconciling the same lines multiple times, it triggers a reconciliation error. What must be done is, for each accrual move, reconcile it’s lines with only the related lines on the destination move. Task: 2717578 Forward-Port-Of: odoo/odoo#83400 Forward-Port-Of: odoo/odoo#81812
When archiving a Tax, you do not want that action to invalidate Sales Orders and Invoices confirmed in the past and that were using it. The purpose of Archiving it is that it would not appear or be proposed to new items created. Until now, we had an inconsistency between Sales Orders and Invoices when a Tax was archived. The tax "disappeared" from old SOs, but the amounts remained unchanged, which created an inconsistency. The domain in the field definition no longer works becaus
Original PR description
When archiving a Tax, you do not want that action to invalidate Sales Orders and Invoices confirmed in the past and that were using it. The purpose of Archiving it is that it would not appear or be proposed to new items created. Until now, we had an inconsistency between Sales Orders and Invoices when a Tax was archived. The tax "disappeared" from old SOs, but the amounts remained unchanged, which created an inconsistency. The domain in the field definition no longer works because a custom domain in the view is shadowing the current domain. task-2745094 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83538 Forward-Port-Of: odoo/odoo#83518
The goal is to add a test that covers the basic use cases of fiscal positions, and in particular when using a delivery address. The use cases are as follows: - Case : 1 Billing (VAT/country) : BE/BE Delivery (VAT/country) : NL/NL Expected FP : Régime National - Case : 2 Billing (VAT/country) : NL/NL Delivery (VAT/country) : BE/BE Expected FP : Régime National - Case : 3 Billing (VAT/country) : BE/BE Delivery (VAT/country) : None/NL Expected FP : Régime National - Case :
Original PR description
The goal is to add a test that covers the basic use cases of fiscal positions, and in particular when using a delivery address. The use cases are as follows: - Case : 1 Billing (VAT/country) : BE/BE…
The goal is to add a test that covers the basic use cases of fiscal positions, and in particular when using a delivery address. The use cases are as follows: - Case : 1 Billing (VAT/country) : BE/BE Delivery (VAT/country) : NL/NL Expected FP : Régime National - Case : 2 Billing (VAT/country) : NL/NL Delivery (VAT/country) : BE/BE Expected FP : Régime National - Case : 3 Billing (VAT/country) : BE/BE Delivery (VAT/country) : None/NL Expected FP : Régime National - Case : 4 Billing (VAT/country) : NL/NL Delivery (VAT/country) : NL/NL Expected FP : Régime Intra-Communautaire - Case : 5 Billing (VAT/country) : None/NL Delivery (VAT/country) : None/NL Expected FP : EU privé - Case : 6 Billing (VAT/country) : None/US Delivery (VAT/country) : None/US Expected FP : Régime Extra-Communautaire Related PR : https://github.com/odoo/odoo/pull/75033 task-2729813 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83618 Forward-Port-Of: odoo/odoo#82280
Current behavior: After creating a group chat in the discuss app you were not able to close it. Steps to reproduce: -Create a group chat with more than one user in the discuss app - Try to leave it - You get an access error opw-2736464 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83603
Original PR description
Current behavior: After creating a group chat in the discuss app you were not able to close it. Steps to reproduce: -Create a group chat with more than one user in the discuss app - Try to leave it - You get an access error opw-2736464 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83603
Steps to follow - Select only one company in the company selector but not the default one from the current user - Go the the CRM app - Create a lead -> A multi company error appears Solution When computing the company_id and team_id, keep only the ones within the allowed_company_ids opw-2713757 Forward-Port-Of: odoo/odoo#83056
Original PR description
Steps to follow - Select only one company in the company selector but not the default one from the current user - Go the the CRM app - Create a lead -> A multi company error appears Solution When computing the company_id and team_id, keep only the ones within the allowed_company_ids opw-2713757 Forward-Port-Of: odoo/odoo#83056
PURPOSE Before this commit it's impossible to unlink a sale order line containing a booth product (the ondelete parameter is unset thus default to restrict) After this commit this bug is fixed. Further explanation on the task implying a bug on the database setting the on delete to cascade despite the default value... LINKS Task-2749521 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83685
Original PR description
PURPOSE Before this commit it's impossible to unlink a sale order line containing a booth product (the ondelete parameter is unset thus default to restrict) After this commit this bug is fixed. Further explanation on the task implying a bug on the database setting the on delete to cascade despite the default value... LINKS Task-2749521 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83685
Steps to reproduce: - Create an invoice and confirm it - In Accounting Dashboard, on the Customer Invoices card, click on 'Unpaid Invoices' - Select the invoice with the checkbox - Click on button 'Register Payment' Issue: - The journal_id is not set by default Before this commit, when opening the payment register wizard, we inherited the customer invoices journal from the context. opw-2729754 Description of the issue/feature this PR addresses: Current behavior before
Original PR description
Steps to reproduce: - Create an invoice and confirm it - In Accounting Dashboard, on the Customer Invoices card, click on 'Unpaid Invoices' - Select the invoice with the checkbox - Click on button 'Register Payment' Issue: - The journal_id is not set by default Before this commit, when opening the payment register wizard, we inherited the customer invoices journal from the context. opw-2729754 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#83273
Before this commit, it was impossible to make a payment if the transaction reference exclusively contained digits. This is because the reference is extracted from the data-* attribute of the <form/> element of the payment form and wrongly cast into an integer by jQuery before being passed to the server. Indeed, as of jQuery 1.4.3, HTML5's data-* attributes are automatically pulled into a jQuery's data object. To reproduce the issue, remove the prefix from the sequence of the sales
Original PR description
Before this commit, it was impossible to make a payment if the transaction reference exclusively contained digits. This is because the reference is extracted from the data-* attribute of the <form/> element of the payment form and wrongly cast into an integer by jQuery before being passed to the server. Indeed, as of jQuery 1.4.3, HTML5's data-* attributes are automatically pulled into a jQuery's data object. To reproduce the issue, remove the prefix from the sequence of the sales orders and attempt to pay a quotation from a payment link. This commit forces the reference to be cast into a string as it is the variable type that the server expects, and it crashes if the reference is an integer. opw-2732448 Forward-Port-Of: odoo/odoo#82729
In version 14, if you create a PoS order without invoicing it, then leave the session without closing and validating, and open said order and invoice it outside the session, picking order will not be created. After this commit Odoo will check if order that is being invoiced already has picking order, and if not, will create one for it. OPW-2725930 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83463
Original PR description
In version 14, if you create a PoS order without invoicing it, then leave the session without closing and validating, and open said order and invoice it outside the session, picking order will not be created. After this commit Odoo will check if order that is being invoiced already has picking order, and if not, will create one for it. OPW-2725930 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83463
Forward-Port-Of: odoo/odoo#83664
Original PR description
Forward-Port-Of: odoo/odoo#83664
Forward-Port-Of: odoo/enterprise#23885
Original PR description
Forward-Port-Of: odoo/enterprise#23885
The tours were not working anymore since odoo/odoo#58287. The class `.o_menu_entry_lvl_*` being removed. TaskID: 2687999 Forward-Port-Of: odoo/enterprise#23881
Original PR description
The tours were not working anymore since odoo/odoo#58287. The class `.o_menu_entry_lvl_*` being removed. TaskID: 2687999 Forward-Port-Of: odoo/enterprise#23881
Forward-Port-Of: odoo/enterprise#23850
Original PR description
Forward-Port-Of: odoo/enterprise#23850
Step to reproduce: - Install "website" module - Switch to Hebrew language - Try to open Website module Issue: Traceback is raised. Cause: Trying to tokenize a string who have one or multiple `"` character in the middle; at each iteration of the tokenizer, it will try to match the current character with the first character to know if it's the end of the string. In this case, it will stop before the end of the string and therefore trigger an error since expr
Original PR description
Step to reproduce: - Install "website" module - Switch to Hebrew language - Try to open Website module Issue: Traceback is raised. Cause: Trying to tokenize a string who have one or multiple `"` character in the middle; at each iteration of the tokenizer, it will try to match the current character with the first character to know if it's the end of the string. In this case, it will stop before the end of the string and therefore trigger an error since expr not fully parsed. Solution: Replace first and last character ' " ' by ' \` ' . Note: Still can have an issue but it's less likely to have a string surrounded by ' \` '. opw-2687503 Forward-Port-Of: odoo/enterprise#23116
A bad forward port of ab823320e2175e7cfd02c00aa3ea98b64a55acf1 in 15.1 made the report unbalanced (2e04425220b3e079146c285eeabd7a2cce995cc6). (One of the line got lost during a conflict resolving) This will add the line back. Forward-Port-Of: odoo/enterprise#23872
Original PR description
A bad forward port of ab823320e2175e7cfd02c00aa3ea98b64a55acf1 in 15.1 made the report unbalanced (2e04425220b3e079146c285eeabd7a2cce995cc6). (One of the line got lost during a conflict resolving) This will add the line back. Forward-Port-Of: odoo/enterprise#23872
General Ledger report contains the account '999999 Undistributed Profits/Losses' when filtering on an account Steps to reproduce: 1. Install Accounting 2. Go to Accounting -> Reporting -> Audit Reports -> General Ledger 3. In 'Search account' on the top right, filter on account 600000 4. Print the pdf or the xlsx 5. The account '999999 Undistributed Profits/Losses' is included in the report generated Solution: Add the account filter to the domain of the candidate accounts OPW-2733
Original PR description
General Ledger report contains the account '999999 Undistributed Profits/Losses' when filtering on an account Steps to reproduce: 1. Install Accounting 2. Go to Accounting -> Reporting -> Audit Reports -> General Ledger 3. In 'Search account' on the top right, filter on account 600000 4. Print the pdf or the xlsx 5. The account '999999 Undistributed Profits/Losses' is included in the report generated Solution: Add the account filter to the domain of the candidate accounts OPW-2733281 Forward-Port-Of: odoo/enterprise#23802 Forward-Port-Of: odoo/enterprise#23703