Wednesday, December 27, 2023
11 changes · 17.0
Resolved issues and error corrections
This fixes the website timeline snippet so the vertical line no longer runs through date labels. It restores the intended visual separation and also corrects existing timeline snippets already saved on websites, improving presentation consistency for visitors.
Original PR description
Each date in the timeline snippet was displayed with the time line going through them. The line is supposed to be cut around the date. This occurs since [1] which made it so `<span>` elements are…
Each date in the timeline snippet was displayed with the time line going through them. The line is supposed to be cut around the date. This occurs since [1] which made it so `<span>` elements are automatically removed by the editor if they do not have any attributes. Unfortunately, this snippet relied on such a span, since [2]. This commit solves the issue by making the snippet better (and the XML structure will further be improved in the master forward-ported version). Unfortunately, this is not entirely stable, even though it leads to the exact same result provided no custom code tweaks the snippet. It will also solve existing timeline snippets in current databases. Note: [1] was obviously a mistake to merge in stable, although it might be kept seeing the delay since it was merged and nothing critical seems to have happened. [1]: https://github.com/odoo/odoo/commit/a26e27c85e6a0685b6cf4d2dbab90453899df34c [2]: https://github.com/odoo/odoo/commit/fbe38fb41dfdb76878748a1149f93700b566d228 task-3657771
Applicant salary offers now keep the salary structure selected on the contract template instead of falling back to the company's default. This prevents candidates, such as student applicants, from seeing irrelevant payroll benefits in the salary configurator.
Original PR description
To reproduce (on runbot): - Enable "debug" mode - Switch to company "My Begian Company" - Go to: Payroll / Configuration / Contracts / Template - Create a new contract template: * Name: Student…
To reproduce (on runbot): - Enable "debug" mode - Switch to company "My Begian Company" - Go to: Payroll / Configuration / Contracts / Template - Create a new contract template: * Name: Student contract template * Salary structure: Belgian Student * Job position: Student - Create a new applicant for job position (Student) - name: John Doe - email: john@example.com - Click "Generate Offer": - Contract Template: Student contract template - Click "Save" - On the offer, click "Salary Configurator" button => by default student has only 1 benefit in kind (regular pay) but on the salary configurator you see many more entries listed (ex: 13th Month) that are coming from another salary structure (Belgian Employee). During the simulation as no employee exists (it's an applicant), a new "temporary" employee is created and assignee to the contract; this update the company which trigger a recomputation of the `structure_type_id` field (since odoo/odoo@21aca4704) resetting it's value to the country's default. This commit ensure we only reset that field when the country do change --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes unstable automated tests in the messaging area by making test checks wait for expected actions instead of relying on timing shortcuts. The change helps reduce false test failures and improves confidence in release validation without changing business functionality.
Original PR description
Several tests are non deterministic because they are using `assert.verifySteps` at the wrong moment. Helpers such as `afterNextRender`, `nextTick`, `Deferred` are used but those are either not reliable or cumbersome to setup. This PR introduces an asynchronous API on top of `assert.step`/`assert.verifyStep`. This will wait until steps are executed or until the timeout is reached. fixes runbot-52660,54471,52794
This fix prevents an occasional error when retrieving product records through XML-RPC by safely handling missing field definition information. It helps integrations and automated processes that read product data continue running instead of failing unexpectedly.
Original PR description
Sometimes definition_record can be None. This checks that definition_record is not None before calling it on record Description of the issue/feature this PR addresses: #146835 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
Editable fields in PDF quotes now show their filled-in values immediately instead of being hidden behind an overlay in some PDF readers. Filled fields are also made read-only, and duplicate field names are handled so different values display correctly across documents.
Original PR description
PDF written with scribus (and some other software) have a problem when filling fields: the output does not work as expected. The replaced value is there, but hidden behind a blue overlay, shown only when clicking on it. We now show the field value and ensure filled fields are read only. Additionally, some readers only allow a single value per field name. Even if the values were different on the documents, only one would be shown. We now rename the fields to ensure they are different when they have different values. task-3626047
API connections using an API key no longer fail when two-factor authentication is enabled. The change skips an email alert check when there is no web request available, improving reliability for integrations without changing normal login behavior.
Original PR description
Description of the issue/behavior this commit addresses: When 2FA is on on a user and he tries to use an API key to do a xmlrpc request, the request fails. This is due to the system which choses whether or not to send an alert via mail to look in the request's values while there is actually no url request in that case. --- Desired behavior after this commit is merged: This commit adds a check to make sure a request is available before checking its values. --- opw-3645609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects how follow-up levels are assigned to invoices in the accounts receivable process. Previously, when executing a follow-up action, the system would incorrectly apply the follow-up level to all invoices from a partner, even those not yet overdue enough for that level. Now the system only applies the follow-up level to invoices that meet the overdue threshold, ensuring the partner's status accurately reflects their actual payment situation after invoices are paid.
Original PR description
To reproduce: 1- Create two bills, the first one should be +30 days overdue and the other between 15 and 30. 2- Execute manually the 15 days / level 1 follow-up. The partner goes into the 30 day level. 3- Change the Next Reminder date to the day before today. 4- Execute the second reminder manually. The partner status will go to 40 days. 5- Pay the first invoice. Now when you go back to the follow-up report, the first invoice will have been removed (normal) but the status remains in "40 days" (not normal). This happens because the executed follow-up level is set for all the move lines, even the ones that are not due enough for the level. Fix: only change the follow-up level on the move lines if their due date is more to or equal to the delay of the level being executed. task-3608880 Forward-Port-Of: odoo/enterprise#53388 Forward-Port-Of: odoo/enterprise#52059
This update fixes several user-facing issues across manufacturing shop floor, point of sale employee login, timesheet validation, and field service stock display. It helps users avoid crashes, misleading stock quantities, unusable popups, and layout problems during everyday operations.
This fix resolves an issue where manager reminder emails for timesheets were being sent multiple times in databases with multiple companies. The system now correctly checks each company's individual settings and only sends reminders to employees in companies where the feature is enabled, preventing unnecessary duplicate emails.
Original PR description
In a multi-company database, as the `Manager Reminder` email setting is a per-company setting, we should only send the reminder to the employees (Timesheet / Manager) of the companies which have the setting enabled OPW-3625737 Forward-Port-Of: odoo/enterprise#53356 Forward-Port-Of: odoo/enterprise#52808
This fix resolves an issue where customers in Mexico and Chile could not complete their checkout when required additional information was needed. The checkout form was getting stuck in a loading state and not processing customer data. The fix ensures that the validation form properly submits customer information so they can proceed with their purchase.
Original PR description
Commit that introduced the issue: https://github.com/odoo/odoo/commit/14fc7f3c923847f5e052888c2cfda0bf92316972 Issue: ====== Validating required additional fields doesn't work. Steps to reproduce the…
Commit that introduced the issue: https://github.com/odoo/odoo/commit/14fc7f3c923847f5e052888c2cfda0bf92316972 Issue: ====== Validating required additional fields doesn't work. Steps to reproduce the issue: ============================= - Install ecommerce - Install l10n_mx_edi_website_sale - Mark the mexican company as the company for the website - make sure you are logged in as admin - Go to shop and add any item to cart and follow the steps until required addional informations - Clicking on next will disable the button and mark it as loading but nothing happens. Origin of the issue: ================================= - There was some fields missing to use `s_website_form` snippet since it uses action + (foce_action or model_name) to call post method on the path but we didn't provide any. Solution: ========= Override the public widge to not use the send method. opw-3635199 Forward-Port-Of: odoo/enterprise#53386 Forward-Port-Of: odoo/enterprise#53072
This update fixes how internal messages are displayed in the helpdesk system for portal users. The fix ensures that messages are properly categorized as comments, which allows the system to correctly filter and display only the appropriate messages to each user based on their access level. This resolves an issue where portal users may have seen messages they shouldn't have access to.
Original PR description
Complete the fix of commit: https://github.com/odoo/enterprise/commit/aacf90852cfcba71ba4b62ceaefecf7da723ebf3 We need to set the subtype of the message to 'comment' (`mt_comment`) to respect the domain which filters the messages to be displayed for a portal user. opw-3601205 Forward-Port-Of: odoo/enterprise#53044