Daily updates from Odoo
Wednesday, April 10, 2024
41 changes
4 changes
Resolved issues and error corrections
The point of sale numpad now shows the backspace and plus/minus buttons in their expected positions. This prevents cashier confusion and helps keep checkout input faster and more accurate.
Original PR description
Before this Commit: ========== - In the Numpad, the plus/minus, decimal point, and backspace buttons were displaced from their correct positions. After this Commit: ========== - The plus/minus, decimal point, and backspace buttons were correctly placed in the Numpad. task-3856515
This fix improves the reliability of automated tests for Odoo's mail, Discuss, and live chat features by preventing delayed background calls from one test affecting another. It is an internal quality fix that helps reduce false test failures without changing user-facing behavior.
Original PR description
HOOT keeps identity of mock server but resets it in-between tests. Tests could have some ongoing code that could trigger RPC, e.g.: - When typing in composer there's a 5 second timeout for sending…
HOOT keeps identity of mock server but resets it in-between tests. Tests could have some ongoing code that could trigger RPC, e.g.: - When typing in composer there's a 5 second timeout for sending "not typing" notification. - When observing a thread with new message, should notify server of new last message seen. Such RPCs of old tests could affect current test and make it fail. HOOT currently lacks proper test isolation with RPCs, so while this is being fixed discuss code implemented a workaround: use an env-bounded version of `rpc()`, so that envs of a given test are tracked and considered elligible during running of the test in question. The rough idea of this workaround works, but using a global `let rpc` was problematic, because it was overridden by new tests, which actually allowed old tests to invoke `rpcWithEnv` of the newer test. A solution is to save this env-bounded rpc on test-specific assets like `this` of service/component/record. This commit solves it by turning it into a `mail.rpc` service that internally contains `rpcWithEnv`. Services are designed to be env-aware, and their uses force developers to use `this`, therefore it feels natural to use a service to solve this issue.
This fixes an internal testing issue in the mail and live chat areas by ensuring requests from finished tests are blocked. It helps keep automated test results reliable and reduces the risk of false failures during development.
Original PR description
This utility function was used to bind an env to rpc, so that HOOT tests prevent handling RPCs of prior tests, i.e. tests that finished could still trigger RPCs that were intercepted in some other…
This utility function was used to bind an env to rpc, so that HOOT tests prevent handling RPCs of prior tests, i.e. tests that finished could still trigger RPCs that were intercepted in some other tests. At the time, we were not aware of HOOT feature of scopped param context for each test (suite). Thanks to this feature and RPC internal being easily globally patchable in test environment, we can slightly change its internal in HOOT to use scopped params in order to use same behaviour as `rpcWithEnv` but it's on whether the contextual start is allowed to make rpc or not. With this commit, tests that use mail `start` now have a patched version of RPC which blocks RPCs at end of test. Some technical notes on the implementation: 1. global variable `rpcPatched` is per HOOT test file, similarly to `rpc` function. Although it looks like the code only patches `rpc` once, it actually patches rpc once per test file being run. This is because global scope is "refreshed" for each file, so `rpc` function needs to be re-patched. 2. On the other hand, `defineParams()` used in start defines `MAIL_START.allowRpc` once per test. This allow to block RPC specifically to a test that has finished.
This fix avoids showing misleading browser console errors when valid screen templates are loaded later as part of a lazy-loaded bundle. It keeps stricter checks where needed so template issues are still caught without disrupting legitimate delayed loading.
Original PR description
With https://github.com/odoo/odoo/pull/160643, it is now easier to detect template extensions for which t-inherit attributes do not match any template name. Nevertheless the implementation should be…
With https://github.com/odoo/odoo/pull/160643, it is now easier to detect template extensions for which t-inherit attributes do not match any template name. Nevertheless the implementation should be improved. Consider the following situation. Have a template A be defined in a bundle 1 and a primary extension B defined in a bundle 2 that is lazy loaded. In that case an error is logged in the console while the template B can be effectively build browser side. The solution to that problem is to check if A is available only when the bundle 2 has been loaded and that all templates in 1 and 2 are known. Note that we don't delay the check for the other type of extensions (t-inherit-mode="extension") since we think it is a bad idea. Take the same situation as before but with B an extension with t-inherit-mode="extension". If OWL has already mounted a component with template A, we wouldn't know what to do with the extension. Keeping things simple, we still enforce (as before) that such an extension should be in the bundle of its parent.
4 changes
Resolved issues and error corrections
This fixes access settings for Australian payroll employee fields so they are only available to appropriate HR users. It prevents errors caused by payroll-related information appearing in the public employee profile where it should not be accessible.
Original PR description
Issues: The model hr.employee requires the group hr.group_hr_user for fields that are not accessible in the employee public profile. The new fields missed the groups. https://runbot.odoo.com/web#id=61373&view_type=form&model=runbot.build.error&menu_id=405&cids=1 Fix: Adds the missing groups on the fields `l10n_au_super_account_ids,super_account_warning` on h.employee.
This fixes an issue where items could appear in the wrong order on the preparation display when starting a database. Staff will see orders in the intended sequence, reducing confusion during preparation workflows.
Original PR description
Make the sequence ordered works in preparation display when starting a db
Grouping planning shifts by role no longer fails when an employee has no working calendar assigned. This keeps planning views usable even when employee schedule information is incomplete.
Original PR description
Steps to Reproduce:
----------
- Install the planning module.
- Navigate to the employee app.
- Create an employee without a working calendar.
- Navigate to the planning app.
- Create a shift.
- Try to group shifts by role.
Issue:
-------
When trying to group shifts by role, a traceback occurs if an employee is without
a working calendar.
Cause
-----
The traceback arises due to the inability to find work intervals for resources without
a working calendar.
Solution:
----------
If a resource has a working calendar, the system retrieves work intervals; otherwise,
it sets the intervals to 0.
task-3858539Fixed an issue that could prevent the Planning schedule from loading when viewed by role. The system now skips a work-hours calculation when the schedule is not grouped by resource, avoiding an error and allowing planners to access the view normally.
Original PR description
Before this commit, when only planning app is installed and the user goes to Planning > Schedule > By Role, a traceback is raised because the resource_id is not found inside work intervals fetched.…
Before this commit, when only planning app is installed and the user goes to Planning > Schedule > By Role, a traceback is raised because the resource_id is not found inside work intervals fetched. The reason is because `this.row.resId` is the resource id only if the first group is resource_id and not something else and so when the group by is `role_id > resource_id` the `resId` will return the role id and not the resource id. It would mean the compute work hours should not be done when the group by does not start by resource. This commit avoids computing the work hours when the progressField is not a employee, that is, when the group by does not start by resource_id. Affected version(s): master Steps to reproduce the issue: ============================ 1. Install planning app 2. Go to planning > Schedule > By Role Current Behavior: ================ A traceback is occured because a role id is not found inside work intervals per resource id. Expected Behavior: ================= The Gantt view should be loaded without any issue. runbot-61438 X-original-commit: 5831c225
33 changes
Resolved issues and error corrections
This fix allows users to decrease the quantity of service products in the Field Service Management catalog, even when those services have been marked as delivered. Previously, the system prevented quantity reductions for delivered services. This change gives users more flexibility when managing service quantities that were invoiced manually.
Original PR description
The quantity_decreasable_sum of a service product no longer takes into account the delivered quantities This is done so we can decrease service product quantity in the product catalog even tho those product are considered delivered by default https://github.com/odoo/odoo/pull/155157 Task-3689939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves a problem where accounting report PDFs were cutting off columns when partner names or currency symbols were too long. The solution adds width constraints and text wrapping to ensure all report columns display properly in PDF exports, improving the reliability of aged payable and aged receivable reports.
Original PR description
### Steps to reproduce: - Create a vendor bill for a partner with a super long name. - Go to Accounting > Reporting > Partner reports > Aged Payable - Generate the pdf #### > If the partner's name is…
### Steps to reproduce: - Create a vendor bill for a partner with a super long name. - Go to Accounting > Reporting > Partner reports > Aged Payable - Generate the pdf #### > If the partner's name is long enough the last columns will not appear ### Cause of the issue: Pdf are generated in Odoo using wkhtmltopdf. This one takes an html file renders it in Qtweb (shrinking its content to fit a single screen) and making a screenshot to generate a pdf. However, there is a limit to the shrinking applied to the html body. Therefore, if the content is too wide part of it will not appear on the pdf (this can easily been observed using Qtweb (but not with chrome)). Between 16.4 and 17.0 there was a refactoring of the way account reports are handled in Odoo see commit 2d77434 and commit b8209e2. Because of this refactoring, there is currently no width limit for cells of the table used in the body of account reports. As such, if the content of the first column is too wide, every other column will be pushed out of the screen before the pdf is generated. This is exactly what happens here. ### Fix: We added a max width to cells and a wordbreak option on the css file used for the html in the pdf export of every account reports. This ensures that the content of any cell will not push the other cells outside of the screen before the screen shot. ### Second Issue: Even with this issue out of the way, it is still possible for the content of the aged partner balance reports to be too wide after the shrink of the hmtl if you use a currency whose symbol is too long. The reason is the same as before coupled with the fact that these reports contain too many columns displaying the currency symbol of the company. ### Second part of the fix: To fix this second issue, we use a custom css class for the export of the two problematic reports (aged payable and aged receivable) when the currency symbol is too wide. opw-3749625 ---
The Journal Report PDF export now displays the reporting period or date in the document header. Previously, when users printed or exported the Journal Report to PDF, the header was missing this important date/period information, making it unclear what time period the report covered. This fix ensures the date is now visible in the PDF header for better clarity and record-keeping.
Original PR description
Currently, when you print the journal report, the header doesn't contain any information about the date/period. Steps to reproduce * install `account_reports` * open and export the Journal Report to PDF The period/date does not appear in the header (or anywhere in the PDF) opw-3827366
Read-only users can no longer see or access the history dialog button when viewing knowledge articles. Previously, these users could view the history interface but couldn't make changes, creating a confusing experience. This fix improves the user interface by hiding the history feature entirely for users without edit permissions.
Original PR description
This commit fixes an issue where readonly users are able to access and restore an old version of an article via the history dialog but it didn't affect the DB as no write could be done by this user. The change was only visible and functionnally didn't change the body field. Now when a user accesses to an article where he can only read, the history dialog button is hidden. task-3836201
A recent system update changed how subscription invoices are displayed, which removed the Brazil-specific customization that hides certain tax-related amounts. This fix restores the proper invoice display for Brazilian customers by creating a new module that reapplies the customization.
Original PR description
4755b82fa40df50362e72ccc3e08f6ce5383dde3 changed the portal template used for subscriptions by overriding `_get_name_portal_content_view()`. Because of this, the override in `l10n_br_sales` no longer applies and we end up with the standard subscription portal view instead of the customized one for Brazil. Although not very nice, the only way around it I could think of was to create this new module so we can override again with a new portal template that inherits from sale_subscription.subscription_portal_content.
This update improves the commercial invoice data for international shipments in the UPS delivery modules. Missing information required for proper customs documentation is now included, ensuring international orders are processed more smoothly and with complete documentation.
Original PR description
This commit adds some of the missing information in the commercial invoice for international shipments in `delivery_ups` and `delivery_ups_rest` modules. opw-3668875 Forward-Port-Of: odoo/enterprise#58861
This fix improves the French FEC import feature by providing a clear error message when required data is missing from imported files. Previously, users would encounter a confusing technical error; now they receive a user-friendly message explaining what went wrong, making the import process more reliable and easier to troubleshoot.
Original PR description
When users try to import a file into the ``FEC import`` and the file doesn't have the value of ``key``, an error occurs. This happens because the system requires the value of ``JournalCode`` to be…
When users try to import a file into the ``FEC import`` and the file doesn't have the value of ``key``, an error occurs. This happens because the system requires the value of ``JournalCode`` to be present in the imported file for successful processing.
Steps to reproduce:
- Install ``l10n_fr_fec_import`` module
- Change company from YourCompany to FR Company
- Now Accounting -> Configuration -> Accounting -> Journals
- Select all journals -> export all journals -> download file in CSV format.
- Configuration -> Settings -> Accounting Import -> import -> Click on the ``Import FEC button``
- Upload a file that you have downloaded and Import
Traceback:
``` AttributeError: 'NoneType' object has no attribute 'replace'
File "odoo/http.py", line 2252, in __call__
response = request._serve_db()
File "odoo/http.py", line 1828, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1848, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1826, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1833, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2058, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 42, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/saas-17.1/l10n_fr_fec_import/wizard/import_wizard.py", line 683, in action_import
return self._import_files()
File "home/odoo/src/enterprise/saas-17.1/l10n_fr_fec_import/wizard/import_wizard.py", line 729, in _import_files
for xml_id, record in generator(rows, cache):
File "home/odoo/src/enterprise/saas-17.1/l10n_fr_fec_import/wizard/import_wizard.py", line 193, in _generator_fec_account_journal
journal_xml_id = self._make_xml_id('journal', journal_code)
File "home/odoo/src/enterprise/saas-17.1/l10n_fr_fec_import/wizard/import_wizard.py", line 110, in _make_xml_id
key = key.replace(' ', '_')
```
This commit resolves the mentioned issue by verifying if the key is present; otherwise, it will raise a UserError.
sentry - 4929578488Fixed a crash that occurred when users tried to drag and drop documents in the schedule activity dialog box. The issue was caused by the dialog attempting to access folder information that wasn't available in that context. After this fix, users can now interact with documents in the schedule activity dialog without encountering errors.
Original PR description
To reproduce the issue: 1. Switch to the `Activity` view for the Documents module. 2. Click `+ Schedule Activity`. 3. The dialog box opens up with the list of documents. 4. Try to DRAG & DROP any…
To reproduce the issue:
1. Switch to the `Activity` view for the Documents module.
2. Click `+ Schedule Activity`.
3. The dialog box opens up with the list of documents.
4. Try to DRAG & DROP any document list item.
5. We get a TRACEBACK.
Issue:
- The `onRecordClick` and the `onDragStart` events bound on the record rows are
executed when we DRAG & DROP or click the records from the list of documents.
- When the method(`onDragStart`) is called from inside the `Dialog` scope, the
`foldersById` in the line of code below returns a singleton object(`{false: {…}}`)
with `false` being the folder_id of the `All` workspace.
- However, when the same method is called from the list/kanban view
(i.e. outside of the `Dialog` scope) then the `foldersById` would return an
object with all of the folderIds present as keys.
- In our case `foldersById[record.data.folder_id[0]].has_write_access` throws a
traceback because the value of every `record.data.folder_id[0]` is a `Number`
(as no document can be present inside the `All` workspace), but the
`foldersById` object only contains the `false` key.
Fix:
- The schedule activity dialog box renders the JS of the list view of the related module. In our case, it renders the base list view from the documents and renders the JS of it.
- We cannot change this in stable so we fix the issue in JS.
After this commit:
- The records are no longer selected.
- We no longer get the traceback.
Task-3727009
Forward-Port-Of: odoo/enterprise#56356This fix resolves an issue where Chilean electronic invoices (boletas) were incorrectly marked as "Rejected" when the system couldn't determine their actual status from the tax authority. Now, when the status is unclear, the system will show "Ask For Status" instead, allowing users to verify the invoice status again. This prevents users from being stuck with rejected invoices that haven't actually been rejected.
Original PR description
**Steps to reproduce:** (requires a real certificate and a real CAF) - Install Accounting and l10n_cl_edi_boletas - Switch to a Chilean company - Configure the localization settings with a real…
**Steps to reproduce:** (requires a real certificate and a real CAF) - Install Accounting and l10n_cl_edi_boletas - Switch to a Chilean company - Configure the localization settings with a real certificate and a real CAF - Create an invoice: * Customer: [a Chilean customer] (e.g. Blanco Martin & Asociados) * Document Type: (39) Boleta Electrónica * Product: [any] - Confirm the invoice - Click on "Send Now to SII" - "SII DTE status" will be "Ask For Status" and "Send Now to SII" will change to "Verify on SII" - As soon as it changes to "Verify on SII", click on it - Repeat clicking on "Verify on SII" as soon as it becomes clickable **Issue:** At some point, "SII DTE status" will switch from "Ask For Status" to "Rejected", even if the invoice has not been officially rejected. And as "Verify on SII" link will not be available anymore, it will not be possible to correct the SII DTE status. **Cause:** While checking the SII result after clicking on "Verify on SII", we could receive a response with "estado: SOK" and "estadistica: []". This combination doesn't allow to determine a specific status for the SII DTE and therefore falls back on the default status that is "Rejected". **Solution:** If the SII DTE status cannot be determined, we should use "Ask For Status" as a fallback status to allow verifying it again. opw-3781373 Forward-Port-Of: odoo/enterprise#60284 Forward-Port-Of: odoo/enterprise#59523
This update fixes a display problem in the My Timesheets grid view where the start button would not appear correctly when there are more than 26 timesheet entries. The fix ensures that all timesheet rows display properly regardless of how many entries are present, improving the user experience for employees with extensive timesheet records.
Original PR description
In My Timesheets grid view if you have more than 26 lines, the last ones will display a border only Tweaked some conditions in the grid_timer_button_cell.xml Task-3670682 Forward-Port-Of: odoo/enterprise#59800 Forward-Port-Of: odoo/enterprise#53749
This update fixes an issue where certain employee information fields in the Morocco payroll module were not properly restricted to private employee records. The fix adds appropriate access controls to ensure these sensitive fields are only accessible where intended, improving data security and system stability.
Original PR description
Basically, the following fields are only defined in private employee, and not on public employee. Thus we need to put group on them
This update corrects how document names are displayed when using the PDF split tool to gather pages. Previously, the filename was incorrectly formatted as "(remaining pages.pdf" with a missing opening name and closing parenthesis. Now it properly displays as "name (remaining pages).pdf", making file names clearer and more consistent for users.
Original PR description
Fix the document name which was renamed to "(remaining pages.pdf" when exiting the split tool by gathering in one page. Missing the initial name and missing the closing parenthesis. The document name by gathering in one page is now structured as: "name (remaining pages).pdf" Technical point: Using sprintf so that users will have an entry with %s in the translation file allowing them to choose the file name position. related: https://github.com/odoo/enterprise/pull/40454 Task-3847395 Forward-Port-Of: odoo/enterprise#59979
This update fixes a critical issue where tax identification numbers and email addresses for shippers and recipients were missing from FedEx commercial invoices. The system now properly includes these required fields in all FedEx shipping requests, ensuring compliance with FedEx documentation requirements and improving the accuracy of shipping records.
Original PR description
before this commit: TaxId and email address of shipper and recipient was not showing on commercial invoice. After this commit: Added relevant fields in fedex request. TaxId needs TinType to be passed in request, default value set to 'BUSINESS_NATIONAL'. https://support.shiptheory.com/support/solutions/articles/24000077333-which-tin-type-should-i-use-for-my-fedex-shipments- opw-3748463 Forward-Port-Of: odoo/enterprise#59421
This update fixes how product quantities are validated in the product catalog when users adjust quantities. Previously, the system prevented quantity reductions below delivered amounts, which caused issues with service products that don't have delivery tracking. The fix allows service products to have their quantities adjusted freely in the catalog while maintaining proper controls for physical products.
Original PR description
The sale_stock module patches the ProductCatalogKanbanRecord updateQuantity method to prevent the quantity to go under the delivered quantity of the product The issue is that we are also using the ProductCatalogKanbanRecord in the industry_fsm_stock module we are also doing an override of the updateQuantity method to prevent the quantity of a product to go under the 'minimumQuantityOnProduct' which can be lower that the delivered quantity of a product in the case of a service product Task-3689939 https://github.com/odoo/enterprise/pull/55455 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Brazilian sales order quotations and portal views were missing line item totals, showing only description, quantity, and unit price. This fix restores the total amount column on each line in both the PDF quotation and customer portal, ensuring customers see the complete pricing breakdown for their orders.
Original PR description
This module was introduced in saas-16.4. In that version the sale order report and portal template displayed both price_subtotal and price_total for each sale order line. 655d375af83dd49bbbd5f5818e319c3b0e9778c1 removed price_total. Because this module removes price_subtotal we end up with no line total at all on the default Brazilian quotation PDF and portal view (just 3 columns: description, quantity and unit price). Loosely inspired by l10n_cl [1], this commit changes our approach to turn the two places where we use price_subtotal into price_total. The aforementioned commit also changed the heading of this column from "Subtotal" to a more generic "Amount", so there's no inconsistency there. Although this is a bit of a mess, I can't think of a better solution. [1] https://github.com/odoo/odoo/blob/655d375af83dd49bbbd5f5818e319c3b0e9778c1/addons/l10n_cl/views/report_invoice.xml#L173-L175
Fixed an issue where users couldn't download files from binary fields in the sales settings form. The download button now appears and functions correctly by properly retrieving files from their actual storage location, even though the settings model doesn't have a traditional ID field.
Original PR description
Steps: - Install sales app. - Go to settings of sales. - See header field there is no download button. Issue: - Binary field should have download button and user should be able to download file with out issue. Cause: - Since Settings is abstract model so it does not contains id field in it and download button visibility depends on id field. Fix: - - Extend binary field for setting view to get proper file from related field where actual file is stored. task-3620555
This fix resolves a critical issue where clicking on product description fields in edit mode caused the page to freeze due to an infinite loop. The problem occurred when editing empty content areas, and this update prevents the system from repeatedly re-selecting these areas, allowing users to edit product pages without interruption.
Original PR description
Steps to reproduce the bug: - Install e-commerce. - Open a product page in edit mode. - Click on the "product.description_ecommerce" field. - Bug: an infinite loop starts. The "selectionchange" event is triggered in an endless loop, causing various issues such as the page freezing after a while. This issue was introduced by this commit [1]. Since this other commit [2], when a selection itself is the main container of the editable area, we replace this selection to only include the content of it. With commit [1], this has been modified to take into account "oe_structure" and "[contenteditable]" elements. As these elements can be empty, clicking on them would reselect them, creating an endless loop since we'd never leave the condition that replaces the selection. [1]: https://github.com/odoo/odoo/commit/e93fa23c29421ffe8917d9650330585d6dad210f [2]: https://github.com/odoo/odoo/commit/10c5a16cd44b8d8e54082df90166f2309dfa788d task-3830033
Fixed an issue where sending multiple PDF bills to a vendor bills email alias would create only one record with all bills attached, instead of creating separate records for each bill. The system now correctly processes each bill individually, allowing proper document extraction and organization.
Original PR description
Configure an email alias for the journal 'Vendor Bills' Send to the mail alias two pdf bills Issue: Only 1 record is created with the 2 bills as attachment The system should split the bills into separate records, but this does not occur: - after the first bill is processed the current move extract_state is 'waiting_extraction' - when the system check whether to extract data from the second document the result is negative as it check the state of the first document Enterprise PR: https://github.com/odoo/enterprise/pull/60168 opw-3822262
This fix prevents portal users from being able to edit timesheet records when viewing subtask timesheets through the project app. Previously, portal users could inadvertently gain write access to timesheets due to permissions granted by the MRP module, which was not intended for the project application. The fix creates read-only views specifically for portal users to prevent unauthorized modifications.
Original PR description
Currently, there is an access right problem concerning timesheet. The module mrp gives write access to portal user on analytic line, but it is not something we want for the project app. step to…
Currently, there is an access right problem concerning timesheet. The module mrp gives write access to portal user on analytic line, but it is not something we want for the project app. step to reproduce: - install hr_timesheet on a saas-16.3 db - go to project app, open office design - select any task, and add a subtask to it - go the the view form of the subtask - create a new timesheet for this subtask - go back to the view form of the parent task a button 'subtask timesheet' is now visible - share the project in edit mode with a portal user - connect with that portal user - open the office design project - go to the view form of the parent task and click on the button - the user is redirected to a view tree with the timesheet of the subtask this view tree is editable Source of the problem: in the mrp module, the access rights of the analytic line is overwritten to give write access to it to portal user. Soluce: We have to make the view in readonly mode for timesheet when the connected user is a portal one. Unfortunately, it is not 100% possible because setting the field to readonly still gives the user the opportunity to click on those fields (which triggers access errors). So we have to create new views and specifically open those views when the user is a portal one. affected version: saas-16.3 - master task - 3751315 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 Forward-Port-Of: odoo/odoo#155768
This fix prevents archived products, taxes, and other records from being added to quotations when creating them from customer opportunities. Previously, the system was incorrectly allowing archived items to appear in new quotations. Now, only active records will be available when users create quotations through the Contact and Opportunity workflow.
Original PR description
Before this commit, when the user created a new quotation from Contact->Opportunity-> ("New Quotation" or "Quotations/orders widget button", archived records could be added to the quotation (e.g. ,product, taxes...) because the context was set to active_test = false. After this commit, the context is configured back to active_test = true when creating a quotation from opportunity.
opw-3802796
Forward-Port-Of: odoo/odoo#160792
Forward-Port-Of: odoo/odoo#159335This fix corrects misleading help text in datetime fields that was incorrectly suggesting language-specific date formats. The help text now consistently displays "today" in all languages instead of showing translated alternatives like "aujourd'hui" in French, which could confuse users about what date formats are actually accepted.
Original PR description
Steps: - Install `web_studio` - Change language to French - Open any form view and enable `Studio` - Add a datetime field and click on it In french we have the following message: "Première date acceptée": Date formatée ISO ou "aujourd'hui" He says that we can use the string "aujourd'hui" when we only expect "today" in English. This commit changes the help text to display "today" in every language opw-3829954 Forward-Port-Of: odoo/odoo#160144 Forward-Port-Of: odoo/odoo#159654
Users encountered an error when trying to clear start or end dates while editing events on the website. This fix prevents the application from crashing by properly handling empty date fields during the save process. The issue affected the website event editing functionality and has now been resolved.
Original PR description
When user tries to empty start date or end date in website using editor, a traceback will appear. Steps to reproduce the error: - Install "website_event" - Go to Website > Events > Open any Event >…
When user tries to empty start date or end date in website using editor,
a traceback will appear.
Steps to reproduce the error:
- Install "website_event"
- Go to Website > Events > Open any Event > Register > Edit
- Now try to empty start date or end date > Save
Traceback:
```
TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1826, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1824, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 30, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/website/models/ir_ui_view.py", line 487, in save
super(View, self).save(value, xpath=xpath)
File "addons/web_editor/models/ir_ui_view.py", line 257, in save
self.save_embedded_field(arch_section)
File "addons/web_editor/models/ir_ui_view.py", line 56, in save_embedded_field
record.write({field: value})
File "addons/website_event/models/event_event.py", line 261, in write
res = super(Event, self).write(vals)
File "addons/event/models/event_event.py", line 590, in write
res = super(EventEvent, self).write(vals)
File "addons/mail/models/mail_thread.py", line 319, in write
result = super(MailThread, self).write(values)
File "addons/mail/models/mail_activity_mixin.py", line 248, in write
return super(MailActivityMixin, self).write(vals)
File "addons/website/models/mixins.py", line 217, in write
return super(WebsitePublishedMixin, self).write(values)
File "addons/website/models/mixins.py", line 136, in write
return super().write(vals)
File "odoo/models.py", line 4536, in write
real_recs._validate_fields(vals, inverse_fields)
File "odoo/models.py", line 1483, in _validate_fields
check(self)
File "addons/event/models/event_event.py", line 570, in _check_closing_date
if event.date_end < event.date_begin:
```
https://github.com/odoo/odoo/blob/4759c6d1ee09c32381dc56c59c95949fd0e2807c/addons/event/models/event_event.py#L507 Here, When user tries to empty start date or end date,
start date or end date will become "False",
So it will lead to the above traceback.
solution:
A try-catch is used to catch typeerror at write of qweb fields.
sentry-5038057541
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#160744
Forward-Port-Of: odoo/odoo#156707This fix resolves an error that occurred when viewing POS sales data in the sales reporting dashboard. Previously, the system couldn't properly display completed POS orders because of a mismatch in how order statuses were defined. The fix aligns POS order statuses with the sales reporting system so reports display correctly without errors.
Original PR description
7bbec42 removes the 'pos_done' state without providing a substitute. A discrepancy arises between the states defined in pos.order and sale.report. While pos.order can have a 'done' state, this state…
7bbec42 removes the 'pos_done' state without providing a substitute. A discrepancy arises between the states defined in pos.order and sale.report.
While pos.order can have a 'done' state, this state is not defined in sale.report. Consequently, it is possible to encounter a situation where a state exists in 'sale.report' without being defined in its state field. This inconsistency leads to an error in the web client when attempting to display the state 'done' from 'pos.order', as the system cannot locate a corresponding label for it.
Since we can't add a new state in stable, we'll re-use the sale.order 'sale' state which is the sale.order counterpart of pos.order 'done'.
**steps to reproduce:**
- sales / reporting / sales and go to pivot view
- remove all filters
- on the pivot view, select 'product category'
- click on a cell corresponding to POS (ex: all/saleable/pos)
- click on a line in the list view
**before this commit:**
```
Caused by: TypeError: Cannot read properties of undefined (reading '1')
at get string (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:8393:281)
at SelectionField.template (eval at compile (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:1500:374), <anonymous>:15:21)
at Fiber._render (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:940:96)
at Fiber.render (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:939:6)
at ComponentNode.initiateRender (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:1007:47)
```
**after this commit:**
the form view is rendered
opw-3816652
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#160432This fix corrects how scheduled jobs (cron tasks) are logged in Odoo. Previously, the system would mark a job as "done" before finalizing all database changes, which could incorrectly show success even when errors occurred during the finalization process. The fix ensures accurate logging and includes the complete execution time, including the finalization period which can sometimes be lengthy.
Original PR description
**Description of the issue/feature this PR addresses:** The logger show "Job done" before the flush. But if during the flush an error appear (sql constraint, validation error during computed field, ...), the log contain "Job done", but is not True. The time to compute the cron is not good because it doesn't contain the flush time (in some case can be very long). @Julien00859 @rco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161079 Forward-Port-Of: odoo/odoo#160895
Updated the description of the Interviewer access rights in the recruitment module to accurately reflect actual system behavior. The documentation previously stated that interviewers would not have access to chatter content, but they actually do have this access since no sensitive information is exposed through it. This change corrects the misleading description to match the intended functionality.
Original PR description
### Steps to reproduce: - Go to Recruitment > Applications > All Applications - Create a new application and add Marc Demo as an interviewer - Change the recruitement access rights of Marc Demo to "Interviewer" - Log in as Marc Demo and got to the application ### Expected behavior: As said in the description of the "Interviewer" access rights: "Interviewer right will give access to all job position/applications where the employee is defined. It will allow to refuse, plan meetings. **Chatter content will not be available.**" ### Current Behavior: You have access to the chatter. ### Note: This access right did not exist before saas-16.4 opw-3783965 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159470
This update adds a database index to the accounting reconciliation system to significantly speed up common operations. Unlinking account moves and unreconciling transactions now complete 60+ times faster on large databases, improving overall system responsiveness for accounting teams without affecting data integrity.
Original PR description
**Description of the issue/feature this PR addresses:** Before this commit the time to unlink an account.move can take lot of time. The time to unreconcile can take lot of time. With 1 million…
**Description of the issue/feature this PR addresses:** Before this commit the time to unlink an account.move can take lot of time. The time to unreconcile can take lot of time. With 1 million `account.partial.reconcile`: Time to remove 1 `account.full.reconcile` : before 329 ms after 5 ms. Index size of `account.partial.reconcile` : before 59 Mo after 68 Mo (data size : 112 Mo) (+ 9 Mo) Before:   After:   @oco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160709 Forward-Port-Of: odoo/odoo#141307
This fix resolves an issue where the system would fail when creating new tax entries if older taxes with the same name already existed without proper system records. The solution automatically renames legacy taxes by appending "old" to their names, allowing new taxes to be created without conflicts. This prevents system errors during tax setup and updates.
Original PR description
due to the absence of IR model data entries for certain account taxes, but with identical tax names, tax types, and scopes, attempts to create standard taxes with the same names alongside IR model…
due to the absence of IR model data entries for certain account taxes, but with identical tax names, tax types, and scopes, attempts to create standard taxes with the same names alongside IR model data result in a constraint violation, specifically, "tax name must be unique." To address this constraint, we append "old" to the tax name for existing taxes lacking IR model data entries.
see:
https://github.com/odoo/odoo/blob/740fb9ac8c8e121820feeac0e1f25a304e47da9d/addons/account/models/account_tax.py#L202
```
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4864, in _create
records._validate_fields(name for data in data_list for name in data['stored'])
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 1456, in _validate_fields
check(self)
File "/home/odoo/src/odoo/17.0/addons/account/models/account_tax.py", line 201, in _constrains_name
raise ValidationError(
odoo.exceptions.ValidationError: Tax names must be unique!
```
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
Forward-Port-Of: odoo/odoo#161054Fixed an issue where filtering blog posts by tag displayed an incorrect article count. When filtering results that span multiple pages, the system was showing only the number of articles on the current page instead of the total number of matching articles. Now users will see the accurate total count of filtered results regardless of pagination.
Original PR description
Steps to reproduce: - Add the same tag to 13 different blog posts. - On the "Blog" page, click on this tag to filter the blogs. -> Problem: the result displays "12 Articles" but they are actually 13. In this case, the result displays "12 Articles" as they are 12 articles on the current page. When going on the second page of the results, "1 Article" is displayed. This problem is solved by displaying the total number of articles found after the filtering operation rather than the number of articles on the page. opw-3802729 Screenshots of the problem:   Forward-Port-Of: odoo/odoo#160997 Forward-Port-Of: odoo/odoo#160654
This update corrects how GST and Reverse Charge (RC) values are handled in Indian electronic invoices. Previously, RC values were incorrectly included in the e-invoice submission. The fix ensures RC values are properly separated and excluded from e-invoices as per regulatory requirements, improving compliance with Indian tax authority standards.
Original PR description
Before ====== In E-invoice Value is pass as other values After ==== No RC value is pass to the E-invoice because not required to pass RC value. 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
This update fixes an issue where the chatbot would stop responding when users were redirected to pages where the chatbot feature is not enabled. The fix ensures the chatbot properly saves its state and resumes functioning when users navigate back to supported pages, improving the overall chat experience.
Original PR description
Before this PR, the chatbot script would hang when redirected to a page where the chatbot is not enabled. When such a scenario occurs, we should restore the chatbot's state to where it stopped, and the script should continue. This PR fixes this issue.
This fix enables Odoo to properly handle Thai characters in emails from Outlook and other Windows-based systems. Previously, these systems used a Windows encoding format that Odoo couldn't recognize, which could cause Thai text to display incorrectly. The fix adds support for this encoding, ensuring emails with Thai characters are processed correctly.
Original PR description
Outlook and similar Windows based systems use windows-874 for encoding Thai characters which is not natively known by Python. Simply aliasing the Windows encoding as cp874 adds support for this encoding. opw-3684161 X-original-commit: b991b28aad38b688a45371ffd6df8b08a03d0957 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 Forward-Port-Of: odoo/odoo#160575
This update fixes a critical issue that prevented users from upgrading their system after a previous change. The fix reverts a technical modification in the website sales module to restore normal upgrade functionality. This ensures customers can successfully update their Odoo system without encountering errors.
Original PR description
After odoo/odoo#154035 users were unable to upgrade resolves https://github.com/odoo/odoo/issues/160816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where the correct form view wasn't being opened when a form contained the same x2many field twice (with one hidden). The system now properly respects the form_view_ref context setting on the visible field, ensuring users see the intended form layout when opening related records.
Original PR description
… invisible
Have a form view that has twice the same x2many field, excpet the first one is invisible=1. The second occurence has a context with the form_view_ref key.
The x2many should have at least one record.
```xml
<form>
<field name="x2m" invisible="1" />
<field name="x2m" context="{'form_view_ref': 'some_ref'}">
<tree>
<field name="display_name" />
</tree>
</field>
</form>
```
When opening a record, the context was not taken into account, yielding the wrong form view to open that record.
After this commit, the form_view_ref context key is taken into account, and the right form view opens.
opw-3845448
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