[16.0] [REF] fields: related warning #90
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
`Environment.__new__` expects a Cursor. Ensure developers pass a Cursor and not another kind of unexpected object. Passing another object with the same attributes would work during the creation of the new environment, but then would fail later, when using the created environment with the wrong `cr` attribute, with a less comprehensive error. Task-3796479 closes odoo#80644 Signed-off-by: Raphael Collet <[email protected]>
Fix to avoid considering TS lines for projects linked to global time off closes odoo#156338 Signed-off-by: Xavier Bol (xbo) <[email protected]>
Previous fix: odoo#139013 added in the ability to handle a use case specific avoided due to its complexity and it being an edge case. I.e. the ability to do a Put in Pack in a batch picking where there is a shipping connector involved (i.e. when the `choose_delivery_package` wizard is opened). Because the ability to handle this situation is now added to stable, we have to sort of support it now and handle it not breaking other flows. Here are the flows that need to be handled (and were broken by the previous PR): [In all cases, "Packages" setting needs to be activated and each picking needs at least 1 move of a consumable/storable product] Flow 1: batch picking + put in pack for single picking - Create 2 pickings of any operation type - Create a new batch picking with these 2 pickings - Open 1 of those pickings directly (i.e. not in the batch) - Click on "Put in Pack" Expected result: Only the move from the open picking is put into a package Result before this commit: Both pickings have their moves put into the same package Additional notes: Because this is not an obvious bug, users may already had this bug occur in their DBs without realizing it === Flow 2: batch picking (or multi-record calling of `action_put_in_pack`) - Create 2 receipt pickings (or any picking where picking_type_id.show_reserved != False) - Create a new batch picking with these 2 pickings - Open batch picking + click "Put in Pack" Expected result: All moves in the batch are put into a package Result before this commit: Stack trace because self.immediate_transfer is a boolean and cannot be called for more than 2 records (i.e. breaks singleton check) Additional notes: In theory batch picking creation has checks to avoid batches where there are pickings with more than 1 picking type or have different `show_reserved` values, but because `_package_move_lines` is a method that can be called in different use cases (including multi-record pickings) via customizations/future code changes, we add in checks to prevent put in pack from finishing in those cases to avoid unexpected behavior/stack traces. I.e. remember to respect existing `self.ensure_one` checks since they're probably there for a reason. === Flow 3: batch picking w/pickings w/more than 1 delivery carriers (where none = a different carrier than having 1) - Create 2 delivery pickings with different `carrier_id` values (i.e. different shipping methods assigned to them) - Add both pickings to a batch - Click "Put in Pack" in the batch picking Expected result: None, we should not handle this case because if the products are in the same package then the same package info will be sent to both carriers and the user will be double charged for every move (or charged(/potentially create the wrong shipping documents) when it shouldn't be in case of no carrier for one of the pickings) Result before this commit: All moves are put in the same package and the double charging/potentially incorrect shipping documents will occur Additional notes: This is the use case that was intended to be avoided when flow was originally decided to not be handled closes odoo#156513 X-original-commit: d3ee7b9 Signed-off-by: Tiffany Chang (tic) <[email protected]>
During the copy of provider if the journal is set, it create a new account.payment.method.line, and if you change the company of the new provider you have an error when you try to create a new journal. closes odoo#149423 Signed-off-by: Quentin De Paoli <[email protected]>
closes odoo#154766 Signed-off-by: Florian Gilbert (flg) <[email protected]>
This commit is a backport of commit [1].
The changes happening in the header often break the history, because a
lot of them add steps in it while they should not be observed at all.
This results in losing the redo history, having to click multiple times
to undo one specific change or even seeing some intermediate states that
should not be appearing, every time we interact with the header (e.g. by
opening/closing a dropdown or a burger menu, resizing or scrolling the
window).
This commit fixes these history issues by not observing some problematic
changes:
- When we open/close a "burger" menu (i.e. the "Hamburger menu" or in
mobile view). It was adding a step in the history, so if we opened and
closed it in the middle of a redo, we would lose the remaining "redo".
- When the extra menu is added/adapted. When resizing the window, which
also means toggling the mobile view, if there is not enough space for
all the desktop menus to be visible, they are moved in an extra ("+")
menu (they are moved out when there is enough space). This resulted in
the intermediate state where the menus are not in the extra menu yet to
be visible when undoing at some point, which did not look good. It was
also adding a step in the history sometimes, so if we resized in the
middle of a redo, we would lose the remaining "redo".
- When hiding a dropdown by scrolling the page and hiding a hoverable
dropdown by clicking somewhere on the page. When they are hidden this
way, undoing the change that will be done after that would reopen the
dropdown, which could be annoying if the dropdown was a mega menu for
example.
- When showing a hoverable dropdown. This added a step in the history,
and since opening a "clickable" dropdown does not do it, this also
should not be the case for a hoverable one.
[1]: odoo@c32dfae
related to task-3609531
closes odoo#155989
X-original-commit: 586608a
Signed-off-by: Quentin Smetz (qsm) <[email protected]>
Complement on 1e35315 (odoo#112450): alongside the split between forwards and backwards jump we missed that 3.11 has a specialized version of each for the `is None` and `is not None` cases. A use of that was added in standard in 16.5 (odoo#120446) but more generally it makes sense that server actions would support conditional tests against `None`, probably... closes odoo#156438 Signed-off-by: Xavier Morel (xmo) <[email protected]>
In Luxembourg, during the year 2023, the VAT rates were decreased by 1% temporarily. Now that we are in 2024, we need to deactivate the taxes added previously. We will not remove them so that client can still use them if needed. closes odoo#156595 Task: 3635758 X-original-commit: eee565f Signed-off-by: Josse Colpaert <[email protected]> Signed-off-by: Maximilien La Barre (malb) <[email protected]>
The `course_publisher_standard` tour was missing slide (channel) tags. We are replacing values used in the tour so that the tour runs on the same data whether demo data is installed or not. See runbot build errors 55762 and 55768. Task-3744848 closes odoo#153926 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
This commit is a follow-up on [1] which fixed the caching of restricted editor which was accidentally shared with public users. It introduces a test that verifies that this fix is not lost. [1]: odoo@8218880 task-3482439 closes odoo#156479 Signed-off-by: Romain Derie (rde) <[email protected]>
…line for included EPD When configuring the payment term to include the EPD within the payment's journal entry on a customer invoice, the tax_tag_invert field got wrongly set as True. This was hardcoded in the code; computing the field in the regular way gives the proper value. OPW 3754446 closes odoo#156661 Signed-off-by: Laurent Smet (las) <[email protected]>
Before this commit: Coming from website to notes the toolbar contains animate text button. After this commit: The toolbar at notes should not contain animate text button. task-3565782 closes odoo#139692 Signed-off-by: David Monjoie (dmo) <[email protected]>
If the user has access to picking types as a stock manager without having access to pos config, deactivating a picking type triggers an AccessError on pos.config. closes odoo#154888 Signed-off-by: Joseph Caburnay (jcb) <[email protected]>
Don't try to keep extra params and co. Keep it simple... Else we should pop from request.params `forum` and `blog` keys because now they are converted as query param with the slug format: /forum/help-1/question-1?forum=forum.forum(1,)&question=forum.post(1,) closes odoo#156537 X-original-commit: 5739602 Signed-off-by: Jérémy Kersten <[email protected]>
The orm doesn't match monetary amounts using the related currency. It means, -208.73 != 208.730000000000002. Let's match the amount using an sql query instead. ticket_id: 3741689 closes odoo#156291 Signed-off-by: Olivier Colson (oco) <[email protected]>
The goal of the `def new` override on `account.payment` is to have the `journal_id` computed when creating a payment in the form view. The problem is that it is also called by the onchange when a field is modified. This is causing a bug: - Go the the cash journal and change the name of its payment methods (so you can distinct them from the ones of the bank journal). - create a payment (do not save) - switch the journal to "Cash" then switch back to "Bank". -> the "Payment Method" is still one from the "Cash" journal. The fix here is a hacky way of checking this is the call on the record creation. closes odoo#155710 Signed-off-by: William André (wan) <[email protected]>
Before this commit: Switching to RTL mode would inadvertently revert the domain picker, causing a disruption in the email format. The expected format is Alias@domain, but it was displaying as domain@alias. After this commit: Now, the domain picker remains intact in RTL mode, ensuring that the email format is correctly displayed as alias@domain. Task-3624012 closes odoo#154834 Related: odoo/enterprise#58251 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
orderpoint creation should also consider archived location while computing qty_available or else users will be faced with a `KeyError` closes odoo#155397 Signed-off-by: William Henrotin (whe) <[email protected]>
Step: * Create Bom A: product A - qty 1, bom line: product = Component X, qty = 20 * Create MO with Bom A and 1 produced_qty = 1: + on components: To Consume = 20, Consumed = 15 + Unbuild MO, check Unbuild, check Product Moves of Unbuild, check line product Component X has Quantity = 20, in fact quantity must = 15 closes odoo#152805 Signed-off-by: Quentin Wolfs (quwo) <[email protected]>
When mixing anglo-saxon accounting and multi-currency, it sometimes leads to incorrect AMLs in the stock-in account To reproduce the issue: (Company in USD) 1. Setup some currency rates: - Yesterday: 1000 EUR = 4335.1 USD - Today: 1000 EUR = 4348.0 USD 2. Create an auto-avco product 3. (Yesterday) Buy one product at 1000 EUR and receive it 4. Deliver the product 5. Bill the PO 6. Open the journal items of stock-in account Error: The AML for the exchange difference has been created twice When posting the bill, it leads to `_generate_price_difference_vals` where we generate AML/SVL in case of price differences. There, we also generate such records in case of exchange difference. This is what we do in the above use case. However, the AML is wrongly encoded, we need to respect some specific conditions: https://github.com/odoo/odoo/blob/d780a2fc73259244411329027349fad1cb353f34/addons/account/models/account_move_line.py#L1773-L1779 Otherwise, the reconciliation process won't work correctly and will generate its own AMLs for the exchange difference (hence the above error). On top of that, to ensure a full reconciliation, we need to first reconcile the exchange diff AML with the bill one. This is what we are supposed to do in `/stock_account`: we split all stock-in AMLs into three recordsets: `correction_amls`, `invoice_aml`, `stock_aml`. However, we don't correctly isolate the correction AMLs. Therefore, we try to reconcile all AMLs at once, which will not work. Note: This commit brings a behaviour change since the amount currency of exch-diff AML will now be zero, as it should (again, see the comment of the code quoted above in the reconciliation process). This also explains why this commit modifies an existing test: comparing the `balance` and the `amount_currency` of such AML is incorrect. OPW-3544318 closes odoo#155421 Signed-off-by: Arnold Moyaux (arm) <[email protected]>
Currently, when we color a list of links with more than three items in the list, only the first and last links are colored. Now when the li element is colored in a list, the font element is created inside the link. We also make sure when the font size is defined the font element is created inside so that the background color is aligned with the font size task-3677214 closes odoo#156573 X-original-commit: 082bb38 Signed-off-by: Geelen Sébastien (sge) <[email protected]> Signed-off-by: Jinjiu Liu (jili) <[email protected]>
Since [1], image options like "Filter" are kept when a user changes the position of an image in an "Image Gallery" snippet. [1] also adapted the `snippet_image_gallery` tour (moved in `snippet_image_gallery_reorder` from version 16) to test this behavior. To do so, the test adds a filter on an image in an "Image Gallery" snippet, checks that the filter is displayed on the editor panel, moves the image, clicks on it and finally checks that the filter is still displayed on the editor panel. The problem is that the steps that check if the filter is displayed on the editor panel are the same before and after the move of the image which means that the second check is true also before the move of the image. This situation is a typical case where an undeterministic error could happen. Indeed, we do not know if the second check tests an old value or an updated one. To solve the problem, the test has been adapted; after the move of the image, the test clicks somewhere else (on the footer in this case), and then back on the moved image to finally check that the filter is still displayed on the editor panel. The goal of the click on the footer is to be sure to have a loaded version of the editor panel. By doing so, we remove the risk of an undeterministic error situation where a condition is already true before an action is done. Note: this problem has been discovered because the test `snippet_image_gallery_reorder` succeeds on version 16.3 without the fix of [1]. Now, the adapted test fails on version 16.3 without the fix of [1]. [1]: odoo@0fd2477 task-3717041 closes odoo#156594 X-original-commit: 23fc59c Signed-off-by: Quentin Smetz (qsm) <[email protected]> Signed-off-by: Colin Louis (loco) <[email protected]>
Steps to reproduce: - Install the l10n_de package - Create and select a german company - Accounting > Configuration > Settings > Fiscal localization - Set: Deutscher Kontenplan SKR03 for the fiscal localization - Accounting > Configuration > Accounting > Fiscal Positions - Click on "Geschäftspartner EU (mit USt-ID)" (this fiscal position translates to "Business partner EU (with VAT ID)". Issue: The `vat_required` field of this fiscal position is False but sould be True as the fiscal position is "(with VAT id)". Cause of the issue: The `vat_required` field is a Boolean of the account.fiscal.position model without defaut value nor compute method. As such it is interpreted as "False" when unset (just like any unset python boolean). Since the `vat_required` field is not set in the data file of the `l10n_de_skr03` localization for the "Geschäftspartner EU (mit USt-ID)" fiscal position, it will be interpreted as False. Fix: We update the data file of the fiscal localization to the expected value opw-3721912 closes odoo#156652 X-original-commit: e608a92 Signed-off-by: Florian Gilbert (flg) <[email protected]> Signed-off-by: Lancelot Semal (lase) <[email protected]>
Steps to reproduce: - Install Accounting, Sales, eCommerce, Contacts - Go to Accounting settings and configure TaxCloud - Go to Sales settings and activate Delivery Methods - Go to Contacts and configure complete address (in US) and Fiscal Position to "TaxCloud" for a contact (e.g. Mitchell Admin) - Create/configure a shipping method: (e.g. Free delivery charges) * Provider: Fixed Price * Delivery Product: [Delivery_007] Free delivery charges * Fixed Price: $10 * Free if order amount is above Amount $101 - Configure the corresponding delivery products with a TaxCloud category (e.g. [11099] Postage/Delivery) - Create a product: (e.g. Product X) * Price: $100 * TaxCloud Category: [0] Uncategorized - Go to eCommerce with Mitchell Admin - Add Product X to cart - Process checkout Issue: On the payment page, the price with the taxes is above $101 but the delivery is not free. When accessing the payment page, the TaxCloud taxes are not computed yet and the delivery is defined based on the price without taxes. Solution: Compute the taxes during order confirmation before determining the delivery. opw-3696956 closes odoo#156880 X-original-commit: 8ca9a47 Related: odoo/enterprise#58255 Signed-off-by: Anh Thao Pham (pta) <[email protected]>
This commit prohibits the archival of a company if it is associated with a website. Otherwise, the website wouldn't be accessible anymore by public users (and so by all users if they need to login). Step to reproduce: - On website 2, change the company from SF to Chicago - In the website list view (in debug mode), reorder the websites so website 2 is the first one in the tree view - Archive the Chicago company (from debug > companies and do it from the list view) - Try to access the website/runbot from an incognito tab - It will show a raw 403 error Note that the companies can only be archives since Odoo 16, thanks to this commit: odoo@7d0996b opw-3749772 closes odoo#156470 Signed-off-by: Romain Derie (rde) <[email protected]>
Issue --> In `_onClickSaleOrder`, we load in the partner on the sale order using `load_new_partners()`. However, the search on the `res.partner` model made in this method has the potential to return every single `res.partner` record because of the domain that it uses --> https://github.com/odoo/odoo/blob/6c2dd5fbd9898f0efecdc35593af69bfd7d4eb50/addons/point_of_sale/static/src/js/models.js#L783-L785 After doing so, we check if the parter has been loaded and we grab the id using `get_partner_by_id`. If the partner is not loaded, we use `_loadPartners` to load them. Since we are already checking and reloading the partner on the sale order using `_loadPartners`, using `load_new_partners()` earlier is redundant. Solution --> Remove the try-catch block that loads multiple `res.partner` records during the process of clicking a sale order via POS. opw-3619941 closes odoo#156970 X-original-commit: 455081d Signed-off-by: Vlad Stroia (vlst) <[email protected]> Signed-off-by: Aditya Dasgupta (adda) <[email protected]>
The tooltip of leave allocation is changed to be more informative task-3762965 closes odoo#155350 Signed-off-by: Yannick Tivisse (yti) <[email protected]>
In Odoo, incoming contracts are defined as having state == 'draft' and kanban_state == 'done'. Currently, the employee contract calendars are synced when incoming contracts are created, and incoming contracts' calendars are changed. However, in many cases the incoming contracts are made for the future and do not reflect the current employee's working schedule. This causes there to be a calendar mismatch whenever incoming contracts are created/updated, despite being set only for the future. This fix checks the contracts_count field on the employee before syncing the calendar, since the only time an incoming contract should reflect the *current* calendar is if it's the only contract for the employee. closes odoo#139725 X-original-commit: 022de78 Signed-off-by: Bertrand Dossogne (bedo) <[email protected]>
BaseModel's sorted() has two problems: - It breaks the prefetch of self for no reason - When it is called without an argument, it filters out new records because the search() used in sorted() doesn't return new records. Keep the same prefetch as self to fix the first problem. We partially fix/support the second issue, we just avoid filtering out new records (but we don't actually sort them) closes odoo#156995 X-original-commit: 35da0a5 Signed-off-by: Rémy Voet (ryv) <[email protected]>
Since the action buttons are not field nodes, the 'invisible' attribute doesn't do anything. The only way to make them invisible is to have an 'invisible' key in attrs/modifiers. The 'states' attribute was removed, since ir_ui_view overwrites the 'invisible' item in the modifiers dict if 'states' exists in the node. closes odoo#147180 X-original-commit: d0b1974 Signed-off-by: Sofie Gvaladze (sgv) <[email protected]>
To reproduce: ============= - install `planning` and `pos_blackbox_be` modules - change Demo's Employee permissions from Administrator to nothing - connect as Demo and try to open planning application -> you will get an error Problem: ======== - the `pos_blackbox_be` module inherits from `hr_employee` and introduces a new field `insz_or_bis_number` which is not in `hr_employee_public`, the `_read` method of `hr_employee` tries to read this field from the `hr_employee_public` model and fails Solution: ========= as `hr` module expects that every field in `hr_employee` is also in `hr_employee_public` we need to add the `insz_or_bis_number` field to `hr_employee_public` model in `pos_blackbox_be`, however this module is a certified module and we cannot modify it, so a workaround is to remove the `insz_or_bis_number` field from the fields to read in the `read` method to prevent the error opw-3772735 closes odoo#157999 Signed-off-by: Joseph Caburnay (jcb) <[email protected]>
In the future, we might want to make most utils available in the non lazy JS bundle part. We are also considering moving the Bootstrap lib and some more in there. This commit is about moving the strict minimum to be able to improve the lazy loading behavior in stable: the DOM utils that allow to make async handlers and create button loading effects when we click on them. This also means that those utils were adapted to not use jQuery and other non available utils. Related to task-3770362 Part-of: odoo#158661
As a preparation for the upcoming improvements in the lazyloader, this moves the code around a bit. This will ease the review later. This also actually removes code that was totally useless in that moved code. Related to task-3770362 Part-of: odoo#158661
Odoo implements its own lazy-loading mechanism for the biggest JS bundles that are loaded on the frontend. This mechanism allows the page to appear to the user very fast, at the downside of having some interactive elements (such as buttons) have no effect during the lazy loading. In general, this is not a problem since: - Standard links and buttons work, only those with custom effects (a modal, a custom JS behavior, etc) have no effect. - The full loading should not take long anyway. - After the pages have been visited, everything should be in cache. However, in some cases (countries with poor internet connections), the experience can be confusing. Without lazy loading, they would have a page that appears as a blank white page for a few seconds. With our custom lazy loading, they get the website very fast... but some buttons appear buggy (no effect) for a few seconds. The long term plan is to review our lazy loading: - Should it be less delayed than it currently is? (at the time, this was the minimum delay that made Google give us good page scoring but it may not be as impacting as before) - Should some of the lazy-loaded JS should actually not be? - Should the assets be split differently? - Could we be able to remove some code that weighs too much? - ...? Meanwhile, this commit improves the behavior this way: during lazy loading, any click on a button is now ignored but a loading effect is displayed. Once the JS is fully loaded, the click is then re-played on the previously clicked button, hopefully triggering its effect. In any case, this cannot be worse than what we have before... except for: - The reasonable risk we take merging this in stable (we considered merging in a more recent version but it is needed for some specific projects and many websites would benefit from this improvement). - Any custom code that added behavior on buttons to be available during lazy loading... will just wait for lazy loading with a loading effect too now. This should be a good compromise as, again, that lazy loading is cached and should not take too long anyway. Note that this replaces the previous o_wait_lazy_js class behavior (it has now no effect). Overall: - This should not impact (neither improve nor worsen) most websites that are currently experienced from good internet connections. - This should be a big improvement for most websites that are currently experienced from bad internet connections. Related to task-3770362 closes odoo#158661 Signed-off-by: Romain Derie (rde) <[email protected]>
…incompatible icon image formats Replace the use of 't-esc' with 't-field' for the payment icon image in the icons list template. The latter, for an image field, provides two options for rendering the payment icon image: use the PIL library to obtain the image when given the option 'qweb_img_raw_data', or use a URL. The former only considers the first option, allowing only image formats compatible with the PIL library. closes odoo#158728 Signed-off-by: Antoine Vandevenne (anv) <[email protected]>
Steps to reproduce: - Remove all permissions to write/create/delete a view for the user "demo" - Open a view form with "demo" user Actual result: - View code is displayed in plain text and with formatting Expected result: - View code is displayed with formatting only - You can't edit the view or the translations opw-3776073 closes odoo#159216 Signed-off-by: Rémy Voet (ryv) <[email protected]>
Backport of original PR odoo#152655 in 17.0+ opw-3704715 Fixes odoo#151310 closes odoo#159305 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Related to previous commit: a9a9d2f From initial PR: 158843 Improve Regexp to match double slugs /blog/blog-1/post-2 or /blog/1/2 Ignore param order: `?a=<param>&b=<param>` == `?b=<param>&a=<param>` Remove trailing / from base url when querystring is present Ignore '/en' url instead of '/en_US' since the default url_code has been updated meanwhile (269aa59). Add a new test to check that urls are cleaned as expected Remove crawl as admin, since the demo user already have all groups and so we will check the same urls. The overlap is important for a really low value. closes odoo#159370 Signed-off-by: Romain Derie (rde) <[email protected]>
This traceback arises when the payment status is 404 A comma at the end is forgotten while creating a tuple with single record, which leads to a typeerror traceback. Error:- "TypeError: 'in <string>' requires string as left operand, not int" https://github.com/odoo/odoo/blob/7e3267fc69324a3c98d36983705a50420b5143f9/addons/payment_mercado_pago/const.py#L35-L39 sentry-5103720097 closes odoo#159433 Signed-off-by: Altaf Shaik (alsh) <[email protected]>
closes odoo#133266 Signed-off-by: Quentin De Paoli <[email protected]>
This commit's purpose is to display the correct currency for the hourly cost of employee in the project sol mapping. Currently, the currency displayed is the one of the sol instead of the currency of the employee. This is due to this commit:odoo@83760b9 We added a monetary widget, but we are feeding it the wrong id. After this commit, the correct currency is displayed closes odoo#154240 Signed-off-by: Xavier Bol (xbo) <[email protected]>
Versions -------- - 15.0 up to saas-16.4 Issue ----- Commit bdf8eb5 added the optional `extra_domain` argument to `_mail_find_partner_from_emails`, but used it it positionally as second argument (the `records` parameter), instead of named `extra_domain=extra_domain`. closes odoo#159353 X-original-commit: 631e2bb Signed-off-by: Thibault Delavallee (tde) <[email protected]> Signed-off-by: Levi Siuzdak <[email protected]>
… portal Steps to reproduce: - Open project share any project which has task. - My account > project > open that project you can see task . - Open any task and add new sub-task you can see once the sub-task is saved 'task view' button is displayed. Issue: - Sub-tasks notebook > add a line > 'view task' is displayed at the creation but is then hidden once the task is saved. Solution: - Correct the attrs and change the condition in able to invisible 'view task' once the sub-task is saved task-3602610 closes odoo#145214 Signed-off-by: Xavier Bol (xbo) <[email protected]>
closes odoo#159552 Signed-off-by: Valentin Chevalier <[email protected]>
… to url Currently, a logger exception is generated when the user tries to upload any image as document in the mass mail. This is because an UnidentifiedImageError occurs when the user uploads an image file as a document and code [1] tries to open it with Image. This commit adds code that handles an UnidentifiedImageError, and it adds the message in the log for an invalid image file. [1] - https://github.com/odoo/odoo/blob/029b84f3c061f819bacb9a4818504cced4adeb1c/addons/mass_mailing/models/mailing.py#L1405 sentry-4311184876 closes odoo#157513 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
When sending an SMS via the action from the sale order view (specifically with sale_subscription), it is possible to specify a number to send the SMS to. However, if the specified number is identical to the partner's number (the number of the sale order's customer), Odoo attempts to send the message twice, resulting in duplication. [This commit change] This commit addresses this issue by ensuring that additional numbers are skipped if they are the same as the partner's number. [Reproduce] - Install mass_mailing_sms, sale_management, and sale_subscription modules. - Add an SMS token to the IAP account. - Create a contact (C) with a valid phone number. - Create a new quotation with contact (C) as the partner. - Go to Actions > "Send an SMS Text Message" (requires the sale_subscription module). - Do not change the contact number on the pop-up (ensure it matches C's phone number exactly). - Bug: Odoo attempts to send two SMS messages, with the first being successful and the second resulting in an error. opw-3596207 closes odoo#153429 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Since [1], the `extraClass` is handled globally across all properties of a composite option such as "Border" or "Round Corners". But [2] did reset the `extraClass` each time `applyCSS` is called. Because of this, the `extraClass` is now missing after setting a "Border" or a "Round Corner". This commit reverts [2] partially to remove the `extraClass` handling from within the `applyCSS` function. Steps to reproduce: - Drop a "Text - Image" block. - Select the text. - Set a "Border". => The "Border" option is reset to 0. [1]: odoo@2a6355c [2]: odoo@d3c3dab task-3800288 closes odoo#159452 Signed-off-by: Robin Lejeune (role) <[email protected]>
Steps to Reproduce the Bug:
- Create a BoM:
- Product: P1, Quantity: 1 unit
- Component:
- C1, Quantity: 1 unit
- Create a MO to produce 10 units of P1:
- This requires 10 units of C1
- In draft state, split the quantity into 10
**Problem:**
The created MOs have component quantities of 0.1 instead of 1.
When the MO is split, we update the product quantity of the original MO
to 1, which triggers the `_compute_move_raw_ids` because it depends on
the product_qty of the MO. Therefore, the move will be updated to 1.
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1793
Subsequently, the factor is calculated based on the `move_qty` and the
`qty_initial` of the MO.
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1828
Factor = 1 / 10 = 0.1
Afterwards, this quantity is set on the original move and the backorder
moves:
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1830
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1835
opw-3825708
closes odoo#159492
Signed-off-by: William Henrotin (whe) <[email protected]>
Steps to reproduce: OS: Ubuntu 20.04.4 LTS with nautilus Browser: Google Chrome Version 123.0.6312.58 - type /file command in knowledge - select a folder and click on open - traceback occurs Before this commit: When a user attempts to upload a folder using /file command, the processing begins, but the folder is not actually uploaded because the `getDataURLFromFile` return promise which is not fulfiled. Additionally, there is no indication of any warnings or errors during the folder upload process. After this commit: If a user attempts to upload a folder instead of a file using the /file command, it results in a error message in toaster notification. task-3690847 closes odoo#151755 Signed-off-by: Damien Abeloos (abd) <[email protected]>
Test 'test_unpack_and_quants_history' may fail with error
```
ERROR: StockQuant.test_unpack_and_quants_history
Traceback (most recent call last):
File "/data/build/odoo/addons/stock/tests/test_quant.py", line 926, in test_unpack_and_quants_history
dst_location = stock_location.child_ids[0]
File "/data/build/odoo/odoo/models.py", line 6189, in __getitem__
return self.browse((self._ids[key],))
IndexError: tuple index out of range
```
closes odoo#159611
Signed-off-by: William Henrotin (whe) <[email protected]>
closes odoo#156175 Signed-off-by: Martin Trigaux (mat) <[email protected]>
Before this commit, it is not possible to export sale.report by excel or show the lines. closes odoo#157870 Signed-off-by: Victor Feyens (vfe) <[email protected]>
separate the true computation of the tax value from the computation of the base unit price (uom & curr conversion, ...). That way, the risks of unwanted side-effects is reduced when the base unit price is already computed (sale, website_sale). Also allows preprocessing the taxes mapping, which doesn't have to be done multiple times when we compute different amounts for the same product/template. Part-of: odoo#159122
Standard `sale` tax flows rely on `_get_tax_included_price_unit`, whereas part of `website_sale` flows do, while another part relies on `_fix_tax_included_price_company`, which doesn't handle some advanced cases (fiscal position mapping of price_included taxes). This commit drops the use of `_fix_tax_included_price_company` in website_sale, to only use the newest API of `_get_tax_included_price_unit`, supposed to handle more cases. Also makes all taxes computation go through a single entry point, `_apply_taxes_to_price`, already used for `combination_info` logic (/shop/product), but not in `_get_sales_prices` (/shop page). opw-3700803 closes odoo#159122 Signed-off-by: Laurent Smet (las) <[email protected]>
this commit fixes an issue introduced by odoo#154203 which could keep the autocomplete options list opened even after a click away when the user would "drag and drop" an option out of the list instead of simply clicking on it. This is caused by the fact that the onInputBlur code is directly terminated in this case (because of ignoreBlur) while it is the only way for the autocomplete list to be closed in this case. The solution is therefore to add an external listener on pointer down which will always close the autocomplete list when clicking away from it. Steps to reproduce: - go to any autocomplete (crm salesperson for example) - click on the input - drag and drop a result outside of the list - try to close the autocomplete list by clicking away Before the fix, the autocomplete list would only close by scrolling or clicking on the input once again. Part-of: odoo#159333
This commit fixes an issue regarding unwanted interaction between the regular autocomplete option click selection and the onChange handler from the input field hook used in the PartnerAutoCompleteCharField component. This became an issue starting from odoo#154203 because of the disappearance of the t-on-mousedown.prevent handler placed on the autocomplete options list which would prevent the onChange event from being triggered when clicking on an option. The issue would be that the onChange handler from the input field hook would take precedence over the option click handler of the autocomplete which would most of the time be ignored afterwards. The solution found for This problem is to prevent the immediate propagation of the change event in the autocomplete handler when an option has been clicked on so that it will never be propagated to the input field hook handler in this case. Steps to reproduce: - Go to contacts and open a company contact - Type in the name field a few characters (at least 3) - Click on any autocomplete option Most of the time, the option will not be applied and the name won't change closes odoo#159333 Signed-off-by: Aaron Bohy (aab) <[email protected]>
Activate "Reception Report" feature Create a SO for a storable product, confirm. Create a PO for the same product. Confirm the PO and check the delivery, open the "Allocation" report Assign the Product to the delivery of the SO. Go back to the PO and cancel the order, delivery of the SO will be cancelled. Issue: Currently the user cannot modify this behavior as the `propagate_cancel` checkbox is unaccessible opw-3733512 closes odoo#159646 X-original-commit: 91dba73 Signed-off-by: Quentin Wolfs (quwo) <[email protected]> Signed-off-by: Andrea Grazioso (agr) <[email protected]>
Currently, attempting to print an unconfirmed Saudi invoice in foreign currency results in an error. Furthermore, even if the invoice is confirmed, the exchange rate displayed is not correct, the rate of the confirmation date is used, instead of the accounting date. Steps to reproduce ------------------ * install `l10n_sa_edi` * switch to a Saudi company * create an invoice in a foreign currency. * without confirming the invoice, attempt to print it You should be met with a traceback: `Undefined Function: operator does not exist: date <= boolean` * confirm the invoice, ensuring the confirmation and invoice dates have different currency rates. * print the confirmed invoice.* print the invoice You should see that the printed rate does not align with the actual transaction amounts. Cause ----- The system incorrectly uses the `l10n_sa_confirmation_datetime` to calculate and display the currency rate on the PDF. This field is only populated upon invoice confirmation, leading to errors when printing unconfirmed invoices. Moreover, using this date for confirmed invoices results in displaying an incorrect rate, as it may differ from the `invoice_date`, which should be used for accurate rate calculations. opw-3731624 closes odoo#159627 X-original-commit: 67da943 Signed-off-by: Brice Bartoletti (bib) <[email protected]> Signed-off-by: Séna Serge Nshimiyimana (sesn) <[email protected]>
Before this commit: The `<br>` tags copied from external editing software's were remained unchanged. After this commit: Implement breaking element at <br> during HTML paste to adress unwanted <br> elements introduced by external editing software's or the OS. This ensures consistent and correct behaviour for all commands. Note that this change does not break `<li>`, `<blockquote>`, and `<pre>` elements. task-2936891 closes odoo#136743 Signed-off-by: David Monjoie (dmo) <[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.