[16.0] [REF] Mail: remove channel data #84
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
When we create partial receipts in subcontracting orders, origin moves are not correctly distributed. Once the final move that carries the finished product into stock is split, it maintains all origin moves that it had in the beginning. Instead of doing that, each of the split moves created in the backorder should only keep its real related origin move. Doing that change, it eases the navigation between linked moves in many other complex processes. Otherwise, it makes the process of finding the linked move difficult. All this happens due to the fact that when the quantity done of a move is saved in the receipt picking, the Subcontracting Orders and their associated stock moves are already divided. Then, since the origins are already separated before confirming the backorder, when the division is made, a selection must be made of their respective origin move. In version 14, this doesn’t happen because the origin is assigned first and then the Subcontracting Orders are divided. So, this PR proposes a solution in which when the split move is done, it selects the last origin move created and assigns into it. Since the moves are ordered by sequence, selecting the last one returns the last stock move created when saving the quantity done. Then, it also removes that origin move from the original stock move. [FIX] mrp_subcontracting: Test is considering one origin move that should not be considering [FIX] sale_stock: Test is considering one origin move that should not be considering closes odoo#148262 Signed-off-by: William Henrotin (whe) <[email protected]>
This a backport of odoo@94ed203 The reason behind the backport is to make reloading the page works correctly and not use default values everytilme. opw-3662606 Part-of: odoo#149487
Issue: ====== Payment methods doesn't show when updating delivery method Steps to reproduce the issue: ============================= - Install website_sale - Activate coupons and promotions in settings - Create a coupon program with the follwing values : reward: discount, percentage: 100% - Save the program and generate some coupons - Activate at least 1 free delivery method and 1 free delivery method - Activate at least one payment method - Go to shop add anything to cart - Apply one of the codes from the generated coupons - Go to confirm order and change between the delivery methods. - If the default delivery method is free, the payment methods will never show , otherwise they will always show. Origin of the issue: ==================== The payment methods were rendered using `t-if` directive which means that we can't toggle it dynamically since they don't exist in the view. Solution: ========= we reload the page only when we toggle from zero to non zero total. opw-3662606 closes odoo#148431 closes odoo#149487 Signed-off-by: Antoine Vandevenne (anv) <[email protected]> Signed-off-by: Mahdi Cheikh Rouhou (macr) <[email protected]>
As _compute_quantities_dict does use stock.move as a source of calculation we need to make sure that the dedicated owner is set also on inventory moves which was forgotten and resulted in wrongly computed quantities in the past in case of such an use case. closes odoo#149532 X-original-commit: 02d5c04 Signed-off-by: Arnold Moyaux (arm) <[email protected]>
The aim of this commit is to fix the computation behavior of the downpayment line of the sale order. Context: Create a sale order and invoice a down payment. Make a credit note for the downpayment invoice for a part of the invoice's amount. Before the commit: The downpayment line on the sale order gets its price_unit updated to the amount of the last credit note. After the commit: The downpayment line on the sale order gets its price_unit updated to the sum of the amount of all linked invoice. closes odoo#148975 Task-id: 3634439 X-original-commit: ac2ca43 Signed-off-by: William André (wan) <[email protected]> Signed-off-by: Brice Bartoletti (bib) <[email protected]>
This commit resolves an issue in the `link_tools` test, specifically addressing a failure that arises when verifying the synchronization between the link's href and the content of the `<a>` tag. The failure was attributed to the oversight of not clicking outside the popup to close it before interacting with the link. This also modifies some steps to make them clearer. Note: the race condition that occurs in this test was very rare and was reduced a lot by [1], its parent commits and their related forward-port. The last version of this commit here actually does not seem to change much but the code speaks for itself: this is how it should be written. Further race conditions need to be fixed in this test again anyway. [1]: odoo@9b26aaf runbot-24929 closes odoo#144234 Signed-off-by: Quentin Smetz (qsm) <[email protected]> Co-authored-by: qsm-odoo <[email protected]>
### Contains the following commits: odoo/o-spreadsheet@3fda98572 [REL] 16.0.29 odoo/o-spreadsheet@afc1b332b [FIX] range: Support ranges with no `Rangeparts` Task: 3608941 odoo/o-spreadsheet@ce7412e02 [REV][FIX] side_panel: cf rule range bugs odoo/o-spreadsheet@e5adfb7dc [FIX] format: support additional date formats odoo/o-spreadsheet@4a956f3ea [FIX] side_panel: cf rule range bugs closes odoo#149721 Signed-off-by: Rémi Rahir (rar) <[email protected]>
Steps to reproduce:
- Configure a non-ASCII custom domain (Punycode encoded) on a database
(e.g. `test-môu.com` <> `xn--test-mu-y0a.com`).
- Setup test API keys on a Stripe account ("Publishable" & "Secret").
- Install and activate the Stripe payment acquirer (in "Test Mode").
- Go to the Stripe Odoo config (Invoicing > Payment Acquirers > Stripe).
- Configure Stripe API keys and click on the button to "GENERATE YOUR
WEBHOOK" > traceback: `Invalid URL: Non-ASCII characters in URLs must
be percent-encoded in order for the URL to be valid`.
The same error occurs in every interaction with the Stripe API.
The `get_base_url()` refactoring (exactly [1]) introduced a way to get
the most suited URL for a record in the following order:
`record.website_id` > `record.company_id.website_id` > The ICP:
`web.base.url`.
For payment acquirers, and to handle multi-website scenarios, the code
uses the base URL: `httprequest.url_root` which explains why the error
occurs even when the domain name is configured in punycode.
The goal of this commit is to fix this behavior by correctly encoding
the returned base URL.
[1] odoo@92175d3
opw-3619608
closes odoo#149758
X-original-commit: 40e0f65
Signed-off-by: Valentin Chevalier <[email protected]>
Steps to reproduce: - Activate developer mode - Install Inventory and Sales - Go to "Inventory / Configuration / Settings" - Activate "Storage Locations" and "Multi-Steps Routes" - Go to "Inventory / Configuration / Warehouse Management / Warehouses" - Configure main warehouse: (e.g. San Francisco warehouse) * Outgoing Shipments: Send goods in output and then deliver (2 steps) - Go to "Inventory / Configuration / Warehouse Management / Rules" - Open the following rule: * Action: Pull From * Source Location: WH/Stock * Destination Location: WH/Output * Route: San Francisco: Deliver in 2 steps (pick + ship) - Configure the rule: * Propagation of Procurement Group: Fixed * Fixed Procurement Group: [create a new one] - Create a storable product (e.g. Product X) - Update its quantity (e.g. 3) and apply - Create a SO with 2 Product X and confirm - Go to "Inventory / Operations / Transfers" - Open the pick move linked to the SO (e.g. WH/PICK/00001) - Set done quantity to 1 and validate - Create a backorder for the remaining quantity (e.g. WH/PICK/00002) - Create another SO with 1 Product X and confirm => Its pick move is merged with WH/PICK/00002, which contains now 2 Product X - Open WH/PICK/00002, set done quantity to 2 and validate Issue: When validating WH/PICK/00002, the products should be reserved in the delivery moves of both SO, but it is only done for the first one, leaving the second one in the "Waiting Another Operation" state. Cause: When validating a move (i.e. WH/PICK/00002) linked to several destination moves, the destination moves are reserved by checking the availability of the product. For the first destination move, its origin moves are WH/PICK/00001 and WH/PICK/00002, having an IN value of 3 and an OUT value of 2, which is correct. When checking the availability of the second destination move, its origin move is WH/PICK/00002, having an IN value of 2, but for the OUT value, the first destination move is taken into account, generating an OUT value of 3. Solution: When computing the availability, if the origin move is linked to several destination moves, it should take all the origin moves of all the destination moves into account. opw-3548123 closes odoo#149780 X-original-commit: 0461d9e Signed-off-by: Anh Thao Pham (pta) <[email protected]>
Have a nested (2 levels) form view with a footer. On the main view, add a record in the one2many in form view (dialog). Before this commit, the footer of the nested one2many form (within the dialog) was put inside the footer of the dialog, which is wrong, as the footer originates from a subview, hence has nothing to do with its parent. After this commit, each subview's part that should be rendered elsewhere than in the main formRenderer doesn't pollute the main view. opw-3681966 closes odoo#149896 Signed-off-by: Aaron Bohy (aab) <[email protected]>
Currently, when a user that is not part of the 'base.group_system' group, they are unable to submit invoices to ZATCA and print B2B invoices since the QR code requires the use of the l10n_sa_production_csid_json fields. To fix this, we mark the l10n_sa_qr_code_str as compute_sudo=True and use sudo when we try to sign XML before submission to ZATCA X-original-commit: ddeb47e closes odoo#149342 Signed-off-by: Josse Colpaert <[email protected]>
When a line with a factor_percent of -100 is applied in the tax, it should be subtracted from the ImporteTotal. This way, we might think that the total of the invoice should do, but we need the amount before application of the withholdings. And in the case of DUA it should be the sum of base and tax. Doing this, we realized that we do not have any tests for vendor bills and their refunds for the intra-community case, so we added one for vendor bill and one for vendor refund. (there is no -100 line for sale) In the meantime, we added docstrings on the existing tests and realized that the sale of intra-community services, it should be no sujeto por reglas de localizacion instead of sujeto. (because as well with the fiscal position, the delivery address counts) We also saw that for intra-community, the clave regimen depended on the tags on the amls but the refund repartition lines were not mapped on the tax report line with Intra-community but in a separate refunds section (mod303), so we fixed by checking all tags on the tax from all the repartition lines. task 3603788 closes odoo#146550 X-original-commit: 83d5945 Signed-off-by: Olivier Colson (oco) <[email protected]> Signed-off-by: Josse Colpaert <[email protected]>
In a spreadsheet with multiple data sources (2 pivots), each data source initially loads and triggers a new evaluation upon loading. This results in two evaluations, even if both data sources resolve in less than 10ms apart. In such cases, the first re-evaluation becomes redundant, as a new one is immediately triggered. The issue is worse when more than 6 RPCs are required, as most browsers limit network calls to 6 in parallel. Consequently, the 7th RPC will unnecessarily wait after the evaluation triggered by the first RPC to resolve. For spreadsheets with many many data sources, the accumulation of these pointless evaluations significantly impacts performance. In a real-life scenario with 18 data sources from our production database, the spreadsheet took approximately ~33s to fully load and become reactive. With this commit, the loading time is reduced to ~7s (only one evaluation instead of 18) (tested in 17.0). Note that this testing was conducted locally, with minimal latency, and with a limited amount of data. One consequence of this commit is that cells won't load incrementally as each data source loads. Instead, all cells will display "Loading..." until all data sources are loaded. Given the substantial speed improvement, we consider this trade-off worthwhile. This fix only impacts loadable datasources (pivot, lists, graphs), it could also include data sources using individual RPCs (currency, accounting). Maybe for master. closes odoo#149767 Signed-off-by: Vincent Schippefilt (vsc) <[email protected]>
When creating a cut-off entry with an account that has a default tax configured on it, we don't want that tax to be computed on the cut-off entry again. Reason is both that we don't want to impact the tax report again with these taxes, and it would also create an auto-balancing line to balance out the computed tax on a suspense account, which is pretty confusing to the user. task-3650271 closes odoo#148479 Signed-off-by: John Laterre (jol) <[email protected]>
Currently, when a worker (process/thread) has finished processing a request, it will keep handles on resources held by the werkzeug `Request` object. This includes open filhandles to temporary files, e.g. those of uploaded files. On platforms supporting `O_TMPFILE`, these files are not visible in the filesystem, but keep using up space in `TMPDIR` until werkzeug finally closes the file handles when the next Request is being handled. In some contexts, e.g. the upgrade platform, it can happen that there are multiple workers that only handle rare requests that upload big files (multiple GiB), kept open after the upload has finished: ```shell lsof -nP | grep -E 'odoo\/tmp.*(deleted)' | grep -vE 'GeoIP' python3 213853 odoo 13u REG 252,3 1064251 926275 /home/odoo/tmp/#926275 (deleted) python3 213853 213865 python3 odoo 13u REG 252,3 1064251 926275 /home/odoo/tmp/#926275 (deleted) ``` This can pose problems, because often the filesystem on `TMPDIR` is not very large and idle workers holding on to large files can increase the chance for ENOSPC. This patch changes the behavior such that the resources held by the werkzeug `Request` object are being closed[^1] after the response has been sent out. This also has the advantage that this work is done at potentially idle time instead of within handling the next request. [^1]: https://werkzeug.palletsprojects.com/en/2.0.x/wrappers/#werkzeug.wrappers.Request.close closes odoo#149904 Signed-off-by: Julien Castiaux (juc) <[email protected]>
Issue: Participants could not be added to an eLearning session due to the absence of the mandatory partner_id field in the tree view. Issue updated: Partner_id removal is intentional. we should block record creation from this tree view. the commit that removed partner_id is odoo#64152 Steps to Reproduce: Navigate to the eLearning module. 1. Go to a specific course. 2. In the form view of the course, click on the 'Attendee' button. 3. In the attendees list view, click on 'New' to add a participant. 4. Observe that the process fails due to a missing partner_id field in the tree view. Solution: prevent creating attendees from the tree view. opw-3555883 closes odoo#140332 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
When pasting text inside the editor, if the text looks like a URL, a link is implicitly created. Unfortunately, this also happens when the edited element does not support HTML. Because of this, when translating a page, links are created inside the translated text which does not support HTML. This commit solves this by pasting the plain text if the target of the paste does not support HTML (which is the case for translations). This commit also prevent link creation when typing a space after text that looks like an URL in targets that do not support HTML. In 17.0, `_handleAutomaticLinkInsertion` is also adapted to prevent unwanted link creation. Steps to reproduce for first scenario: - Add French to your website. - Edit your master English Home page. - Drop a Text snippet in the Home page. - Save the Home page. - Switch to French. - Translate the page. - From an external text input, copy `http://odoo.com` in your clipboard. - Put the cursor inside the Text snippet's text. - Paste. => A link was created. Steps to reproduce for second scenario: - Add French to your website. - Edit your master English Home page. - Drop a Text snippet in the Home page. - Save the Home page. - Switch to French. - Translate the page. - Put the cursor inside the Text snippet's text. - Type `http://odoo.com` followed by a space. => A link was created. opw-3546308 closes odoo#149486 X-original-commit: 29498c6 Signed-off-by: Benjamin Vray (bvr) <[email protected]>
If partner to invoice is from "Zona Franca - IVA Liberado" then the exportation invoice then the AFIP concept to use should be code 4. "Others" closes odoo#147643 Signed-off-by: Josse Colpaert <[email protected]>
Before this commit, the date was being considered in UTC instead of the time zone of the current user. This is problematic in LATAM, where the time zone is negative. closes odoo#149971 Signed-off-by: John Laterre (jol) <[email protected]>
Currently, if you open any list view in `hr_expense` and attempt to insert it into a spreadsheet, nothing happens. Steps to reproduce ------------------ * install `hr_expense` * open a list view * click "Favorites > Insert list in spreadsheet" (or "Favorites > Link menu in spreadsheet") You should see that nothing happens. opw-3633963 closes odoo#148417 Signed-off-by: William André (wan) <[email protected]>
For multiple bugfixes: https://github.com/chartjs/Chart.js/releases/tag/v2.9.4 opw-3691601 closes odoo#150016 X-original-commit: ea4e78d Signed-off-by: Denis Ledoux (dle) <[email protected]>
Steps to reproduce issue: 1. Go to Products. 2. Select a Product with an existing Barcode. 3. Click on Print Labels. 4. Select Dymo as format, add Extra Content, Confirm. 5. Extra Content is not shown. Explanation: The Extra Content is pushed out of the label by the other elements. Suggested fix: Remove Extra Content to make up for lack of space. Approved by PO (thd) and already removed on other label formats. opw-3614842 closes odoo#149757 X-original-commit: 0cf6e76 Signed-off-by: William Henrotin (whe) <[email protected]> Signed-off-by: Stroobant Paul (stpa) <[email protected]>
With the new IoT build 23_11 which uses Raspi OS Bookworm, tvservice is no longer usable. We therefore use the driver made for 17.0, but for that you need to install the vcgencmd library. In order not to force people to reflash their box, we check if the library is present, if not we install it. closes odoo#150037 X-original-commit: 5cd67de Signed-off-by: Quentin Lejeune (qle) <[email protected]>
Before this commit: Attempting to delete a selected table row does not result in the removal of the row in Firefox. After this commit: Now deleting a selected table row results in removal of the row in FIrefox. task-3610789 closes odoo#143747 Signed-off-by: Antoine Guenet (age) <[email protected]>
The tab PL Extra is visible if l10n_pl_jpk is installed and your company is not polish. This should not be the case closes odoo#146617 Signed-off-by: Olivier Colson (oco) <[email protected]>
Current behaviour before commit: In v16.0 and above clear format button was missing from snippet toolbar. Desired behaviour after commit: Now clear format button is getting appeared in snippet toolbar. task-3638147 closes odoo#147045 Signed-off-by: Antoine Guenet (age) <[email protected]>
After the migration to Bootstrap5 (odoo#95450), some standard bootstrap classes did not work anymore when *printing* the report via wkhtmltopdf (bg-dark, bg-black etc.....). This is because wkhtmltopdf doesn't support CSS Custom Properties and many Bootstrap5 rules use them (many have already been adapted in the referenced PR or linked ones) wkhtmltopdf doesn"t support rgba CSS function either. This fix allows for thoses classes to work when printing as they can be used if the report was edited via Studio's Report Editor. closes odoo#150087 Signed-off-by: Romeo Fragomeli (rfr) <[email protected]>
To reproduce the issue: 1. Create two companies C1, C2 2. Select C1 and enable C2 3. Confirm a PO with a FIFO product in C2 4. Process the receipt 5. Bill the PO with a landed cost 6. Generate and post the LC Few errors will happen: on the LC, the journal used belongs to C1, not C2. Another one: in C2, on the product's form view, the standard price does not include the LC OPW-3651022 closes odoo#150094 Signed-off-by: William Henrotin (whe) <[email protected]>
…e in query In order to avoid failing on this computation make sure actual ids are available to be used in query. closes odoo#150095 X-original-commit: c87209c Signed-off-by: Morgane Demesmaeker <[email protected]>
Steps to reproduce:
1. install the calendar module
2. in General settings, add the French -or any- language
3. create a new event
4. under **Options** tab choose the recurrence type to be weekly
5. select the days to repeat the event on
6. save the event
7. send an email using the **EMAIL** button, you can notice that works like (Weeks) and the days’ names are not translated but still in English
Investigation
- the translation is applied on the model level, not on the code level. So we have to explicitly/programmatically translate the options.
Discussion
- In the proposed fix, we compute the recurrence rule `name` by translating it to the current language -the event creator's language- but as this field is **stored**, it resulted in another issue that the invitation emails sent to the participants had a mix of languages: the email template being translated in each participant's language while the recurrence rule itself is translated in the owner's language being a **stored** field
- That's why the fix got extended to embed translating of the recurrence rule directly into the template.
- However there's a **_limitation_** we couldn't deal with that's there are two types of emails we are concerned with:
- invitation emails that follows `calendar attendee` model which works correctly as discussed
- update emails that follows `calendar event` model coming from the composer which deosn't allow to properly use partners/participants languages
Resolution
- The update emails are sent in the owner's language, with the intention to enhance the behavior in master (Task-3677327)
opw-3483319
closes odoo#141951
Signed-off-by: Arnaud Joset (arj) <[email protected]>
To reproduce ============= - Go to shop page - Edit the page - select a product - add a ribbon - modify the ribbon (background or text color) the ribbon is not updated Problem ======= the default ribbon are using the bootstrap class "text-bg-*" to set the background color and the text color. But the editor expects the ribbon to have a class "bg-*" and color css style. That's why when editing, the class "text-bg-*" is never removed so each time it's taken instead of the added style. Solution ======== remove the class "text-bg-*" from default ribbons and use the fields "bg_color" and "text_color" to set the background and text color opw-3674520 closes odoo#150185 Signed-off-by: Antoine Vandevenne (anv) <[email protected]>
Slot params are dynamic content, similar to props, and are not translated. There is no point in adding untranslated content to the .pot files; so this commit prevents the content of slot params from being exported for translation. Task-3718993. closes odoo#152564 X-original-commit: b839faf Signed-off-by: Géry Debongnie <[email protected]> Signed-off-by: Louis Wicket (wil) <[email protected]>
When switching view from a kanban view to something else (or to kanban itself eg to reload the data), we export parts of its state so that it can be restored later if you switch back to it. Part of this exported state are the current groups, because in some flows, you may archive all the records of a group, and we want the group to still be present when you come back even if it is empty. To do so, we would export the entire group datapoint, and it would be given back to the kanban view the next time around. The problem is that the group datapoint has access to its model, and also has some hooks passed in by the controller, so the group datapoint retains the entire model and component tree from the kanban view which is no longer needed. When switching back and forth, each kanban has a reference to the previous kanban, creating this long chain of objects that cannot be grabage collected. This commit fixes that by not exporting the actual data point itself, but only the pieces of it that are necessary to restore it later, which are plain values with no reference to the model or to the datapoint's hooks. closes odoo#152420 Signed-off-by: Aaron Bohy (aab) <[email protected]>
Trying to call the get_lines() method of the stock.traceability.report model was failing using the external API, due to the response containing None values. Making sure that False is returned instead of None fixes this. The XML-RPC client error is the following: closes odoo#147831 Typeerror: cannot marshal None unless allow_none is enabled Signed-off-by: William Henrotin (whe) <[email protected]>
Before this PR, the `TestImLivechatSupportPage` test could fail in a non deterministic fashion. This errors was already fixed in [1], this PR backports the fixing commit. [1]: odoo@f615dac fixes runbot-39522 closes odoo#152670 Signed-off-by: Sébastien Theys (seb) <[email protected]>
When filtering column had too much attributes, scrollbar would appear. Scrollbar was deleted but ability to scroll is left. task-3609062 closes odoo#145934 Signed-off-by: Antoine Vandevenne (anv) <[email protected]>
Steps to reproduce the bug: - Add a delay (for example 5 seconds) at the beginning of the `/sale/get_combination_info_website` route. - Add a delay (for example 10 seconds) in a `willStart` method in the `Wysiwyg`. - Go on a product page and enter edit mode. - Click on the the product image. -> The "Replace" button does not appear. In this situation, the added delays represent slow rpc answers. Let's analyse the flow of instructions in order to better understand the problem: - When you go on a product page, the `WebsiteSale` public widget is started. `_getCombinationInfo` of `VariantMixin` is then called through the `start()` of the public widget. As the rpc is taking time to answer, `_onChangeCombination()` is not directly called. - When entering edit mode, the `WebsiteSale` public widget is destroyed. Due to the edit mode, the `o_editable` class has been added on editable elements. - After the first added delay and thanks to the rpc answer, `_updateProductImage()` is called through `_onChangeCombination()`. Because the `editor_enable` class has not been added to the document body yet (due to the second added rpc), the `_updateProductImage()` method replaces some elements of the DOM and by doing so, removes the `o_editable` class of some elements. Consequently, the snippet option linked to the image is not displayed. The problem here is that the `_updateProductImage` method is called even if its associated public widget has been destroyed. To solve the problem, we first check that the associated widget is alive before handling the result of the rpc answer in the `VariantMixin` mixin. Note that the first idea was to use `this._rpc()` instead of `ajax.jsonRpc()` in the mixin. Indeed, the advantage of using `this._rpc()` is that it already ensures that the associated widget is alive before handling the result of the rpc answer. The problem is that some widgets that use the `VariantMixin` are created in such a way that `this._rpc()` can not be used on them (for example `OptionalProductsModal`). Related to runbot-28700 closes odoo#149127 X-original-commit: 5b9df66 Signed-off-by: Quentin Smetz (qsm) <[email protected]>
Issue: When using a mercado pago invalid access token with extra tabs, we get 403 response from mercado pago without a body which raises and exception while handling this exception we fail to parse the response as it has no body. line causing the issue: https://github.com/odoo/odoo/blob/9764e6f7fe39a10f3b04e1764110d8c274d0431a/addons/payment_mercado_pago/models/payment_provider.py#L70 Steps to reproduce: 1- Enable mercado pago as a payment provider 2- Set a valid access token for mercado pago with extra tabs 3- Go to website 4- Fill the cart 5- Checkout with the cart using mercado pago 6- You see error message of unhandled json parsing error Solution: We should wrap parsing the response in a try statement to handle the responses without body opw-3654133 closes odoo#152102 Signed-off-by: Omar Abosamaha (abom) <[email protected]>
- generate a lot (i.e. 10000) of records inside account.edi.documents model - call the _cron_process_documents_web_services or the ir_cron_edi_network cron. The current behavior is that only one single job with all records (i.e. 10000) are generated. This can take a lot of time or synchronization problem for cron process the queue. We implement a batching_limit parameter for a single job so that the cron can enqueue items in buckets. odoo#148849 issue-148849 closes odoo#149269 Signed-off-by: Laurent Smet (las) <[email protected]>
Issue: When the notification webhook is enabled for Adyen, sometimes the response back causes an SQL concurrent update. Odoo then creates a retry towards Adyen, charging the customer card several times. Both the notification webhook and the payment controller are hit, and try updatingthe same row simultaneously, which causes this behavior. Steps to reproduce: This bug is not reproducible due to a connection issue for the Adyen test account. However, if the payment request would implement idempotency we could prevent billing the customer on the same request if the request reaches this collision and is retried multiple times. Description A first payment request is sent to Adyen. The card is charged and Adyen answers that all went as expected. We try to process the payment, but a concurrent access error occurs. A retry is done. A payment request is sent again to Adyen, The card is charged AGAIN and Adyen answers that all went as expected. We try to process the payment, but a concurrent access error occurs. For each retry, the request is sent and the card is charged. If the first retry succeeds, then Odoo can finish the process. There will be only 1 payment transaction on Odoo's side (others have been rollbacked) but there will be 3 on Adyen's side and the card will be charged 3 times. This PR fixes this behaviour by adding the idempotency key to the headers with the hash of the transaction reference and the database UUID, we prevent duplicate payments to happen. OPW-3584300 closes odoo#150102 Signed-off-by: Antoine Vandevenne (anv) <[email protected]>
Description of the issue/feature this PR addresses: Depending on user rights or customization, "Print" or "Action" menu can equals to "undefined". This causes a client error when selecting lines in the tree view. Current behavior before PR: javascript error " TypeError: print/action is undefined" is raised when selecting lines in the inventory list tree view. Desired behavior after PR is merged: No error raised if user has no print/action menu available. closes odoo#152301 Signed-off-by: Steve Van Essche <[email protected]>
Steps: - Install project. - Go to settings and select Custom Email Servers. - Add alias domain. - Then go to the project. - Create a new project. - The gap between the email alias and project title is too much. Issue: -When we create a new project the gap between the email alias and project name is too much when only the project is installed and there are no options to display. Cause: -The margin-top taking too much space. Fix: -After this commit the space between email-alias and project name is decreased. task-3550638 closes odoo#139908 Signed-off-by: Xavier Bol (xbo) <[email protected]>
Ever since 14.0, from PR odoo#45414, there has been a _compute_state function for recalculating the state on holiday_status_id change The reverted commit becomes unnecessary and causes incorrect action buttons to be shown before creation Note: Reverts commit 015f8ec from odoo#82552 closes odoo#152444 X-original-commit: 0c4a174 Signed-off-by: Sofie Gvaladze (sgv) <[email protected]>
Restrict collaborator portals to: - Change unallowed fields on subtasks - Create/Update/Delete tags. They can only link, unlink tags to tasks. task-3698146 closes odoo#152763 X-original-commit: 121b47f Signed-off-by: Xavier Bol (xbo) <[email protected]> Signed-off-by: Denis Ledoux (dle) <[email protected]>
Avoid specific changes of l10n_in invoice report to affect other countries. OPW-2504287 closes odoo#151408 X-original-commit: 1146df5 Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <[email protected]> Signed-off-by: Xavier Alt (xal) <[email protected]>
…cklist Before this commit: When creating a nested checklist within another checklist and subsequently changing the direction of the parent list, the direction of the parent element would reverse alongside the pseudo element. However, in the case of nested checklists, only the content's direction would change, while the pseudo element's direction remained unaffected. Afte this commit: When altering the direction of the parent checklist's content, both the content itself and the associated pseudo element's direction is changed alongwith the nested checklist. task-3461806 closes odoo#152486 X-original-commit: 4fb6b70 Signed-off-by: Geelen Sébastien (sge) <[email protected]>
This commit fixes the problem of selection change on colorpicker fast hover. Before this commit, hovering too fast on the colors of the colorpicker unselected text that would be on the edge of the selection and uncolored. This is fixed by deep ranging the selection at the moment we limit it to fonts. This improves the accuracy of the history as, in case the font tag has been removed, it saves the text node as the current selection. And since hovering updates rely on it, it prevents losing the selection when unhovering fast (which is the cause of the bug). We noticed two behavior when dealing with this bug. When hoving on a color cell and exiting out of the colorpicker altogether, no bug appears. But when switching between two cells, multiple selection issue happen. After analysis of the performance graph, we believe that this is due to the fact in the first case, onSelectionChange events are fired and the handler is called, whereas in the other case it doesn't happen. That handler particularly reacalulates the latest selection. And this doesn't happen in our pathological case. After testing this theory, we view that the problem is solved. task-3295858 closes odoo#152505 X-original-commit: 1df89cc Signed-off-by: Geelen Sébastien (sge) <[email protected]> Co-authored-by: Hamza Maimoune <[email protected]> Co-authored-by: Antoine Guenet <[email protected]>
When inserting a list to a mega menu, the closest `LI` is a nav-item within the navbar. We aim to prevent the toggling of this list. This commit ensures that lists with class nav-item in the navbar are not toggled. task-3609500 X-original-commit: 2217af1 Part-of: odoo#152754
Commit [1] implemented an approach to preserve all the attributes when converting to a list. This is beneficial for `p` elements since they will no longer be in the DOM. However, elements other than `p` will always remain, requiring only dir attribute and not other attributes like href, data-name, describedby, etc.. to transfer to the list. [1]: c422db5 task-3609500 X-original-commit: 4eb133c Part-of: odoo#152754
The mega menu templates on the website, like `s_mega_menu_multi_menus` and `s_mega_menu_menu_image_menu`, contains a `text-center` class within the `div`. This div has multiple block type anchor nodes. When a list is added to the mega menu, the anchor node is added inside the `LI`. Now clicking on the `A` tag then adds the `oe_edited_link` class, resulting in the centering of the A tag due to the `inline-block` display of the `oe_edited_link` class. This commit fixes the issue by adding display `inline-block` when not with nav-link. task-3609500 X-original-commit: 5a30710 Part-of: odoo#152754
Previously, sanitize would remove the `<p>` tag if it was a child of an `<li>` element. This commit makes sure that the `<p>` tag which is a child of `<li>` with class `nav-item` does not get removed. task-3609500 closes odoo#152754 Signed-off-by: Antoine Guenet (age) <[email protected]>
Commit c05815a will go through a chain a move to set the last one as "reserved from stock" if the first one is reserved even if the cahin is not completed yet. The issue is if the chain is inter warehouses, a move out in a warehouse can be marked as "reserved" while the stock being reserved is actually the one of another warehouse. To reproduce Create 2 warehouses create a stock rule (pull) and a route between the 2 stock location of those product create a product having the route MTO and the new replenish route create a delivery in the second warehouse a transfer from the two warehouse should be created and linked to the delivery Open the forecast report for the warehouse that deliver the product -> the delivery is marked as "Reserved from stock" instead of being linked to the replenish transfer. closes odoo#152322 Signed-off-by: Quentin Wolfs (quwo) <[email protected]>
In tax report, ve38 line should display the tax excluded amount, not the tax amount. opw-3609402 closes odoo#145570 Signed-off-by: Florian Gilbert (flg) <[email protected]>
Prior to this commit, Gift cards assigned to a specific partner were restricted for use only by that partner. This commit rectifies the issue, enabling Gift cards to be usable by any customer as intended. opw-3689391 closes odoo#149913 Signed-off-by: Christophe Monniez (moc) <[email protected]>
And pull Danish opw-3626068 closes odoo#152864 Related: odoo/enterprise#55958 Signed-off-by: Martin Trigaux (mat) <[email protected]>
…nción": Do not take into account "retención" type taxes in the sum of the total price of the invoice lines, these taxes are of retention types and are declared in RetencionSoportada XML node. Add amount_retention in invoice values and change template_invoice_factura to activate RetencionSoportada xml node. Before this commit: Invoices with "retención" type taxes are not declared correctly, validation errors in the response of the tax agency. With this commit: Invoices with "retención" type taxes are declared correctly and accepted with no validation errors in the response of the tax agency. closes odoo#152302 Signed-off-by: Josse Colpaert <[email protected]>
closes odoo#152826 X-original-commit: dfff7b9 Signed-off-by: Martin Trigaux (mat) <[email protected]>
This commit resolves a bug related to zero-width spaces within the inner content of a link. The bug led to a systematic test failure in 17.0 link_tools when comparing the input value with the expected value. The bug originated from [1] that manipulates zero-width spaces to allow users to select the edges of the link. Steps to reproduce: - Navigate to the Project app and open a random task (create one if none exists). - Select the "Description" tab. - Enter "/link" and press "Enter" to activate the link tools dialog box. - In the link label field, input "The Website". - In the URL or email field, input "localhost:8069". - Save the changes. - A new div is generated with the class "note-editable". - Click on the newly created link. - Edit the link by clicking on the edit icon in the popover. - Direct the focus to the link label field at the end of the string "The Website". - Press the "Backspace" key — observe that nothing happens. This fix is actually a complement to [2]. The test added in [3] eliminates zero-width-spaces prior to asserting the equality of values. This was appropriately addresses and handled in this commit. [1]: odoo@99bc9b1 [2]: odoo@71feab5 [3]: odoo@a565861 runbot-44779 closes odoo#152853 X-original-commit: cd63810 Signed-off-by: Quentin Smetz (qsm) <[email protected]>
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.