[16.0] [REF] lxml 5.2 compatibility #93
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Just to see how it behaves currently, as we are going to fix some unwanted
changes. Notably
* setting user_id to the same value as before should not update the
date_open value;
* setting stage_id to the same value as before should not update the
last stage update value;
* triggers generate chain update of those fields (changing team_id
changes user_id that changes date_open, ...);
Task-3515225
Part-of: odoo#144848
Before this commit:
* when a user changes 'user_id' to set the same previous 'user_id', the
assign date 'date_open' is updated but it should not as the responsible
did not change;
* when a user changes the salesperson 'user_id' of a crm lead, it triggers
a recompute of 'team_id' that triggers a recompute of 'stage_id' that
updates 'date_last_stage_update' even if the stage does not change, which
happens frequently when changing leads within a given team (new assign,
salesperson on holidays, ...)
* when merging opportunities, 'user_id' can be set on the main opportunity
which triggers a recomputation of both 'date_last_stage_update' and
'date_open' as explained in above points;
Reason:
The 'date_last_stage_update' field depends on 'stage_id' which depends on
'team_id' which depends on 'user_id'. As a result, when 'user_id' changes,
'date_last_stage_update' also updates.
Moreover those fields are implemented using editable stored computed fields
which are triggered everytime a value is given to those fields, even when
the same value is given.
After this commit:
'date_last_stage_update' and 'date_open' will only update when there are
real changes.
Task-3515225
Part-of: odoo#144848
'date_open' is the date when a user is assigned to a lead / opportunity. It should not be set when converting a lead to an opportunity, as those two flows are different. Only setting a responsible should update it. Task-3515225 Part-of: odoo#144848
date_open should not be set when there is no user_id set. Let us be coherent so that we can see the effect of assigning users that updates the date_open field. Task-3515225 Part-of: odoo#144848
Before this commit:
* when a user changes 'user_id' to set the same previous 'user_id', the
assign date 'date_open' is updated but it should not as the responsible
did not change;
* when a user changes the salesperson 'user_id' of a crm lead, it triggers
a recompute of 'team_id' that triggers a recompute of 'stage_id' that
updates 'date_last_stage_update' even if the stage does not change, which
happens frequently when changing leads within a given team (new assign,
salesperson on holidays, ...)
* when merging opportunities, 'user_id' can be set on the main opportunity
which triggers a recomputation of both 'date_last_stage_update' and
'date_open' as explained in above points;
Reason:
The 'date_last_stage_update' field depends on 'stage_id' which depends on
'team_id' which depends on 'user_id'. As a result, when 'user_id' changes,
'date_last_stage_update' also updates.
Moreover those fields are implemented using editable stored computed fields
which are triggered everytime a value is given to those fields, even when
the same value is given.
After this commit:
'date_last_stage_update' and 'date_open' will only update when there are
real changes.
Also fix 'date_open' update when lead is converted into an opportunity.
'date_open' is the date when a user is assigned to a lead / opportunity. It
should not be set when converting a lead to an opportunity, as those two
flows are different. Only setting a responsible should update it.
Task-3515225
closes odoo#144848
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps ----- 1. Have Resellers module installed 2. Connect with a portal user who doesn't have any opportunities but should be able to create one. 3. On the portal page, the user cannot create an opportunity as the opportunities tab is the only way to access the "Create opportunity" button and this tab is not displayed if there are no existing opportunities. Fix --- We always display the opportunities tab on the portal for users who can create opportunities. Note: the fix for 17.0 is different as portal_docs_entry was modified. opw-3809571 closes odoo#159670 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Backporting: 1e24b15 When importing a UBL file, Odoo expects the UBL specific namespaces to be in the root element of the file. This is not always the case as these namespaces could exist in every element in the file. When a file is formatted this way, Odoo cannot extract the necessary data from it because it is missing the necessary namespaces. To cover this case we use the lxml.etree.Element.find function instead, and pass in the UBL specific namespaces to successfully extract the data. task-3657563 opw-3839398 closes odoo#161653 X-original-commit: ac607fe Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com> Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
If the "generic" routes (i.e., the ones created from the master data)
are company-specific, the user won't be able to create a new company
anymore.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Enable all companies
3. Inventory > Configuration > Rules:
- For each Manufacture rule:
- If its route does not have any company:
- Set the route's company equal to the one of the rule
4. Create a new company
Error: a Validation Error is raised: "Rule [...] (Production) belongs
to \<new company\> while the route belongs to \<an existing company\>."
Creating a company leads to the creation of the WH and its rules. At
some point, we create/update the global rules. Let's look at the
Manufacture one. We will provide all the required values for its
creation:
https://github.com/odoo/odoo/blob/270d8aa06bb37b4a01f01a7274062e3f88ca2a1c/addons/mrp/models/stock_warehouse.py#L112-L128
As you can see, for the `route_id` field, we try to find a global
route. But here is the issue: in this `_find_global_route`, we will
find the "generic" one thanks to the provided XML_ID. But, step 3,
we set a company on that route. As a result, here, we try to create
a rule for a company X linked to a route that belongs to a company Y,
hence the validation error:
https://github.com/odoo/odoo/blob/dc58d7913131f1f4dbeb0e3337e61e0b21f6f0d9/addons/stock/models/stock_rule.py#L107-L108
OPW-3790512
closes odoo#161820
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
…plates. Strings within inline templates are not translatable, so we convert these templates into standard templates so that they can be. Task-3761551 closes odoo#160238 Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
This commit fixes a bug where the value of an autocomplete with autoselect could go into an undefined state where the model value doesn't match the input value but no change is detected. This would happen on escape press, scroll and more recently due to odoo#159333 on click out. To fix this issue, the commit introduces some change in the autocomplete behavior so that it will no longer select the active option on click out (blur) when autoselect is active and instead it will revert the input value to the one stored into the model. Also applies this behavior on escape key press and scroll for the before mentioned reasons. Steps to reproduce: - Go to CRM form view - Edit the salesperson name to some non existant one and click out (or scroll or press escape) Before the fix, the name was stuck to the invalid one but no change was detected so we couldnt save it. Before odoo#159333, click out would select the active option of the dropdown instead (and launch a dialog for quick create). This is removed because the behavior is neither intuitive nor practical. After the fix, the name is reset to its previous valid value instead. This applies to all autocomplete components with autoselect prop set to true. closes odoo#161251 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce: - Create 2 lines with the same balance but only one has an analytic_distribution (of 100% on an analytic account). - Create a transfer of accounts for these => The counterpart has a distribution of 100% or no distribution. Indeed, we simply put the distribution of the last line. It makes no sense: analytic "balance" is generated and does not reflect the transfer move. We should make a prorata of the distributions of the lines to transfer. closes odoo#160965 Signed-off-by: Laurent Smet (las) <las@odoo.com>
While in practice you would never get this inverse called with more than one record at a time, it is still wrong to get the company of self in the loop. Fixing it to keep good conscience :) closes odoo#161815 Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Steps to reproduce:
1. Go to IoT > Devices
2. Select a device and add the report "Lot/Serial Number (ZPL)"
3. Create a product tracked by lots
4. Purchase 5 units of this product
5. Validate the reception (with a lot)
6. Print labels > Lot/SN Labels
- Quantity to print: One per unit
- Format: ZPL Labels
Before this commit:
When printing labels for multiple lots of the same product, the wizard
was incorrectly generating the docids as a `list[list[int]]`. It works
correctly as the ids are joined thanks to JavaScript magic. However,
when sending the report to an IoT device, the ids are sent as-is in
the context, which raises and error when calling `browse()`.
After this commit:
The docids are now generated as a flat list of integers, which is
correct and works as expected.
opw-3850631
closes odoo#161932
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
According to https://www.easytax.co/en/countries/greece the vat number format for Greece is EL123456783 instead of GR12345670. We also delete the line for country code `el` from `_ref_vat` dict as we use `gr` for Greece. opw-3845662 closes odoo#161895 X-original-commit: b97c74e Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com> Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
As of April 1, 2024, the EAS code for Finland should be 0216. Other address types are not allowed for Finnish end users. See also: [Finland Peppol Authority requirements](https://peppol.org/wp-content/uploads/2023/08/Finland-Peppol-Authority-Specific-Requirements.pdf) [Finland Peppol Authority website](https://www.valtiokonttori.fi/en/service/the-state-treasury-is-the-finnish-peppol-authority/#for-service-providers_authority-specific-requirements-in-finland) no task, reported by the Finnish Peppol Authoirty Team closes odoo#161953 X-original-commit: e732bc2 Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com> Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
…endances closes odoo#159422 See: odoo#158439 Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the issue:
- Create a storable product “P1”:
- Route: dropship
- Vendor: Azure interior and deco addict
- Create a sales order with one unit of P1
- Confirm the sales order
- A purchase order is generated with a dropship-picking
(linked to the SO)
- Create an alternative PO and confirm it
Problem:
The alternative PO is linked to the SO, but the dropship-picking is not
linked. This is because the procurement is not propagated when creating
the alternative PO.
opw-3828132
closes odoo#160354
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
No rounding in the query used to map sale.order.line to the hr.expense, models leads to some records not being able to be linked together, because of floating point errors. Adding a rounding to the key price_unit, and not filtering on price_unit. Then, using the rounded string versions of the price_unit in the comparisons adds a more reliable approach. task-3705179 closes odoo#154002 Signed-off-by: William André (wan) <wan@odoo.com>
With a SA company setup Open a journal entry Hit 'Reverse Entry' > Reverse Error: "For Credit/Debit notes issued in Saudi Arabia, you need to specify a Reason" This occurs because with SA localization we need to provide a reason for move reversal but by default the reason field is invisible for journal entries Backport of odoo@d660fd5 opw-3789732 closes odoo#161936 X-original-commit: 527db37 Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com> Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Problem --------- Because of this PR: 155896, the customer default value for the UBL export values has been modified from commercial partner to partner. However, in 16.0, some constraints have been added to verify that some fields were properly set up before generating the XML. Those restrictions clash with the said changes. Indeed: 1 - Create NO company 2 - Set up UBL on invoice journal 3 - Create a new NO customer and set up UBL in the same way 4 - Create an invoicing address for that customer 5 - Create an invoice for with the customer set as the invoice address set up in step 3. 6 - Send & Print with UBL selected >> An error is added to the export errors while it should not. Solution --------- Use the commercial partner when checking constrains of all fields other than addresses. OPW-3848367 closes odoo#160523 Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Steps to reproduce the issue: 1. Create a Storable Product and give it a UOM 2. Create an On Hand stock in a certain location 3. Go to Barcode and create a new Internal Transfer 4. Add the Product and with any quantity and click on Confirm (not Validate) 5. Edit the line of the Product (pencil icon), change the quantity and the UOM and click on Confirm 6. Validate the Transfer 7. Go back to the Product and click on the "On Hand" or the "Update Quantity" button 8. The reserved quantity is not null Explanation: When you change `stock.move.line.product_uom_id`, `stock.quant.reserved_quantity` (using `product.product.uom_id`) is not changed to reflect the new `uom.uom.factor`. You then have two routes: - In `stock_barcode`, `stock.move.line.product_uom_id` changes first, `stock.move.line.quantity` change is triggered through `stock.move.line._inverse_qty_done` afterwards. https://github.com/odoo/enterprise/blob/d04b69ba03877a9b4aae82fb061dca23b1bfc4bc/stock_barcode/models/stock_move_line.py#L58-L61 When calling `stock.move.line._synchronize_quant`, `stock.move.line.quantity_product_uom` will use the new `stock.move.line.product_uom_id` while `stock.quant.reserved_quantity` still reflects the old `uom.uom.factor`. https://github.com/odoo/odoo/blob/1b0dbb3645ad8b52c5260f1cbbc4f6bdee48461e/addons/stock/models/stock_move_line.py#L421-L422 (e.g.: going from `1 Dozens` to `2 Units` would give you `1.09 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`) - There is a similar issue in _Inventory > Transfers > Internal_, where `stock.move.line.product_uom_id` changes at the same time instead. In that case, the whole operation will be done using the previous `stock.move.line.product_uom_id`, and changing `stock.move.line.product_uom_id` before changing `stock.move.line.quantity` would cause the same issue as in `stock_barcode`. (e.g.: going from `1 Dozens` to `2 Units` would give you `2 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`) Suggested fix: There is a first check to make sure one of the values has changed, then each one will be assigned through a condition: - The first one will be `product_uom_id`, with which `uom.uom._compute_quantity` will be called. - The second condition will be `quantity`, which will be set in a `vals.get` in the `qty` parameter of the compute. opw-3798046 closes odoo#161973 X-original-commit: 7e4d5c0 Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com> Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
Browse files Steps to reproduce: - Install Accounting, l10n_it_edi and Contacts - Switch to an Italian company (e.g. IT Company) - Go to Contacts and create a contact from San Marino: * Name: SM customer * Country: San Marino * Street, City, ZIP: [any] * Destination Code: [any] - Create an invoice: * Customer: [the created contact from San Marino] * Product: [any] - Confirm the invoice - Check the generated electronic invoice Issue: In the XML, the destination code (i.e. CodiceDestinatario) is the default one for non-Italian customer (i.e. XXXXXXX). Also, the VAT number (i.e. IdFiscaleIVA) is the default value for countries that are not in the European Union (i.e. OO99999999999). However, since October 2021, San Marino should be handled differently for Italian electronic invoices. A specific destination code (i.e. 2R4GTO8) should be used for all customers from San Marino. Source: https://www.credemtel.it/fattura-elettronica/fattura-elettronica-san-marino/ Solution: For customers from San Marino: - Keep VAT number - Set "2R4GTO8" as destination code This is a backport of odoo@15cb8f5 opw-3819054 closes odoo#162073 X-original-commit: 302a7f6 Signed-off-by: Quentin De Paoli <qdp@odoo.com> Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Before this commit: If an error was sent back from stripe, it will not display in the dialog box. Only the title of it but an empty content. This happened as the message in my case was inside the error. Also took the occasion to add a log in the backend Example to reproduce: use a $ database when the stripe is set in euro. It will trigger an error: The card_present source type with currency usd is not supported in ... After this commit: Fallback on the message if the previous value is falsy opw-3853953 closes odoo#161310 Signed-off-by: Loan Sens (lse) <lse@odoo.com>
…achments Issue ----- Report creation for multiple invoices fails (e.g. with <AttributeError: "NoneType" object has no attribute "getvalue">) when some, but not all, of the invoices across the selection have a previously generated report as an attachment, and the 'Reload from attachment' option is enabled for the report action. Steps ----- - Enable 'Reload from attachment' from Settings -> Techical -> Actions -> Reports -> invoices. - Create 3 invoices without any previous reports as attachments. - Select the middle invoice and generate a report (Print -> Invoices). An attachment will be created for the invoice. - Select the 3 invoices then generate a report (Print -> Invoices). Cause ----- When "Reload from attachment" is enabled, the algorithm for creating aggregate reports for a number of invoices selects only those that don't have an attachment to generate a pdf for. These are copied into a separate list "res_ids_wo_stream". When the pdfs streams are generated, they're put back into the return value "collected_streams. However, this was done from the original ids list "res_ids" rather than the selected one, which resulted in an indexing issue. opw-3827700 Closes odoo#157975 closes odoo#160670 Signed-off-by: William André (wan) <wan@odoo.com>
The `test_accepting_recurrent_event_*` tests make sure that accepting recurrent events on google side reflect in odoo. The test was failing because of the following: when retrieving the invited attendee, the test used `self.assertEqual(event.attendee_ids[1].state, expected_states[i])` assuming that organizer will be at index `0` and invited user at index `1`. However the list of `event.attendee_ids` is ordered by create_date. And we create both organizer and attendee with the same command at the same time: `partner_ids=[Command.set([self.organizer_user.partner_id.id, self.attendee_user.partner_id.id])]` So we might have organizer at index `1` and invited attendee at index `0`. This resulted in the indeterministic behavior of the test. To fix this issue: This commit changes how the invited attendee is retrieved, making sure that we always get the right attendee. fixes runbot-61527 closes odoo#161451 Signed-off-by: Ahmad Almaghraby (alah) <alah@odoo.com>
Steps to reproduce:
- Install POS app.
- Go to POS > Products > Discount & Loyalty
- Create a New program with:
- Program Type: Loyalty Cards
- Conditional rules:
- Minimum Quantity: 2
- Grant: 1 Loyalty Points per unit paid
- Rewards:
- Reward Type: Discount
- Discount: 100 % one Cheapest Product
- In exchange of 2 Loyalty Points
- Start a new POS session
- Select a Customer
- Add two different products.
- Notice the Loyalty Points of +2 shown. This is Correct
- Click on the Reward button
- Notice how the Loyalty Points are now +3 which is obviously wrong given we only have two products. Basically it's as if the reward line (100% discount) is taken into consideration as the cheapest product.
Investigation:
- Inside `_updatePrograms`, `pointsForPrograms()` are calculated.
- we sum the lines quantities regardless of whether it's a reward line or not https://github.com/odoo/odoo/blob/e5c3ba58964f47cfd41d337e39e1bf25eaa25379/addons/pos_loyalty/static/src/js/Loyalty.js#L906
- By doing so, the reward lines are taken into consideration and the rule is triggerd by skipping this if clause https://github.com/odoo/odoo/blob/e5c3ba58964f47cfd41d337e39e1bf25eaa25379/addons/pos_loyalty/static/src/js/Loyalty.js#L917-L921
opw-3855323
closes odoo#161503
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Current behavior:**
Adding an attachment to a mail template record associated with
the survey invite wizard will not cause the attachment to
populate the relevant field when actually sending a new survey
invite email.
**Expected behavior:**
The attachments linked in the email template which is used by
the survey invite wizard will appear in the form when sending a
survey invite.
**Steps to reproduce:**
1. In settings, go to the email templates management page
2. Select the Survey: Invite template and upload some
attachment
3. Go to the Survey application and click on one of the surveys
listed, observe the lack of attachments despite having the
email template with the attachment selected
**Cause of the issue:**
The survey invite wizard never uses its template's attachments
to modify/update its own attachment_ids field.
**Fix:**
Make the attachment_ids field a stored computed field.
opw-3709830
closes odoo#152728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue: Discounts are not displayed in DDT Steps to reproduce: - create a quotation with a sale line having a discount - smart button delivery > set qty > validate - Print opw-3745866 closes odoo#159325 Signed-off-by: Josse Colpaert <jco@odoo.com>
Currently, when you refund an order that was paid with bank, thus not rounded, the refund is rounded wich result in a difference between the original order and the refund. This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund. Steps to reproduce: ------------------- * Setup a rounding method with a precision of 5.0 * Create a product with a price of 138.0 * Open the POS and add the product to the order * Pay the order with 2 payments, one bank of 55 and one cash that will be rounded to 80. * Validate the order * Go in the backend and refund the order * The refund will be rounded to 135.0 Why the fix: ------------ The new behavior after this fix: * When refunding the entire original order, the amount to refund should be equal to what the customer paid on the original order (thus taking into account the rounding). * When doing a partial refund, the amount that should be refunded correspond to the base price of the article(s) selected. The issue was about the fact that refunds differed in prices compared to the original order. With this fix, there could still be a difference in the prices if a customer comes multiple times to do a partial refund and end up refunding the total order. This difference exists only if the original order was paid with rounding and will be maximum the rounding defined. Since this is a rare event, we consider this difference to be acceptable. Post-fixup: ----------- The function `_get_rounded_amount()` was modified as we are not computing cash rounding when refunding anymore. opw-3701574 closes odoo#161564 Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com> Co-authored-by: Robin Engels <roen@odoo.com>
Previously, when the odoo server was running on some Windows installations, it was possible for javascript files loaded directly from the static folder of an addon to fail to run because the Content-Type header was set to text/plain instead of text/javascript. This is because the mimetypes module from the standard library honors the mimetypes from the OS, in the case of Windows it reads a key in the registry, which can be misconfigured to text/plain for .js files. This commit forces the mimetype of .js files to text/javascript to solve this issue. closes odoo#162277 X-original-commit: 9474c99 Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
"Cannot unreserve more than you have in stock" Error. Prior to this fix, one could edit and change the uom on the stock move line after reservations were done for an MO. Therefore you could theoretically reserve 10 grams on the MO, go to the stock move line in mobile version and change the UOM to kg - reserving 10kg. This creates a missmatch in the reservation and triggers the unreserve error. This fix blocks the user from doing so if there are already reserved quantities on the move line. OPW-3747596 closes odoo#162432 X-original-commit: c869077 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit: Any IoT-box syncing to a version 16 (and >) database would not be able to start odoo service due to the `num2words` missing library. This is in practice the fault of the IoT as this library is part of odoo requirement. But to solve it it would need to recreate an IoT box OS image and asking customers to re-flash their SD card which is not convenient and time consumming. After this commit: Import conditionally num2words opw-3902183 closes odoo#165067 Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Steps to reproduce: Create a Service Product with the Invoicing Policy "Based on Milestones" publish its eCommerce page. When logged out, click on "Add to Cart" on the product's eCommerce page. an error message occurs Bug: since this commit[1] "delivered_milestones" is only a valid selection for users with the group "group_project_milestone" Fix: compute the field as sudo to avoid acces error but still only allow the correct group to manually set that value opw-3892462 [1]:odoo@50ffc33 closes odoo#164714 Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit: The attachmentViewer toolbar buttons displayed incorrect colors for portal users. The mail module's public assets loaded all components and their SCSS files. However, the attachment viewer had a separate SCSS file for dark mode button colors, which was unnecessary for portal users. Removing it would help fix the bug. After this commit: AttachmentViewer toolbar button colors now display correctly for portal users. task-3872205 closes odoo#163927 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Some modules may use attachments from mail messages directly. In that case it may be desirable to at least be able to write over the name and other non-critical information even if the attachment is linked to a document. The restrictions on writing on message attachments is reduced to only apply to data fields, as those are the only ones that we really don't want people to change. Also return True instead of None in the override of `check` to match the behavior of the parent. Also reword the error message to convey writing is also forbidden. Complementary to 4c4e63f task-3519815 Part-of: odoo#164985
Administrators are technically allowed to delete attachments from any message. However the UI does not reflect that since [1] 1: 4c4e63f task-3519815 closes odoo#164985 Related: odoo/enterprise#62223 Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com> Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
task-3806683 Co-authored-by: Thomas Becquevort (thbe) <thbe@odoo.com>
Commit that introduced the issue: [1] Issue: ====== The email sent from chatter message isn't correctly formatted. Steps to reproduce the issue: ============================= - Go to chatter of any form view - Open the mail compose modal - Add a primary link the in the email body - Send it - The email isn't formatted in the received email. Origin of the issue: ==================== The flow goes as follow, we first change the field and then when clicking send, we first update the value of the editor by `onWysiwygBlur` , then before the send is done, the field is saved which will trigger the event `NEED_LOCAL_CHANGES` which will call commitChanges, but since we already updated the value and we don't have urgent, nothing will happend and the function `toInline` will never be called. Solution: ========= To not break the old commit behavior and make it reset with disard, we add another flag `shouldInline` so we can force `commitChanges` and calculating inline style when saving. [1]: odoo@3573167 opw-3885368 closes odoo#163323 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce: - create a new spreadsheet - right click any cell => boom `Cannot read properties of undefined (reading 'id')` Bug introduced by odoo/enterprise@31401c7 opw-3900571 closes odoo#165183 X-original-commit: odoo/enterprise@78218c9 Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
The payment acquirer must always be linked to a single journal, one per company. It's currently an hard constraint we have on the journal. So after the duplication, both are always linked to the same journal but only one appear on it. This "fix" is improving that allowing the duplication of an existing acquirer and to be able to link them to different journals or on the same one. opw-3704407 closes odoo#164208 X-original-commit: 88782d3 Signed-off-by: John Laterre (jol) <jol@odoo.com> Signed-off-by: Laurent Smet (las) <las@odoo.com>
In the express checkout flow delivery methods with failed rate shipment stay still available as a choice for the users. With this commit only carriers with successful rate will be shown. opw-3861519 closes odoo#161524 Signed-off-by: Valeriya Chuprina (vchu) <vchu@odoo.com>
defs was imported from lxml.html.clean.defs, where defs is actually imported from lxml.html After lxml 5.2, clean is moved into a separate package and def is not importable from clean anymore. Simple fix, adapt the import. Part-of: odoo#165081
closes odoo#165081 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The aim of this commit is to fix the view returned from the expense split wizard Context: When splitting an expense, the wizard view returns the expense list view with "my expenses" a "to report" filters activated. This makes splitting an expense attributed to someone else return an empty view. After this commit: The view now uses a domain that selects the expenses the wizard modified and/or created closes odoo#164499 Task-id: 3911134 Signed-off-by: William André (wan) <wan@odoo.com>
…iant Currently, an error is generated when unarchiving multiple products which have dynamic attributes & variants. Step to produce: - Install a 'Sales' module. - Navigate to the Sales / Products / Products, And create a product. - Add a 'Product Name' and save a record, and then add dynamic Attributes & Variants. - Repeat the process described in the above step to create another product with the same configuration as the first one. -Go to list view of 'Product'. select both products that we made recently and click on the Action button to archive both products. - Click on 'Filters' to see the archive product, And select those products to Unarchive. ValueError: Expected singleton: product.template(39, 37, 40, 42, 38, 46, 34) The issue occurs when unarchive multiple products that contain dynamic attributes & variants. As a result, the system receives multiple product templates at [1]. link[1]: https://github.com/odoo/odoo/blob/e5635c38810a745f00b106d7a075ae1553de50c7/addons/product/models/product_template.py#L745 To resolve the issue, replace a 'self' with 'tmpl_id' to get a single product template record instead of multiple. sentry-5222160918 closes odoo#165108 X-original-commit: 4d1e2a4 Signed-off-by: Meet Gandhi (mega) <mega@odoo.com>
Commit that introduced the issue: ================================= odoo@e806328 Issue: ===== when an icon is converted to png it's cropped. Steps to reproduce the issue: ============================= - Go to this url: {host}/web_editor/font_to_img/61802/rgb(0,143,140)/rgb(255,255,255)/190x200 - The icon is cropped. Origin of the issue: ===================== In this case we are using `top` and `left` as they are the top left corner of the icon inside the image , but in reality the returned value is 0 , and the top left corner is represented by `box[0]` and `box[1]`. Solution: ========= Use of `box` values instead of `top` and `left` opw-3865845 closes odoo#165193 X-original-commit: 07de2db Signed-off-by: David Monjoie (dmo) <dmo@odoo.com> Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Problem: The arabic_english_invoice report displays product name twice since the description includes the product name by default. Solution:The report should only display the description if the description is not the same as the products' name. Otherwise, the report should display the products' name in the same language as the customer. Steps to Reproduce on Runbot: 1. Install Sales,l10n_sa,l10n_gcc_invoice 2. Switch to SA Company 3. Create a product with sales description 4. Create an invoice with the product from step 3 5. Print the invoice report 6. Observe the product name is displayed twice 7. If Arabic is enabled as a language, the product name will be displayed three times, with the 3rd being in Arabic. opw-3768196 closes odoo#157774 Signed-off-by: Quentin De Paoli <qdp@odoo.com>
In production we are encountering an issue wherein the message number is exceeding the maximum value (255). This results in an error when converting the integer into its byte value representation. The solution to this is to reset the message number upon each send. closes odoo#165242 Task-id: none Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
The class doesn't have the post_install tag, and so, is skipped. runbot-25903 closes odoo#165240 Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
This commit removes the dead and undeterministic test added by mistake after an unsucessful merge. This test assumes that the organizer of the event might always be on the position 0 of the attendees list but it is not always the case. Issue from: odoo#164408 closes odoo#165346 Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
According to MDN: > Unlike the input event, the change event is not necessarily fired for each alteration to an element's value. closes odoo#165347 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
With the conversion of inline templates in [1], a typo was introduced that changed "screen" to "string". Also the string was escaped and not displayed correctly. This commit fixes these issues. [1]: odoo@5700cc6 closes odoo#164893 Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In this commit, if the user has created a leave request for today and it remains unvalidated, they can delete it However, past leave cannot be deleted Task-3775186 closes odoo#156851 Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce: - Install Accounting, l10n_it_edi and Contacts - Switch to an Italian company (e.g. IT Company) - Go to Contacts - Create an EU contact with "/" or "NA" as VAT (e.g. a Germnan contact with a full address) - Create an invoice: * Customer: [the created contact] * Product: [any] - Confirm the invoice - Process the electronic invoice - Check the generated electronic invoice Issue: 1) The country of customer is first computed from his VAT number and a fallback is made on his country. It should be the opposite. 2) In the XML, the "IdFiscaleIVA" section is set for customer with "/" (or "NA") as "IdPaese", but it should not because customer doesn't have a VAT number. If the XML is sent for validation, it is rejected because of that. Solution: 1) Backport of odoo#164950 2) Add a condition on "IdFiscaleIVA" node as it is done from saas-16.4 opw-3889051 closes odoo#165365 X-original-commit: a34019c Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com> Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
ThomasBinsfeld
changed the title
ThomasBinsfeld
force-pushed
the
16.0-ref_lxml_5.2_compatibility_tbi
branch
from
ca2bad9
to
fb4b1f2
Compare
ThomasBinsfeld
force-pushed
the
16.0-ref_lxml_5.2_compatibility_tbi
branch
from
fb4b1f2
to
8948ec1
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.