This repository was archived by the owner on Sep 22, 2025. It is now read-only.
16.0 #1
Open
16.0 #1
Conversation
This file contains hidden or 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
Member
Author
|
eissa |
Scenario: - insert the last blog posts widget in a page using Card Layout - open editor and edit (eg. Background) the cover of a post - save Result: the change is lost Cause: the content of the widget is dynamic, and we delete the content in cleanForSave (that call the destroy of the widget) before saving, so the change are not saved. Fix: make the dynamically added cover widget unselectable, the cover of the blog post can still be changed in other locations (blog post list, blog post page). Note: the issue doesn't happen in 17.0 in big picture template, because the figcaption is not a children of the cover snippet. It happens in 18.0 because the content of the cover is a children of the cover. opw-4633287 closes #210079 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Follow up of 1c17cb5. It is OK to write raw bytes in a Binary attachment=False field. The thing actually is: * Binary fields, accept raw bytes, store raw bytes in db. * Image fields, reject raw bytes, want base64, store base64 in db. When reading Image fields it is easy: always decode the base64. For Binary fields it is complicated, because some crazy people encode their binary fields in base64, and expect automatic base64 decoding when read. Crazy! So *attempt* to decode the b64 and if the decoding fail just assume it was raw bytes from the begining. Those crazy people even use silly base64 libraries to encode their bytes, e.g. `base64.encodebytes` which is a Email MIME utility: it adds `\r\n` every 76th character because of the folding requirements in email headers. So those bytes are "technically" not base64 (as far as `validate=True` is concerned) but we still must decode them. CRAZY. I'm looking at you `base.language.export.data`. closes #214758 Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Whenever there is a fault in the ZATCA onboarding steps (like missing Certificate Signing Request (CSR) information etc.), a traceback is returned to the user instead of a clear error message. This behavior was introduced by the following PR: #205671 which changed the return format of the `_l10n_sa_call_api` function in case of failures. Steps to reproduce: - Configure a Saudi Arabia company - Switch ZATCA environment to Simulation (or Production) - Attempt to onboard a journal using an incorrect OTP code - A traceback is triggered instead of a clear user-facing error Traceback example: ``` File "/home/odoo/src/odoo/17.0/addons/l10n_sa_edi/models/account_journal.py", line 200, in _l10n_sa_compute_production_csid_validity journal.l10n_sa_production_csid_validity = self._l10n_sa_get_pcsid_validity( File "/home/odoo/src/odoo/17.0/addons/l10n_sa_edi/models/account_journal.py", line 516, in _l10n_sa_get_pcsid_validity b64_decoded_pcsid = b64decode(PCSID_data['binarySecurityToken']) File "/usr/lib/python3.10/base64.py", line 80, in b64decode s = _bytes_from_decode_data(s) File "/usr/lib/python3.10/base64.py", line 45, in _bytes_from_decode_data raise TypeError("argument should be a bytes-like object or ASCII " TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType' ``` This is due to the check in `_l10n_sa_get_compliance_CSID` for an 'error' key, not present in the response when an OTP is invalid because in these case, the `_l10n_sa_call_api` return the response_data directly. This fix improves the behavior by displaying a user-friendly alert message with the error returned by ZATCA, instead of a traceback. This ensures a better experience and compliance with CCSID onboarding flows. opw-4838542 closes #214391 Signed-off-by: Josse Colpaert (jco) <jco@odoo.com>
### Contains the following commits: odoo/o-spreadsheet@8bc0a8a1d [REL] 16.0.73 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) odoo/o-spreadsheet@49a987e7b [FIX] collaborative: don't send duplicate messages [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) odoo/o-spreadsheet@133dc1b21 [PERF] collaborative: avoid useless transformations [Task: 4873461](https://www.odoo.com/odoo/2328/tasks/4873461) odoo/o-spreadsheet@ee63cc687 [FIX] menus: hide invalid 'delete' option from edit menu [Task: 4854659](https://www.odoo.com/odoo/2328/tasks/4854659) closes #215088 Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
`l10n_eg_long_edi` is set by two different computes. This is completely useless as it will trigger a write and the actual compute will still be called when the field is read. closes #215134 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Calling external resources can lead to random failures in tests test_tracking_short_code calls a tracked url to check the side effect of this call, but we actually don't need to follow the redirect. Fixes the test by not following the 301 and checking the target instead. closes #215175 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
invoice status Before this fix, users could create a refund order from multiple POS orders as long as none of them were invoiced. A previous fix (commit 58fa771) already prevented refunds from multiple **invoiced** orders via the POS interface, as such cases could not be invoiced due to conflicts with multiple related account moves. However, it was still possible to create a refund from multiple **non-invoiced** orders, and then later invoice those original orders through the backend. This ultimately leads to the same invoicing failure when trying to invoice the refund, because it ends up being linked to multiple account moves. This commit improves upon the previous one by blocking refund creation from **more than one POS order, regardless of their invoicing status**, thus ensuring consistency and preventing invoicing errors in the future. closes #214290 Signed-off-by: David Monnom (moda) <moda@odoo.com>
closes #214036 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps: - Open any views with a search bar - Press ALT + Q (hotkey used to focus search input) - Nothing happens This behavior has been introduced by #185960 This commit just adds the focus that had previously been removed to enable the input to be correctly selected so that the user can write directly on it. opw-4874194 closes #215127 Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Currently if 2 concurrent requests are generating a sequence number on a sequence that requires a new range odoo will create 2 ranges with the same start and end date. Both request will then return the same sequence number. closes #210277 Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Due to historical error, the key mapped for cancel remarks seems to be incorrect. Due to which while cancelling the E-waybill we receive the error code `[659] Remark is mandatory`. In this commit, we make sure the keys are mapped correctly as per https://docs.ewaybillgst.gov.in/apidocs/version1.03/cancel-eway-bill.html Though as per the schema validation the remark is not mandatory after receiving the ticket it doesn't seems like that :) opw-4882071 closes #215523 Signed-off-by: Josse Colpaert (jco) <jco@odoo.com>
…_price Current behavior before commit: The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the `_compute_purchase_price` method. Within `_compute_purchase_price`, the method `_compute_average_price` is called with the company context of the sales order line (SOL). Company Context - correctly set to SOL company https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py\#L14 Method Call https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py\#L18 During recursion in `compute_average_price`, the company context incorrectly reverts to the global company instead of preserving the original company context from the initial call. Recursive call https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/mrp_account/models/product.py\#L77 Since the product is a kit, its cost is derived from its components. However, due to the incorrect company context switch, the purchase price is incorrectly set to 0 (because the product does not exist in the global company). This distorts sales margins in ongoing sales orders. Root Cause: The stock_moves passed into the method have env.company set to the 1st company (due to the scheduler cron being called with sudo across all companies at the same time). At https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/mrp_account/models/product.py\#L66 bom_lines are extracted, inheriting the env of the stock_moves. As a result, `_compute_average_price` is executed within the context of a company that may not match the originally set SOL company, which may lead to incorrect computations. Fix: Ensure that `stock_moves` is explicitly passed into the method with the correct company context. This guarantees that the company context remains consistent throughout the execution. opw-4222976 closes #192890 Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Before this commit: When adding any statement line with a date in the future, the amount is reflected in the journal's final balance. While it's not considered when calculating the graph points of the dashboard. which results in a discrepancy between balances and graph points of all past points. With this commit: Future points are considered in graph points aggregation and visualization. opw-4823770 closes #214641 Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
… common name to be unique per journal Previously, the company name was used as the common name when onboarding the journal. However, the common name has to be unique. The fix changes the common name to use the journal's short code, journal name, and company name to ensure uniquness. Additionally, an improvement is applied to the serial number on journals. Previously, users inputted this field manually. Now, the system uses the journal's id as the serial number to ensure uniqueness. A post-migration script was added to notify users that they need to re-onboard their journals. This is done in case users previously onboarded journals with non-unique serial numbers. task-4797124 closes #215012 Signed-off-by: Josse Colpaert (jco) <jco@odoo.com>
Added the dirty hook `_get_additional_robots_rules_web` to allow modules to add extra rules to the robots.txt file whenever it's needed. Previously, it was blocking all the user-agents when website was not installed. opw-4726371 closes #211734 Related: odoo/enterprise#85990 Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
The fix 64a7b63, while fixing the behaviour of the numeric fields, ended up also breaking the behaviour of text fields. Namely, the empty text fields were represented by empty strings and the fix forced their value to 'False' which is the result returned by the server. Since the original idea was to fix an issue that occured in version 18.0 and later, we will revert the change in 16.0 and address it properly in 18.0. task-4897690 closes #215820 Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Actually update to use new email domain closes #216195 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
closes #203293 Signed-off-by: Ruben Gomes (rugo) <rugo@odoo.com>
* PROBLEM: install account_debit_note module, add a debit note -> check the log at chatter we will see 2 message, one is 'This entry has been duplicated from ...' and another is 'This debit note was created from..' * Fix by only keep one message log in that case, just like in odoo 18 check the default value to have a appropriate message content closes #214302 Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
### Contains the following commits: odoo/o-spreadsheet@a1d6303ae [REL] 16.0.74 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) odoo/o-spreadsheet@6cdea61bc [FIX] Selection: Fix navigation through merges [Task: 4873718](https://www.odoo.com/odoo/2328/tasks/4873718) closes #216249 Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This commit fixes the search for OSS taxes in `_has_oss_taxes` function. The current search approach (with tax tags) is better in the following points: 1. No need to use `sudo` for ir.model.data access 2. Currently, user-created OSS taxes are considered in the search task-4548095 closes #215614 Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
[1] was backported from 17.0 to 16.0 and erroneously introduced the robots route that is present in that version in the web module. As this changes the behavior considerably we don't actually want robots.txt to be added in stable. Remove the route but keep the overridable list getter for website. [1]: 44f9d16 closes #216259 Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Binary fields can hold arbitrary data. Before this commit there were crashes when the value was not a string and the filename field was not set. After this commit, there is no crash, though we recognize that this doesn't make much sense to display such field in the first place. Usually those fields that do not contain a string are technical ones that end up in views by accident. closes #212780 Part-of: #213967 Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
…t form view Before this commit, computing a default form view included binary fields that are not stored Those fields are usually made to hold arbitrary data, that is not necessarily a string. This lead to some crashes in some cases. After this commit, we do not include those fields any more closes #213967 Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
When using Ubuntu Jammy, werkzeug is version 2.0.2, which does not yet follow RFC3986. With Ubuntu Noble, werkzeug is version 3.0.1 and has removed url_encode. We now recommend changing to urllib.parse.urlencode which also does not follow RFC3986. RFC3986 is being followed in an inbetween version of werkzeug. We have vendored the code from a version above 2.1.0, which includes the following git pull request: pallets/werkzeug#2320 This parser differential behavior can cause unexpected behavior. Due to our modular system we should preserve the behavior that developers expect. A third-party module should work regardless of differences in the supported OS they choose to use. opw-5172692
Backport ICE number from 18.0 to 16.0: f9d00e6 Reason: The ICE (Identifiant Commun de l'Entreprise) is an identification number assigned to businesses and legal entities for various administrative and legal purposes in Morocco. If the partner has one, it must be indicated on the invoice. The ICE number is supposed to be put on all the invoices made to Moroccan companies, whatever the country of the company issuing those invoices. We hence add that directly into the account module. task-4879950 closes #237068 Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Werkzeug's url_encode does not have consistent behavior between versions, and gives three different result when running Odoo under Ubuntu Jammy, Ubuntu Noble or a virtual environment. After this commit: Use the standard library urllib, which has consistent behavior across versions. opw-5187047
…records RATIONALE When a cascade delete occurs in DB, ORM methods are not called. More specifically loosely connected records using res_model / res_id pair are not removed when unlink override exists. SPECIFICATIONS If you post a scheduled message on a record and delete it before it is sent, the notifications cron got blocked with `MissingError`. Now, those notifications are simply skipped. Scheduled message is unlinked, but no message is produced. As there is no recovery mean no log is done either, would add useless information. @moduon MT-7276 Task-5138556 Part-of: #233071 Related: odoo/enterprise#101185 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE When a cascade delete occurs in DB, ORM methods are not called. More specifically loosely connected records using res_model / res_id pair are not removed when unlink override exists. SPECIFICATIONS When a record that inherits from `mail.thread` is deleted by an 'ondelete="cascade"'' SQL constraint, its messages and notifiations are kept in DB. If some of those notifications is in status 'bounce' or 'exception' it will keep being displayed to the user. However, the user won't be able to do anything with it. Actually, if they try to, they'll get an exception. This fix avoids displaying failures related to non-existing records. This clears noise and avoids situations where the user is unable to react to their notifications. COUNTERS This implies additional query counters in various tests, as we add some exists in calls, notably when messages are formated, which happens quite frequently. Those querie are fast as they are just a direct hit to the id field of tables. @moduon MT-7609 OPW-4285691 Task-5138556 Part-of: #233071 Related: odoo/enterprise#101185 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE When a cascade delete occurs in DB, ORM methods are not called. More specifically loosely connected records using res_model / res_id pair are not removed when unlink override exists. SPECIFICATIONS If there are some activities linked to removed records, those are fetched by systray. However when trying to set them done there is a crash linked to posting a message on an unexisting record. We are now defensively checking records exist. For removed records no message is posted, and attachments are removed while removing the activity. Task-5138556 Part-of: #233071 Related: odoo/enterprise#101185 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE When a cascade delete occurs in DB, ORM methods are not called. More specifically loosely connected records using res_model / res_id pair are not removed when unlink override exists. SPECIFICATIONS Fix various use case in mail * notifications sent for scheduled messages; * failure notifications management; * activities mark as done; Task-5138556 closes #233071 Related: odoo/enterprise#101185 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Verify that the user is an internal user to avoid unexpected behavior. task-5349128
In rare case when we would like to schedule messages without model a variable is not defined in that scope. closes #238762 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When running tests locally, it's really annoying (and sometimes really jarring / surprising) to hear random beeps and boops from your machine, especially when it's an old timey ringtone from voip. Make it stop. closes #238882 Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Steps to reproduce =============== 1. Enable reCaptcha in Settings and configure keys. 2. Go to an event and click Register. 3. Fill in the form but wait more than 2 minutes. 4. Submit the form ---> An error message is shown. When reCaptcha was enabled on event registrations, the token was being requested too early (during `willStart`). Since a token is only valid for 2 minutes, users who took longer to fill out the registration form encountered an error when submitting. After this commit, the reCaptcha token is requested only on submitting. This way, the token is always valid and the form can be submitted successfully, even after several minutes. Backport of ed691e6 closes #238504 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The parser rules cannot be modified once the parser has been instantiated. task-5091744 closes #239046 Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When a user gets deleted or archived, his signup token is not correct and should be recomputed and resent if still required. task-5340362
When `lower_logging` encounters a `LogRecord.args: Mapping`, it fucks up and strips out all the values keeping only the mapping keys (as a tuple), which then breaks when trying to format it in `LogRecord.msg`. Fix the issue by moving the entire message munging into, appropriately, the formatter: `getMessage` will do the `str.__mod__` call at which point we don't need to deal with the args at all, then `formatMessage` generates the full message line (not including the stack traces from `exc_info` and `stack_info`, those are added in the second half of `Formatter.format`). https://runbot.odoo.com/odoo/error/234669 closes #239410 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
closes #177614 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit adds the Global Location Number (GLN) to delivery partners, which is required to be reported during eInvoicing. closes #237591 Task: 5237220 Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Legacy payment APIs will be discontinued by 31 Dec 2025. Backport Worldline provider to 16.0. - Worldline payment provider was introduced in v18.0 - Worldline has now been backported to version 16.0 and serves as the replacement for Ogone. Affected version-16.0 task-4687593 closes #215758 Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
One of the changes in #118332 was to let exceptions bubble up to the interpreter in case of error, to improve the experience while running the script locally. This turns out to have downgraded runbot reporting significantly as it doesn't account for stderr / log tracebacks if it got error-level (and possibly even warning-level) logs during the run. Hopefully get the best of both world (and shorten tracebacks slightly) by restoring `logging.exception` at the script level but triggering an abnormal exit for local CLI utility. closes #239995 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Fixes wrong author on portal users messages. task-5150607
Currently the PDF is not embedded into the XML files sent via Peppol. This commit fixes that. The PDF is embedded into the XML file at the point where the PDF is generated. It (re)uses the existing logic for other account EDI formats. opw-5405357 (among others) closes #240093 Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
This commit improves the UX by displaying more intuitive placeholders for the peppol identifier. The peppol information is also automatically verified when important data changes. It also adds a special case for Belgium in which we try to use the vat number as the peppol identifier with the company registry endpoint. back-port of: #233160 closes #240178 Task: 5172378 Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
The \_retrieve \_product() function relies on a query with multiple domains OR'ed together. As the search will require a LEFT JOIN with the product_template table, the use of OR in the query prevents Postgres from utilizing indexes. This becomes a problem in databases with a large number of products since a seq scan would be very slow. This commit changes the way this is done by performing separate queries instead of a single query with multiple conditions within an OR statement. Although this might seem a performance degradation, it actually allows these separate queries to utilize indexes and run much faster compared to the original approach. It also simplifies the priority logic and allows for faster early exits compared to the original one. This function is mainly used with EDI crons (such as PEPPOL where this problem was noticed), which could require hundreds of product searches as it does a search per invoice line. Benchmarks: Importing a peppol document of 173 invoice lines. | Num products | Num invoice lines | Before | After | | ------------ | ----------------- | -------- | ------- | | 864873 | 173 | 868.18 s | 19.43 s | | 397005 | 173 | 468.91 s | 20.68 s | | 8064 | 173 | 125.08 s | 20.1 s | | 564 | 173 | 119.9 s | 20.21 s | opw-5245007 closes #238853 Signed-off-by: Laurent Smet (las) <las@odoo.com>
The current call to `super()._get_proxy_identification()` was incorrect, because the parent method expects a 'company' argument. Steps to reproduce: - Configure an Italian company - Install l10n_it_edi - Attempt to set up Peppol This triggers: TypeError: AccountEdiFormat._get_proxy_identification() missing 1 required positional argument: 'company' The issue occurs following the addition of account_peppol, because before that, no other EDI format existed besides fattura_pa, so the condition in the if clause was never triggered. opw-5405602 closes #240680 Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Steps to reproduce: - Insert a icon in an empty paragraph. - Remove the inserted icon. - The paragraph becomes unreachable. Cause: - When a paragraph contains only an icon, removing that icon during the delete process does not trigger fillEmpty. As a result, the paragraph ends up with no content, leaving it empty and unreachable. Solution: - During the delete process, after the icon is removed, call the fillEmpty method. This ensures that if the block becomes empty, a <br> is inserted inside the paragraph, keeping it accessible. task-3540454 Part-of: #237891 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce - Insert an icon in an empty paragraph. - Place the cursor before the icon. - Press Enter. - Nothing happens. Cause - When the cursor is placed before a contenteditable=false element, getDeepRange sets the selection deep inside the non-editable element as a result, when Enter is pressed, the action is ignored because the selection is not in an editable context. Solution - Instead of setting the selection inside getDeepRange, set the selection after calling getDeepRange only if the returned range is not within a contenteditable=false element. task-3540454 closes #237891 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit: the document uploaded by /image cannot be downloaded on clicking. After this commit: we open a popover for document without the editing buttons. The user may download the document by clicking the link. Also the toolbar is hidden for attachments. task-3648796 closes #236705 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
There is a `for invoice in invoices_data.items()` loop. The var `invoices_data` is a dict (account_move -> invoice_data dict). But in the loop body we use the variables `invoice` as account_move and `invoice_data` as dict as if we did `for invoice, invoice_data in ...`. Thus there is a traceback ``` AttributeError: 'tuple' object has no attribute 'peppol_move_state' ``` It can easily be reproduced by setting the timeout in `_make_request` to `0.01`. task-None closes #242196 Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
20 participants
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.
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