-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[16.0-irc] Update repo to latest changes from 16.0 #609
Merged
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
Before this commit, when a time off request based on extra hours was set to draft, a new overtime record with negative duration was created. This commit makes sure that the record is only created when the time off request is in the state confirm or validate. task-4096548 closes odoo#185962 Signed-off-by: Yannick Tivisse (yti) <[email protected]>
… for xrechnung Steps to reproduce: - Install Accounting and l10n_de - Switch to a German company - Configure the customer invoice journal to enable "XRechnung UBL (Germany)" - Create a German contact: * with a complete address * with an email address * without a VAT number - Create an invoice for the created contact - Confirm the invoice - Generate the electronic invoice - Validate the generated XML on an online XRechnung ValidationError Issue: The XRechnung (UBL Invoice) is not valid because the buyer electronic address is missing (cbc:EndpointID). Cause: <cbc:EndpointID> gets its value from contact's VAT, but the contact has no VAT. Solution: Since XRechnung 3.0.1, the email address can be used as electronic address with "EM" as schemeID. So, fallback on email address if contact has no VAT. Reference: https://www.e-rechnung-bund.de/standard-xrechnung-3-0-1/ https://blog.seeburger.com/xrechnung-version-3-0-1-comes-into-force-on-february-1-2024/ https://erechnungsvalidator.service-bw.de/ opw-4261026 closes odoo#189183 Signed-off-by: Florian Gilbert (flg) <[email protected]>
The issue: Starting with version 17.4, the Odoo banner displaying the invoice name on original bills is only added if the attached PDF uses US Letter paper size and is oriented vertically. How to reproduce the issue: -Upload any invoice with a non-standard format -Print -> Original Bills Explanation: Since saas-16.0, the PyPDF2 library version was allowed compatibility from 1.26.0 to 2.12.1. In version 1.26.0, the canvas dimensions were automatically adjusted when merging with non-standard page sizes. However, in version 2.12.1, this behavior no longer occurs, resulting in the banner not appearing correctly on non-standard formats. opw-4278031 closes odoo#186947 Signed-off-by: Xavier Morel (xmo) <[email protected]>
Versions -------- - 16.0+ Steps (18.0+) ------------- 1. Enable credit limits via Accounting settings; 2. log in as a user with access to Sales but not Accounting; 3. create a Sales Order; 4. add a product. Issue ----- Access Error. Cause ----- Commit de302c2 changed the way company dependent fields are handled. Instead of computing them via `_compute_company_dependent`, they are now stored in the database. Before this this change, any `groups` restriction added to a field wasn't actually checked. After this change, it does get checked, leading to the access error. Solution -------- 1. Use `sudo` to access `partner_id.credit`. 2. When calling the `_build_credit_warning_message`, pass the sales order with `sudo`. opw-4367393 closes odoo#189209 Signed-off-by: Levi Siuzdak <[email protected]>
* STEP TO REPRODUCE: try to _message_log on a channel contain record link (an a tag with data-oe-model and data-oe-link) then click on it -> nothing happen * REASON: when _message_log in mail.channel, it will consider that message as a NotificationMessageView model and we do not have onClick for it unlike MessageView model * SOLUTION: implement onClick for messaging, if any error come up with onClick then we can quickly fix at this method in messaging closes odoo#188380 Signed-off-by: Alexandre Kühn (aku) <[email protected]>
Versions -------- - 16.0+ Steps ----- 1. Activate a second language; 2. create a new quotation template; 3. add a note & save change; 4. add a translation for the note & save change; 5. create a new sales order; 6. select the created quotation template; 7. set customer to a partner using the second language. Issue ----- The note is still displayed in English. Cause ----- The translation is saved on the `sale.order.template.line` model, so it has to get fetched from there. Currently there is no logic in place to do this when changing the customer. Solution -------- Add an `onchange` method which reloads the template if no lines were added or removed. opw-4260006 closes odoo#188038 Signed-off-by: Levi Siuzdak <[email protected]>
Steps: - Install CRM - Open Settings/CRM - "Rule-Based Assignment" is disabled - Go to open the scheduled action: "CRM: Lead Assignment" - No interval type defined - Enable it Other flow: - Install CRM - Open Settings/CRM - Enable "Rule-Based Assignment" Repeatedly - Go to open the scheduled action: "CRM: Lead Assignment" - Change the interval to nothing Actual result: - Scheduled actions will not run anymore - KeyError: None - interval = _intervalTypes[job['interval_type']](job['interval_number']) - Other cron will not run due to previous error Expected result: - You cannot enable a scheduled action without an interval_type defined opw-4370139 opw-4318230 closes odoo#189684 Signed-off-by: Rémy Voet (ryv) <[email protected]>
…requests - Created a new module `l10n_mt_pos` to provide a compliance letter required by Maltese businesses for requesting an EXO number. - Automatically installs for Malta by default. - Added a menu item under "Reporting" > "Compliance Letter" to allow users to download the document. Task ID: 4373339 closes odoo#189640 Signed-off-by: Joseph Caburnay (jcb) <[email protected]>
Before, when using reconcile models that wanted to match invoice/bills to statement based on the Label and/or Note and/or Reference, if there is no real match with the statement label, the bank reco model would mount/suggest another entry from the same partner. This is misleading as we expect to be suggested with lines that actually match with the statement, as stated in the reconciliation model. Now, if any of the Invoices/bills matching rule is toggled, it will suggest *only* matching amls. If no rule is toggled, it will behave like before (mounting a match if any, or an aml from the same partner). task-4194671 closes odoo#181620 Related: odoo/enterprise#70785 Signed-off-by: Laurent Smet (las) <[email protected]>
* STEP TO REPRODUCE: In Form view Michelle Admin create a private event with attendee not inlcude him, then he forgot that he need to attend that too but no 'Edit' button appear in calendar popover. * REASON: In order to display the Edit button for private event , user need to be in attendees list * SOLUTION: This commit fix that by allow organizer to do the same thing , can edit and delete the event closes odoo#189840 Signed-off-by: Arnaud Joset (arj) <[email protected]>
**Current behavior:** Enabling the "Display Lots & Serial Numbers on Delivery Slips" setting, then creating an RFQ for a product with lot/SN tracking and a reference (`default_code`) + receiving the product, and finally printing the delivery slip will result in the product display name appearing twice on the delivery slip. **Expected behavior:** One time, the name. **Steps to reproduce:** 1. Enable "Display Lots & Serial Numbers on Delivery Slips" 2. Create a SN/Lot tracked product with a reference 3. Create a purchase order, confirm and receive the product 4. On the receipt, click the `Print` button -> 2x name **Cause of the issue:** `description != move_line.product_id.name">` Won't ever be true if there is a reference, as the description at this point is like: `product_id.default_code + product_id.name` **Fix:** Compare description to the `display_name` which will include this kind of extra stuff. opw-4165301 closes odoo#188078 Signed-off-by: Tiffany Chang (tic) <[email protected]>
**Current behavior:** When computing the total cost for a kit product in a POS order, extra stock moves are included if another POS order line has a product that shares the same components. This results in an incorrect total cost displayed on the POS order, which does not match the computed price from the BOM shown on the product page. **Expected behavior:** The total cost for the POS order should match the computed BOM price shown on the product page. **Steps to reproduce:** 1. Create two products: Product 1 and Product 2. 2. Set both products to be tracked by "quantity" or make them "storable" and assign them to a product category with "average cost" as the costing method (instead of "standard price"). 3. Create a Bill of Materials for each product, ensuring they share at least one component. Make sure BoM Type is 'kit' - Tip: For better visibility of the error, assign a quantity of 10 or more to the shared component in Product 2's BOM, and set the shared component’s `standard_price` (cost) to 5 or higher. This will make the discrepancy in the total cost more apparent. 4. Create the shared component as a new product and assign it a price. 5. Open a new POS order, add Product 1 and Product 2, and close the order. 6. Locate the order and observe that the "total cost" is incorrect. **Cause of the issue:** The stock move filter does not consider that stock moves for BOM lines need to belong to the current product. As a result, if two kit products share components, the stock moves for one product are mistakenly included in the calculation for the other, leading to an incorrect total cost. **Fix:** When filtering out the stock moves, ensure they are correctly associated with the current product by verifying that each stock move’s BOM line belongs specifically to the current product and does not include nested BOMs. opw-4274532 closes odoo#187130 Signed-off-by: Joseph Caburnay (jcb) <[email protected]>
…anges In previous commit [1], we made changes to handle better the invoicing address partner and the commercial partner. This broke facturx constraints. [1]: odoo@053c6de task-no closes odoo#189907 Signed-off-by: Laurent Smet (las) <[email protected]>
It is necessary to check that the cursor used to create the instance of the environment is an instance of `BaseCursor` directly at the start of the method (in order to be sure to check it before its first use). Task-4268673
When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input using 'email_split(_and_format)', which finds emails but do not format them. This leads to incoherent behavior as most emails are normalized as we generally always use partners, but not all. In this commit we now split, normalize and format email_to and email_cc in outgoing emails. This fixes a first issue where name are lost if a formatted email was entered in email_cc field. Only address was kept, now the name is correctly found and put back. This also fixes an issue for validated email detection, in order to compare normalized emails. This was introduced at odoo#185793 and may skip valid emails entered in email_to or email_cc. This commit backports a tool introduced at odoo/odoo@dd4709e which aims at allowing a quick convert from a string holding emails to a list of nicely formatted emails, using normalize version of email addresses. This is the standard we use in most flows. Task-4376876 Followup of task-3704658 Part-of: odoo#189409 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Due to history reasons, input given when inviting users is parsed in a simple way. However this create issues, notably because Odoo heavily relies on normalized emails. We therefore use the same heuristics as when creating partners given a potentially formatted input. Task-4376876 Followup of task-3704658 closes odoo#189409 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
When in preview mode (connected as a website editor) and a modal is open in the preview, pressing escape hides both the modal and the top menu bar. We want to prevent that. Steps to reproduce: 1. Connect as Admin and go on the website homepage 2. Edit the page, add a popup and save 3. Make sure to be in preview mode 4. Wait for the popup to show. 5. Click on it (just to be sure it's focused) 6. Press escape task-4351982 closes odoo#188085 Signed-off-by: Benjamin Vray (bvr) <[email protected]>
Any computed fields that depend on `customer_rank` or `supplier_rank` were not being recomputed when the ranks changed. This isn't noticeable on standard Odoo code, but downstream modules that use such feature wouldn't work. @moduon MT-8208 closes odoo#189127 Signed-off-by: Florian Gilbert (flg) <[email protected]>
**Problem**: In the Marketing module, when adding an image and attempting to center it, the centering action does not work because the action is not applying any style to the image. **Solution**: Use the same actions as those implemented in `web_editor` to apply the appropriate styles for centering the image: https://github.com/odoo/odoo/blob/175fdc14769e530424c3b0e364a4c3495aa499d3/addons/web_editor/views/snippets.xml#L600-L602 **Steps to reproduce**: 1. Go to *Email Marketing* and open any template. 2. Add an image and resize it. 3. Change the alignment of the image to center. 4. Observe that nothing happens and the image is not centered. opw-4348923 closes odoo#189413 Signed-off-by: Damien Abeloos (abd) <[email protected]>
Use case: - Create +100 project tags (e.g. 200). - Go to a task and in the Tags field click on Search more - The new window should show all records TT52091 closes odoo#189698 Signed-off-by: Xavier Bol (xbo) <[email protected]>
Trapping the focus in modal dialogs and refocusing the last focused element when closing the dialog are requirements from the WCAG. It was not done up to now for popup snippets in the website. As popups without backdrop aren't dialogs (they don't prevent interacting with the rest of the page), we don't trap the focus in these. Steps to reproduce (Chrome/Firefox): - Drop a popup and save - Wait for the popup to appear - Use tab / shift + tab to navigate around the page => Without the fix, you're able to focus elements outside of the popup. task-4256274 closes odoo#183558 Signed-off-by: Serge Bayet (seba) <[email protected]>
Versions -------- - 16.0+ Steps ----- 1. Run `test_reload_template_translations` without demo data. Issue ----- > AssertionError: sale_order_template_id was not found in the view Cause ----- The `sale_order_template_id` field requires the user to have the `sale_management.group_sale_order_template` group, which they don't have by default without demo data. Solution -------- Add the group to the current user before running the test. opw-4260006 closes odoo#190031 Signed-off-by: Victor Feyens (vfe) <[email protected]>
Incorporate Eduardo Martinez (emtz10) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr closes odoo#190149 Signed-off-by: Martin Trigaux (mat) <[email protected]>
Previously, the fields in the calendar popover were misaligned. This fix ensures proper alignment of the fields. Task-4315829 closes odoo#188757 Signed-off-by: Aaron Bohy (aab) <[email protected]>
Steps to reproduce: 1. Add a stored computed field on `res.users` that depends on `groups_id` 2. Add a constraint on `res.users` that depends on `groups_id` 3. Give the user a group 4. Modify the given group and add an implied group Result: - The computed field is not recomputed - The constraint is not checked The reason for this is that the users groups are updated with a raw SQL query, and the ORM is not aware of the changes. This is a regression since 5f12e24. This issue was partially detected and fixed in 459e6dc, but only for a single constraint. This commit makes sure that the ORM properly propagates the changes to computed fields and all constraints, not just the one that was explicitly checked. closes odoo#177301 Signed-off-by: Raphael Collet <[email protected]>
The last update on Mexican banks was five years ago. Since then, several new banks have emerged, while others have closed. opw-4327242 closes odoo#189387 Signed-off-by: Laurent Smet (las) <[email protected]>
Problem: A loyalty rewards points member don't receive their points for their confirmed order if they don't sign into their account when signing their quotation online from a link they received in their email. This bug only occurs if the quotation is set to "online signature" only. The bug is not reproducible when the quotation is set to both "online signature" and "online payment" or if website_sale_loyalty is not installed. Purpose: It is expected that customers should receive their reward points for their order without needing to sign in because they accessed the link to sign the quotation from their email. It should be consistent with the behavior exhibited from having "online payment" set for the quotation or without website_sale_loyalty installed. Steps to Reproduce on Runbot: 1. Install Sales app, website_sale_loyalty, loyalty, sale_loyalty 2. Create a loyalty program that reward points based on orders 3. Create a quotation for a partner, set "online signature" in Other info, and click "Send by email" 4. Access the email in Settings > Technical > Emails 5. Copy the "Accept & sign" link and paste into incognito window 6. Sign the quote as a public user 7. Observe that the loyalty card for the partner did not update the points opw-4205826 closes odoo#182545 Signed-off-by: Mylyna Hy (myhy) <[email protected]>
Accounting group is such a big permission when the only need is to record basic cash operations. This reverts commit 47ac97f. Part-of: odoo#188798 Signed-off-by: Vlad Stroia (vlst) <[email protected]>
It's usual to have point of sale users with bare permissions. In any case, those users need to reflect the cash operations they make without the need of elevated accounting permissions. closes odoo#188798 Signed-off-by: Vlad Stroia (vlst) <[email protected]>
Steps to reproduce: - Install "l10n_ch" and switch to a Swiss company - Create an invoice for a Swiss partner - Send it - The QR code appears in the generated PDF Cause: The bank eligibility is not checked when printing the QR code. Solution: If the fiscal_country is not Switzerland then we check the account validity. A valid account is an IBAN account of this type type CHXX 3000 0XXX XXXX with the number in the middle being between 30000 and 31999. opw-4380520 closes odoo#194421 Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <[email protected]>
Before this commit: - The 'disabled' attribute does not work on buttons in a form view arch, As a result, The button remained enabled even when the disabled attribute was applied. After this commit: - We can now disable a button after simply adding the `disabled` attribute on it. Part-of: odoo#190323 Signed-off-by: Aaron Bohy (aab) <[email protected]>
Currently, an error occurs when users press the data-hotkey 'ALT + Q' to split expense and any expense is not available in the split expense line. Step to produce: - Install the 'hr_expense' module. - Create an expense, add a category, and click on the 'Split Expense' button. - Delete all expenses from the split expense line, and press the data-hotkey 'ALT + Q' to click on the 'Split Expense' button to split expenses. IndexError: tuple index out of range This occurs because the system attempts to access the first expense from the split expense line [1], but expenses are not available. Link [1]: https://github.com/odoo/odoo/blob/280b762e7cd1b3d9a578bbae60cbb9b137ee5ce5/addons/hr_expense/wizard/hr_expense_split_wizard.py#L36 To resolve this issue, Disable a 'Split Expense' button after simply adding a `disabled` attribute on it. Sentry-6015854429 closes odoo#190323 Signed-off-by: Aaron Bohy (aab) <[email protected]>
To reproduce: ============= - create an event on calendar with description containing html - on calendar view, click on the event to open the popover and hover on the description field -> the tooltip is displayed with raw html content Fix: ==== hide the tooltip on html fields in calendar popover as it's not needed opw-4356581 closes odoo#192104 Signed-off-by: Aaron Bohy (aab) <[email protected]>
We update quote detection for gmail and outlook: - gmail has simple wrapper divs with explicit classes - outlook has a mix of div ids and simple pattern-based quoting (everything under "<hr><div id="divRplyFwdMsg"/> seems to be considered a quote) Previously gmail just used blockquote, which still works but does not capture "On xx:xx:xx X <[email protected]> wrote:" headers, which are caught for outlook. Previously outlook had a wrapper div around divRplyFwdMsg which would set data-o-mail-quote-container on it, and propagate to children. However it seems that outer div was either removed or is not always present, a heuristic is thus needed. task-4381505 Part-of: odoo#192875 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Blank spaces following a quoted node should also be quoted. This avoids having long trailing spaces below a signature and having unquoted blank spaces between two quoted blocks task-4381505 Part-of: odoo#192875 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
We update quote detection for gmail and outlook: - gmail has simple wrapper divs with explicit classes - outlook has a mix of div ids and simple pattern-based quoting (everything under "<hr><div id="divRplyFwdMsg"/> seems to be considered a quote) Previously gmail just used blockquote, which still works but does not capture "On xx:xx:xx X <[email protected]> wrote:" headers, which are caught for outlook. Previously outlook had a wrapper div around divRplyFwdMsg which would set data-o-mail-quote-container on it, and propagate to children. However it seems that outer div was either removed or is not always present, a heuristic is thus needed. task-4381505 closes odoo#192875 Signed-off-by: Thibault Delavallee (tde) <[email protected]>
Before this commit, it could happen that the autocomplete does not find the option to select. Now, we give the option to select so we're sure that the option exists when we select it. runbot errors: 5759, 102534, 111418 closes odoo#124584 Signed-off-by: Julien Carion (juca) <[email protected]>
**Problem**: The cropper buttons are positioned at the end of the page instead of directly under the image being cropped. **Solution**: Remove `position: fixed` from the buttons container, allowing it to be positioned just below the image being cropped/edited. **Steps to Reproduce**: 1. Navigate to Email Marketing > Start from scratch. 2. Add "Blocks" > "Body" > "Columns". 3. Open the cropping tool on the first image. 4. Observe that the cropping buttons appear at the end of the page, requiring scrolling to access them. opw-4461565 closes odoo#193016 Signed-off-by: David Monjoie (dmo) <[email protected]>
closes odoo#194670 Signed-off-by: Josse Colpaert (jco) <[email protected]>
Adds a configuration that can be used to mitigate PostgreSQL transactional errors with long-living connections and the `LISTEN/NOTIFY`[1] functionality by re-establishing the database connection periodically. In the case that a connection outlives the transaction wraparound[2] mechanism of postgres, the `LISTEN/NOTIFY` internal queue might contain references to transactions that have already been deleted by the system's (or a manual) `VACUUM`[3] as it has its own transaction validity mechanisms (roughly comparing transaction ids). This can be reproduced by: - Triggering a wraparound _AND_ cleaning of pg_xact between the cron's `LISTEN` + `COMMIT` and its recyling. - Having done at least one `NOTIFY` during that time period (?). - Try to `LISTEN` to the same channel on the same database (transaction id must be < than the first connection's transaction id). The following is an example error message: ``` ERROR database odoo.service.server: Worker (3194772) Exception occurred, exiting... Traceback (most recent call last): File "/home/user/odoo/service/server.py", line 1089, in run self.start() File "/home/user/odoo/service/server.py", line 1235, in start self.dbcursor.commit() File "/home/user/odoo/sql_db.py", line 480, in commit result = self._cnx.commit() ^^^^^^^^^^^^^^^^^^ psycopg2.errors.UndefinedFile: could not access status of transaction 1194816979 DETAIL: Could not open file "pg_xact/0473": No such file or directory. ``` [1: LISTEN/NOTIFY](https://www.postgresql.org/docs/current/sql-notify.html) [2: wraparound](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND) [3: VACUUM](https://www.postgresql.org/docs/17/sql-vacuum.html) [LISTEN/NOTIFY code](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c) [Connection being kept](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c#L2167-L2191) [See more](https://www.postgresql.org/message-id/flat/VE1PR03MB531295B1BDCFE422441B15FD92499%40VE1PR03MB5312.eurprd03.prod.outlook.com#7e36d1fdca921b5292e92c7017984ffa) closes odoo#194141 Related: odoo/documentation#11779 Signed-off-by: Julien Castiaux (juc) <[email protected]>
…quests Steps to Reproduce: • Install the Time Off app. • Create a new user and corresponding employee without any group in Time Off. • Create a new time off request with a start date < today's date. • Attempt to change the date, which results in a validation error. Issue: - Users are unable to modify time off requests, even if they are not yet approved. Fix: - Added a check to ensure that modifications are allowed for time off requests that are not in an approved state. task-4236572 closes odoo#190944 Signed-off-by: Yannick Tivisse (yti) <[email protected]>
Problem: When printing an invoice with l10n_cl installed, the tax total will display the lavel as 'VAT.' The user expects 'VAT' to be translated to maybe 'IVA.' It is hardcoded into the view, thus the .pot file needs to be updated. Note: Starting from v17, there are missing translations for strings "Net Amount", "Total", "Exempt Amount" in the .pot file for the view l10n_cl.tax_totals_widget. However, these are present for v16. Will probably need to modify the fw-ports to include these strings in the file. Purpose: Updating the .pot file to include the hardcoded VAT string will ensure there are translations for that label. Steps to Reproduce on Runbot: 1. Install l10n_cl and Accounting 2. Add Spanish as a language 3. Switch to the CL company 4. Create an invoice for a customer whose language is Spanish 5. Print the invoice and notice 'VAT' is not translated opw-4383092 closes odoo#190605 Signed-off-by: Antoine Dupuis (andu) <[email protected]>
Before this commit, if a gift card was created in another company and the gift card program was not assigned to any company, using the gift card in another company resulted in an error. opw-4422730 closes odoo#192246 Signed-off-by: Joseph Caburnay (jcb) <[email protected]>
Steps: - Install sale app. - Enable Loyalty settings. - Try to create a card on a loyalty. Issue: - Giving validation error. Casue: - In [PR] forgot to check expiration_date set or not before raise an error. Fix: - Added condition to check if expiration_date set or not on card before raising an error. [PR]: odoo#171453 opw-4492179 opw-4490587 opw-4504188 opw-4495530 closes odoo#194785 Signed-off-by: Morgane Demesmaeker <[email protected]>
Issue: - The negative values in Vendor Bills are not being reflected in the Analytic Account linked to a project. - the negative value does not reduce the project’s total cost in the Analytic Report cost calculations. Steps to reproduce: - Create a project and set an analytic account or use the "Renovations" project. - Create a vendor bill. - On the VB add two lines one with a positive Price and the other with a negative Price. - on `Analytic` of each line set the project to `Renovations` or the project you created. - Validate the vendor bill. - Go to the project app and click on the 3 dots of the project you choose and click on `Project Updates`. - Notice the total cost of the project is not reflecting the negative value of the vendor bill. Solution: - The issue is caused by the condition ('price_subtotal', '>', 0) in the query for account.move.line. Removing this condition ensures both positive and negative price_subtotal values are included. opw-4416931 closes odoo#194300 Signed-off-by: Xavier Bol (xbo) <[email protected]>
In error_service, event.preventDefault() is required to prevent uncaught error message due to latest Chrome version (132) compatibility. closes odoo#194795 Signed-off-by: Aaron Bohy (aab) <[email protected]>
Since commit [1], we added a selector using the ":has" pseudo-class in the template that defines where "inner content" blocks can be dropped. It is no longer possible to enter edit mode (a traceback occurs) starting from Odoo version 18.0 and in browsers older than Chrome 112 or Firefox 121. This bug happens because the same selector, used by jQuery, combines both the ":has" pseudo-class and the ":is" pseudo-class (this ":is" pseudo-class was introduced into the same selector by commit [2] starting from Odoo version 18.0). This is not compatible with the older browsers mentioned above. The bug only appears in version 18. However, we already fixed this in 16.0 in case potential customizations had added the ":is" pseudo-class to the same selector. [1]: odoo@65a8500 [2]: odoo@e0fc837 opw-4494945 closes odoo#194676 Signed-off-by: Quentin Smetz (qsm) <[email protected]>
Before: The typofix feature treats terms in the old and new values with similar text content as the same term, migrating the translations of the old term to the new term. For example The old value has the mapping: 'Draft': 'Brouillon' The new value contains the term: '<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>' Since the old term and the new term share the same text content, 'Draft', after `write`, the new term reuses the old translation of 'Draft'. However, the translation 'Brouillon' is always visible, unlike its en_US counterpart. This behavior is acceptable in non-upgrade mode because the user writes the en_US value and is responsible for verifying translations afterward. However, it is problematic during upgrades because users cannot easily identify which records have changed and need to be rechecked. After: The translation inheritance behavior can be described as below Translations can be inherited after `write` from old terms to new terms which share the very close text contents 1. when `write` in production mode, text contents for translation terms are more important than the HTML/XML structures of them, and the old term translations should be remained as much as possible. Because * the writing user is responsible to recheck all translations after `write`. * it is easier for the writing user to copy technical HTML/XML structures than translate text contents for a language they may not know. * the feature can also be used as typofix when the only small diff is the text content 2. when `write` in upgrade time, the HTML/XML structure is more important than the text content, and the new term structure should be remained as much as possible. Because * HTML/XML structures might be changed a lot after upgrade, which may contain behavior relevant diff (e.g. `invisible`), even if text contents are not changed. * users have no idea which records' values are changed during upgrade and are hard to recheck their translations. * new terms are highly likely to be correctly translated in the latest po files which will be imported during upgrade. * the typofix feature can still be remained when the only small diff is the text content Based on the above feature analysis, we use the below new strategy 1. translations can be inherited only if the old source term and the new source term share the same HTML/XML structure 2. translations can be inherited only if the old translation term and the new source term share the same HTML/XML structure 3. when translations are inherited, MODIFIER_ATTRS will be synchronized with the new source term, other attributes will be copied from the source term if available. closes odoo#194186 Backward-port-of: odoo#194181 Backward-port-of: odoo#150152 Signed-off-by: Raphael Collet <[email protected]>
…on AMLs **Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entries which have simply not been posted yet. Reconciliation should be deferred until these moves are no longer in draft. **Steps to reproduce:** 1. Activate another currency, define some rate for today and another (different) rate for tomorrow 2. Create a product with FIFO and real-time costing & valuation 3. Create an initial purchase for the product, receive then bill normally 4. Create another purchase order and receive the product 5. Create the invoice, set the invoie date for tomorrow 6. Post the invoice -> Open the `Exchange Difference` journal to see the entries which should not have been generated **Cause of the issue:** After creating the AMLs which represent the difference in reception/bill unit price of the product, they are caught here: https://github.com/odoo/odoo/blob/971400771a31c05641a8672f6b1d85afaa9c4a19/addons/account/models/account_move.py#L3575 and designated as future moves, not to be posted at this time. At the end of the `_post()` stack: https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L229 where there would normally be some `correction_amls`, they weren't created here because the AMLs for the price diff were not posted- so the price diff entry is generated. **Fix:** Wait for pending (`state == 'draft'`) AMLs that are part of some `AccountMove`'s valuation to be no longer in draft before allowing reconciliation with a currency exchange difference. opw-4266652 closes odoo#193971 Signed-off-by: William Henrotin (whe) <[email protected]>
**Problem**: Outlook always displays the border of an element if `border-style` is set to `solid`, even when all border widths are 0. **Solution**: Change `border-style` to `none` if all border widths are 0. **Steps to Reproduce**: 1. Open the "Event: Registration Confirmation" email template in the web editor. 2. Add a character and save the template. 3. Check the saved `body_html`. -> All table elements will have `border-style: solid;` added as inline styling, causing borders to appear in Outlook. opw-4211794 closes odoo#193973 Signed-off-by: David Monjoie (dmo) <[email protected]>
When creating a new database or activating a new currency, the first rate fetched will often be set only starting "today". This can lead to issues when creating invoices in the past, especially if the conversion rate is very different from 1. Instead of only using a fallback on 1, we also fallback on the oldest rate in the database if available. closes odoo#194500 Signed-off-by: Wala Gauthier (gawa) <[email protected]>
The credit limit in the partner form view was missing a currency symbol, leading to ambiguity about whether the limit was in the customer's currency or the company's currency. Displayed the partner limit in the company currency to avoid confusion. task-4507336 closes odoo#194807 Signed-off-by: Hugo Poncelet (hupo) <[email protected]>
### Contains the following commits: odoo/o-spreadsheet@4886b0b10 [REL] 16.0.58 Task: 0 odoo/o-spreadsheet@e83048734 [FIX] formulas: binary search returning incorrect index for multiple exact matches Task: 4328300 odoo/o-spreadsheet@f76407ac7 [FIX] selection: drag and drop resized cols and rows Task: 4454025 odoo/o-spreadsheet@db9509f79 [FIX] renderer: Fix grid rendering Task: 4448426 closes odoo#195229 Signed-off-by: Pierre Rousseau (pro) <[email protected]> Co-authored-by: Anthony Hendrickx (anhe) <[email protected]> Co-authored-by: Alexis Lacroix (laa) <[email protected]> Co-authored-by: Lucas Lefèvre (lul) <[email protected]> Co-authored-by: Dhrutik Patel (dhrp) <[email protected]> Co-authored-by: Adrien Minne (adrm) <[email protected]> Co-authored-by: Mehdi Rachico (mera) <[email protected]> Co-authored-by: Florian Damhaut (flda) <[email protected]> Co-authored-by: Rémi Rahir (rar) <[email protected]> Co-authored-by: Pierre Rousseau (pro) <[email protected]> Co-authored-by: Vincent Schippefilt (vsc) <[email protected]>
Steps to Reproduce: - Go to the website editor. - Add a form to the page. - Select the form and change the default action from "Send an email" to "Create an opportunity." - Select the "Subject" field. - Set the visibility condition of the "Subject" field to "visible only if the phone number is set." - Since this is a mandatory field, define a default value for the "Subject" field. - Save the changes. - Fill out the form but leave the phone number field empty so that the "Subject" field does not appear. - Attempt to submit the form. - Bug: the form is not sent and there is an error message. The error occurs preventing the record from being created because all required fields are not present, we should use the default value as it has been provided. This commit prevents adding the "disabled" attribute to inputs that are required for models. This commit also adds tests to ensure that a field required for a model is not disabled when conditionally hidden, and that a required field (but not required for a model) is disabled when conditionally hidden. opw-4447039 closes odoo#194902 Signed-off-by: Serge Bayet (seba) <[email protected]>
Before this commit, due to the group place on the setting, the cash basis option was not displayed to user with only invoicing. Now, we want the user (with only invoicing) to be able to see it but not modifying the account on the settings. It will allow the users to choose the tax exigibility on the taxes, which for french user is important since depending on that the sentence "Option to pay tax on debits" will be displayed on the invoice. closes odoo#190995 Task: 4342603 Signed-off-by: Ruben Gomes (rugo) <[email protected]>
Additional information is needed in the error log to identify the method causing the error. Prior to this change, the log received when an error occured was as follows but no information about the code was shown: `odoo.addons.point_of_sale.models.pos_order: Could not fully process the POS Order: Record cannot be modified right now: This cron task is currently being executed and may not be modified Please try again in a few minutes. closes odoo#195184 Signed-off-by: Vlad Stroia (vlst) <[email protected]>
Applies odoo#194130 for all TicketBAI invoices, and not only for those for Bizkaia. Also, fixes a syntax error where attributes were view not really being changed. That syntax error was hiding another problem: extra refunds were not taken into consideration when checking chain integrity. Thus, refunds made this way could never be pushed to TicketBai/Batuz because Odoo failed that prior validation. That's fixed here too now. @moduon MT-4966 closes odoo#194361 Signed-off-by: Ricardo Gomes Rodrigues (rigr) <[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.
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