Tuesday, February 1, 2022
33 changes · master
Enhancements to existing features
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
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…
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 .
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