[18.0][CHG] load product pricelist cache on product selection#249040#121
Open
[18.0][CHG] load product pricelist cache on product selection#249040#121
Conversation
benwillig
force-pushed
the
18.0-customer_pricelist_lazy_loading-bwi
branch
from
eb63730 to
d6a87c9
Compare
Before the addition of identification questions like "name", "email",
and "phone" in the commit [1] as event questions instead of having them
static, we could add custom data, such as fields for the address, with
static inputs in the form. After that addition, it's no longer possible
because the registration gives us the following error when trying to
convert data that isn't a M2o ID or an Integer value:
invalid literal for int() with base 10
By adding the check for the field's type, we can still add custom
fields with static fields in the template, as an alternative, given that
there's no question type for other fields.
The fix is needed to allow custom modules overrides.
[1]: odoo@6b8daa880c
closes odoo#244378
Signed-off-by: Noé Antoine (nan) <nan@odoo.com>
How to reproduce: - insert an odoo list in a spreadsheet - duplicate the list from the sidepanel - undo with Ctrl+z -> crash The command "DUPLICATE_ODOO_LIST" was not supported in the inverseCommand registry. Task-5943688 closes odoo#248969 Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
**Steps to reproduce:** - Go to Email Marketing app - Create a new mailing - Click on empty mail body and add only a Heading block - Set a subject, save it and click `Add to Templates` (favorites) - Create another mailing which use the first one as its template - Repeat the operation multiple times - Error will be raised at some point due to the depth of the template html **Issue:** Unnecessarily nested DIVs are created when using favorites to create new mailing.mailing records, if those favorites are themselves based on other favorites etc., which later can lead to a recursion error when rendering the template. **Fix:** Check if the template comes from the favorites to avoid reapplying the wrappers on it. This seems to be solved in 19.0 with the refactoring (odoo@354b8f6#diff-14a6d2cb740522696fcc7c950d0767ad23de989d621cca3bbbe24020d3f9c609) opw-5275187 closes odoo#238489 Signed-off-by: Julien Banken (jbn) <jbn@odoo.com>
Following rewrite in odoo/odoo@33206fd1941ae, this commit update passed props (`disabled` -> `isReadOnly`) to avoid a crash when creating a new forum post while being in debug mode: `OwlError: Invalid props for component 'WebsiteForumTagsWrapper': unknown key 'disabled'` closes odoo#244063 Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In PR odoo#233423, we rightfully removed `cert_reqs='CERT_NONE'` to enforce secure certificate validation during IoT handler downloads. However, this exposed a blind spot in Python's `urllib3` library on Windows. Because `urllib3` defaults to the host's underlying certificate list (which is limited on Windows) instead of the installed `certifi` package, Virtual IoT boxes get the following error during handler downloads: `certificate verify failed: unable to get local issuer certificate` This commit restores the broken flow while maintaining security by explicitly passing `certifi.where()` to the `urllib3.PoolManager` via the `ca_certs` parameter. opw-5902549 closes odoo#249271 X-original-commit: 521ee2b Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com> Signed-off-by: Maxime Orban (orma) <orma@odoo.com>
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. Steps to produce: * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty Sale Order Item Field Observed Behavior: * Sale Order is still linked to the task despite sale order line has been unlinked from that task. Root cause: * Compute method [1] only detaches the sale order if the customer has been changed. Solution: * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2]: https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 opw-5215989 closes odoo#249107 X-original-commit: 0ebe2ea Related: odoo/enterprise#107716 Signed-off-by: Maxime de Neuville (mane) <mane@odoo.com>
This commit prevents duplicate URLs for the same survey when fetched by bots/crawlers, improving SEO for public surveys. opw-5408587 Co-Authored-By: Denis Ledoux <dle@odoo.com>
We introduce a new model `pos.edi.xml.ubl_21` which can be inherited to build UBL 2.1 Invoice and CreditNote documents from a PoS order. This generates the UBL document using sensible default values taken from the PoS order but can also be inherited. This calls methods defined in the `account.edi.xml.ubl_21` model and so can be composed with models that inherit from `account.edi.xml.ubl_21`. task-4038651 Part-of: odoo#243844 Signed-off-by: Josse Colpaert (jco) <jco@odoo.com>
This commit adds support to JoFotara for pos.order model. task-4213323 closes odoo#243844 Signed-off-by: Josse Colpaert (jco) <jco@odoo.com>
The CIUS RO and CIUS HR depends on the BIS3 which is fundamentally incorrect. This was probably made out of lazyness to redefine things that are almost the same in both these CIUS and the BIS3. Now, in previous PR [1], we added contraints for the Peppol BIS 3 that are impacting those formats. Indeed, the EndpointID can be empty in the context of CIUS RO and CIUS HR. In particular, it's breaking the sending to physical person at the moment. [1]: odoo#246961 opw-5943698 closes odoo#249089 Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Followup to odoo#247151 after community report that if a test swizzles the model in the registry, looking models up by class leads to a lookup failure and a fallback to the default attributes set, and an almost certain mismatch as a result. Switching to a string lookup fixes the issue and doesn't seem to trigger any problem. closes odoo#249416 Related: odoo/enterprise#107905 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce: - Have facturae modules installed - Generate invoice with any amount - Send to Facturae Issue: Resulting XML has 8 digits after the decimal point on several fields, such as unit price, gross amount, and total cost. When trying to validate such an XML with e-Fact [1], this results in validation error: "RCF06001: En facturas emitidas en euros, alguno de los importes de las líneas tiene más de dos decimales (regla 6a del anexo II de la Orden HAP/1650/2015)." It occurs after 88b7ee6. Even if the TotalCost and GrossAmount have more digits in the xml, the file will be accepted by the fiscal entity only if the digits after the second one are all 0's. If any of the high precision digits is used, validation may fail. This commit partially revert changes introduced before because only UnitPriceWithoutTax can actually have more precision [1] https://efact.aoc.cat/bustia/validation/validateFile.htm opw-5927356 closes odoo#248882 Signed-off-by: Laurent Smet (las) <las@odoo.com>
Issue: --- In pick-up point list, the case formatting should be: 1- Pick-up point's `name`, `street` and `city` should not be auto-capitalized. 2- Weekdays should must be always capitalized regardless of language. Steps to reproduce: --- 1- Create a second Company named `store`. 2- Create a wh for the created company and add the wh to click-and-collect pick-up points. (There should be more than 1 pick-up points) 3- In the website, add Dutch lang. 4- In website, open a product and, open the `Click and Collect`. Outcome: --- Name is capitalized to `Store` and the days are not capitalized if you switch to dutch lang. Cause: --- Due to CLDR, luxon doesn't capitalize weekdays in some languages. opw-5941830 closes odoo#249078 Signed-off-by: Mohammadmahdi Alijani (malj) <malj@odoo.com>
Issue before this commit: ========================= When opening a Barcode Rule form view, a traceback was raised due to the following python expression: bool(parent.is_gs1_nomenclature or type == 'alias') Steps to Reproduce: ========================= - Install the stock module. - Go to Configuration → Barcode Nomenclatures in the Stock app. - Open any Barcode Nomenclature form. - Go to the Rules tab and open a rule (pop-up form view). - Click on the Expand button. - A traceback is raised. Cause of the issue: ========================= The form view tries to evaluate `parent.is_gs1_nomenclature`, but the `parent` record is not defined when the rule form view is opened directly (via expand), leading to a traceback. This happens because the form view is not defined as a child of any parent view, so no parent context is available, which leads to a traceback. With This Commit: ========================= Removed the usage of `parent.is_gs1_nomenclature` and use `is_gs1_nomenclature` directly instead. The `is_gs1_nomenclature` field on `barcode.rule` is already a related field to `barcode.nomenclature`, so it can be safely used without relying on the parent. opw-5949083 closes odoo#249293 Signed-off-by: Steve Van Essche <svs@odoo.com>
### Contains the following commits: odoo/o-spreadsheet@ce74496c9 [REL] 18.0.57 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) odoo/o-spreadsheet@43731776d [FIX] Evaluation: Provide cell position on single formula evaluation [Task: 5798610](https://www.odoo.com/odoo/2328/tasks/5798610) odoo/o-spreadsheet@979c0a365 [FIX] chart-panel: keep buttons visibles [Task: 5926661](https://www.odoo.com/odoo/2328/tasks/5926661) closes odoo#249571 Signed-off-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@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: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
If a company sell me something, they can send me an invoice. With KSeF, they do not have to send an invoice to me by post or mail - they can send it directly to KSeF. And it is legally delivered to me. Implement fetching bills from KSeF task-5405257 closes odoo#247812 Signed-off-by: Thomas Becquevort (thbe) <thbe@odoo.com>
Before this commit, when commercial_partner_id is on the view (possible with web_studio), the value by default is False. When the autocomplete widget is used, many fields could be autofilled and raise _onchange_verify_peppol_status, that requires this field. To avoid this issue we review that the value has been filled. Steps to Reproduce: 1. Open the Contacts app 2. Open Studio on the contact form view 3. Add the field commercial_partner_id to the form view (make it visible) 4. Create a new contact 5. Type a name 6. Select a suggestion from the IAP autocomplete 7. An error is raised immediately OPW-[5896847](https://www.odoo.com/odoo/action-4043/5896847) closes odoo#248895 Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com> Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com> Co-authored-by: Victor Miguel Armenta Carrillo <vmac@odoo.com>
Steps to reproduce: =================== 1. Install the website_project module 2. Go to website > contact us page 3. Set the form to "Create a task" 4. Submit a new task with description. 5. View the Description in the project app. -> The description field is already shown in the form by default. You will find another time it is repeated. Cause: ====== The default field content is always appended to the form content. Solution: ========= Avoid adding description to the description field content. opw-5868382 closes odoo#246952 Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
**Steps to reproduce:** * Install `Accounting` and `accounting_peppol` modules. * Create Belgium company. * Go to accounting settings and activate PEPPOL under `PEPPOL Electronic Invoicing`. * Create and post a customer invoice. * Click **Send & Print**. * Select only **Email** and click **Send** to generate the PDF. * Click **Send & Print** again. * Select only **Peppol** (partner configured for Peppol). * Click **Send**. **Observed behavior:** * The invoice is sent via **Peppol**, but the generated UBL XML does **not** contain the embedded PDF. * The receiver gets the XML data without the PDF representation. **Cause:** * When a PDF already exists on the invoice, the send flow skips the document post-processing step to avoid regenerating it. * The PDF embedding into the UBL XML relies on this post-processing step. * Sending via Peppol after emailing the invoice therefore bypasses the PDF embedding logic. **Fix:** * When sending via **Peppol**, detect if a PDF already exists on the invoice. * If so, explicitly post-process the UBL XML to embed the existing PDF before sending. * Ensures the PDF is always included in Peppol messages, regardless of when it was generated. opw-5495465 closes odoo#245901 Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
Context: When importing an XML invoice or vendor bill, the tax prediction was based on the customer’s invoice history. Example: if the imported invoice contains an item found in the history with two taxes (6% and 21%), the prediction would return both taxes (6% and 21%), even though only one tax is present in the XML file. The actual tax data present in the imported XML was not taken into account. After this commit, the prediction is more rigorous and correctly relies on the tax information provided in the XML (restricted search domain) task-5503126 closes odoo#249307 X-original-commit: 9cc26a1 Signed-off-by: Laurent Smet (las) <las@odoo.com>
…ustomer pricelist on selection
…one + dirty fix to check connectivity before loading the pricelist
…on order" This reverts commit 2da791d.
benwillig
force-pushed
the
18.0-customer_pricelist_lazy_loading-bwi
branch
from
d6a87c9 to
9550d89
Compare
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.