Friday, April 5, 2024
49 changes · saas-17.2
Enhancements to existing features
Error messages for automated web tour checks now combine the tour and step details with the specific failure reason. This makes it easier for teams to identify which tour failed and why, reducing investigation time in test environments.
Original PR description
In this commit, we make the error message more explicit to avoid to get the same error message for differents tours in runbot. e.g.
- Error: Tour ${tour.name} failed at step ${describeStep(step)}.
- Error: Element has been found. The error seems to be in run() To reach that, we just concatenate the two error messages in only one. e.g.
- Error: Tour ${tour.name} failed at step ${describeStep(step)}. Element has been found. The error seems to be in run()Resolved issues and error corrections
This fix updates how PDF preview files are referenced in Documents so they load correctly on common web servers such as Nginx. Users should see fewer failed PDF thumbnails or preview issues caused by server file-type handling.
Original PR description
Follow-up of odoo/odoo#151714: To avoid error like "Loading module from “/web/static/lib/pdfjs/build/pdf.mjs” was blocked because of a disallowed MIME type (“application/octet-stream”)." when JavaScript Modules using .mjs file extension are served from some common HTTP server (i.e. Nginx [1]), this commit renames PDF.js assets who uses this extension (introduced in commit [2]) to a more traditional .js extension. opw-3844829 opw-3850119 [1]: https://trac.nginx.org/nginx/ticket/2216 [2]: odoo/odoo@0216dc4f9ecef49e8b799bb0d52b59250f5f23e8
Miscellaneous changes
…the SAT - Create an invoice in prod PAC environment - Sign it - Cancel it Even if the PAC approved the cancellation, the SAT could reject it. This is because, in some cases, the partner could reject the cancellation. opw-3745401 Forward-Port-Of: odoo/enterprise#59914 Forward-Port-Of: odoo/enterprise#58657
Original PR description
…the SAT - Create an invoice in prod PAC environment - Sign it - Cancel it Even if the PAC approved the cancellation, the SAT could reject it. This is because, in some cases, the partner could reject the cancellation. opw-3745401 Forward-Port-Of: odoo/enterprise#59914 Forward-Port-Of: odoo/enterprise#58657
This fixes spreadsheet list menu actions that open related records after a change in how blank spreadsheet cells are interpreted. Users can reliably drill down from spreadsheet lists even when formulas return blank text, reducing broken or missing navigation actions.
Original PR description
Since https://github.com/odoo/odoo/commoit/e210809e, the concept of empty cell was altered. Before the aforementioned commit, an evaluated cell with the type "empty" could be empty or have a formula whose result is an empty string. Now, only really empty cells (no content) have the evaluated type "empty". Empty string result is now mapped to the "text" type. The menu actions to drilldown records were relying on the previous logic and were not properly adapted. Task: 3827310
This fix restores the warning ribbon in appointment views after an internal field name change. It helps users see relevant appointment resource warnings at the right time, avoiding missed alerts during scheduling.
Original PR description
When switching from `appointment_resource_ids` to `resource_ids` We forgot to update the associated compute methods so that they may be triggered from the relevant views. task-3813567
The settings screen now displays the correct Odoo edition by aligning the Enterprise settings display with the underlying base template. This prevents confusion for users reviewing their system edition in configuration settings.
Original PR description
Following odoo/odoo@d153638dd1a4, we must use the same template name as base template. This commit fix it so that the right edition is displayed in the settings form.
Users working in debug mode who switch away from a company can now be redirected cleanly when the current record is no longer accessible. This avoids a confusing access error and keeps behavior consistent with the standard non-debug experience.
Original PR description
… in debug mode Be logged in multiple companies (A and B) with debug mode. Be on a form view of some record which is visible only on company B via ir.rules. With the company switcher, unlog from company B. Before this commit, the user ends up on the multi-record view of that model and received an AccessError. The behaviour is different from the one when the user is not in debug mode. The user should be redirected to the multi-record view but without the AccessError.
This fixes grid scrolling for right-to-left languages, so content displays and moves correctly for users working in those layouts. It improves the experience for international users without changing existing features.
Original PR description
If an element's direction is rtl (right-to-left), then scrollLeft is 0 when the scrollbar is at its rightmost position (at the start of the scrolled content), and then increasingly negative as you scroll towards the end of the content. **Before this commit** The useVirtualGrid hook did not take that into account. **After this commit** Now it does, making use of the ABS math operator.
Changing the language from My Profile could fail when a new sales order screen was open, interrupting users with an error. This fix makes the profile language change handle unsaved records safely, so users can update their preferences without disrupting their workflow.
Original PR description
An error occurred when attempting to change the language in my profile. Steps to reproduce: - Install the ``sale_management`` and ``hr`` module - Settings / Translations / Languages - Activate any…
An error occurred when attempting to change the language in my profile.
Steps to reproduce:
- Install the ``sale_management`` and ``hr`` module
- Settings / Translations / Languages
- Activate any Language
- Open Sales / Click New / Click the profile icon / click ``My Profile``
- Change the language
Traceback:
``` ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5848, in ensure_one
_id, = self._ids
ValueError: Expected singleton: sale.order('n', 'e', 'w')
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1827, 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 1825, 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 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 739, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/action.py", line 67, in load_breadcrumbs
display_names.append(request.env[act['res_model']].browse(record_id).display_name)
File "odoo/fields.py", line 1202, in __get__
record.ensure_one()
File "odoo/models.py", line 5851, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
In line[1] we are getting the record ID as ('n', 'e', 'w') while trying to
change the language.
This commit resolves the mentioned issue by checking the type of record ID
[1] : https://github.com/odoo/odoo/blob/853bd97eda1f4eca5f9f63ef1c5909fddaa98d27/addons/web/controllers/action.py#L67
sentry - 5135218331
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where default list values in the mail module could be unintentionally shared across multiple records. Each record now gets its own default values, reducing unexpected behavior and improving reliability in messaging-related features.
Original PR description
Before this commit, the default value definition of a Record.attr() was saved once and given to all records of the given model at record creation. This meant that lists were shared between records, which is definitely an undesireable side-effect of the implementation. This commit fixes the issue by instead getting default value from usual lifecyle as a class instance.
Issue: when trying to share the spreadsheet workspace with only one document on it, instead of selecting the right view for the workspace we currently share the document view directly without giving the user any change to get to the workspace view where we are able to upload new file if allowed or see the rest of documents in the folder. Steps to reproduce: 1. Install Documents and go to Spreadsheet. 2. Create or Upload a new spreadsheet. 3. Click next to the upload button and in the dro
Original PR description
Issue: when trying to share the spreadsheet workspace with only one document on it, instead of selecting the right view for the workspace we currently share the document view directly without giving…
Issue: when trying to share the spreadsheet workspace with only one document on it, instead of selecting the right view for the workspace we currently share the document view directly without giving the user any change to get to the workspace view where we are able to upload new file if allowed or see the rest of documents in the folder. Steps to reproduce: 1. Install Documents and go to Spreadsheet. 2. Create or Upload a new spreadsheet. 3. Click next to the upload button and in the dropdown, select share to open the share popup. 4. Inside here just select the allow to download and upload documents and we click on share again. 5. Open the link in a new tab and we will see only the document already opened, without any posibility of see the entire folder or uploading a new document. Solution: Inside the `share_portal` of `SpreadsheetShareRoute` when checking for a single document, we also need to check if we are working with a selection, or if it's the folder what we want to share. opw-3688409 Forward-Port-Of: odoo/enterprise#57394
**[FIX] stock_barcode: scan only picking's (sub)loc** > Before this commit, it was possible to scan any location as the source location. > This commit fixes that and a location can be used as the source only if it's the picking's source location or one of its child locations. **[FIX] stock_barcode: Package source location** > Steps to reproduce: > - Edit internal transfers setting: -- general tab: Move entire Package "Checked" -- barcode tab: Source Location "No Scan" > - Create a new
Original PR description
**[FIX] stock_barcode: scan only picking's (sub)loc** > Before this commit, it was possible to scan any location as the source location. > This commit fixes that and a location can be used as the source only if it's the picking's source location or one of its child locations. **[FIX] stock_barcode: Package source location** > Steps to reproduce: > - Edit internal transfers setting: -- general tab: Move entire Package "Checked" -- barcode tab: Source Location "No Scan" > - Create a new storable product > - Update onhand qty: 20 package: PKG1, location: WH/Stock/Shelf 1 > - in Barcode app create a new transfer and scan PKG1 > > Bug: > the current package location is different from the default source location therefore package is ignored and an error is thrown (you are expected to scan one or more products ....) > > Fix: > check if the package is in a child location aswell > > opw-3595643 Forward-Port-Of: odoo/enterprise#59779 Forward-Port-Of: odoo/enterprise#58896
It is possible that a FEC file contains journals with different codes but same name. In such case, each of these would try to create a distinct mail alias with the same name ; this is not allowed and raised an error. We now prevent that by not generating any mail alias by default on journals imported via FEC. They can still be added later on by the user if he wishes to do so. OPW 3813584 Forward-Port-Of: odoo/enterprise#59921 Forward-Port-Of: odoo/enterprise#59527
Original PR description
It is possible that a FEC file contains journals with different codes but same name. In such case, each of these would try to create a distinct mail alias with the same name ; this is not allowed and raised an error. We now prevent that by not generating any mail alias by default on journals imported via FEC. They can still be added later on by the user if he wishes to do so. OPW 3813584 Forward-Port-Of: odoo/enterprise#59921 Forward-Port-Of: odoo/enterprise#59527
An internal transfer must not be signed in the SAT. Odoo does not allow generating a EDI document in that process, but shows all the MX fields to EDI documents. Now, the fields are not in the view for internal transfers. Forward-Port-Of: odoo/enterprise#49680 Forward-Port-Of: odoo/enterprise#42569
Original PR description
An internal transfer must not be signed in the SAT. Odoo does not allow generating a EDI document in that process, but shows all the MX fields to EDI documents. Now, the fields are not in the view for internal transfers. Forward-Port-Of: odoo/enterprise#49680 Forward-Port-Of: odoo/enterprise#42569
Steps to reproduce: ------------------- 1. Assume a user without "Project" access rights (but with "Sale" access rights) 2. Create an SO containing a service product which generates a Project & Task (or Project) on order 3. Confirm the SO 4. An access error should appear: "You are not allowed to modify 'Project' (project.project) records." ------------------- To trigger the same access error but for "Documents" access, repeat the same process but remove the "Documents" access rights of t
Original PR description
Steps to reproduce: ------------------- 1. Assume a user without "Project" access rights (but with "Sale" access rights) 2. Create an SO containing a service product which generates a Project & Task (or Project) on order 3. Confirm the SO 4. An access error should appear: "You are not allowed to modify 'Project' (project.project) records." ------------------- To trigger the same access error but for "Documents" access, repeat the same process but remove the "Documents" access rights of the user. In this case, the service product must have its "Working Template" set. task-3646545 version-16.0 Forward-Port-Of: odoo/enterprise#59794 Forward-Port-Of: odoo/enterprise#58004
This traceback will arise when the user removes the attendees while creating the new "Staff Booking". Steps to reproduce: - Install ``appointments`` - Open appointments -> Dental care - Go to new -> create appointment -> remove Attendees -> Save&Close Traceback : ```TypeError: 'bool' object is not subscriptable 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_
Original PR description
This traceback will arise when the user removes the attendees while creating the new "Staff Booking". Steps to reproduce: - Install ``appointments`` - Open appointments -> Dental care - Go to new ->…
This traceback will arise when the user removes the attendees while creating the new "Staff Booking".
Steps to reproduce:
- Install ``appointments``
- Open appointments -> Dental care
- Go to new -> create appointment -> remove Attendees -> Save&Close
Traceback :
```TypeError: 'bool' object is not subscriptable
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 38, in call_kw
return 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/appointment/models/calendar_event.py", line 392, in get_gantt_data
gantt_data['groups'] = [group for group in gantt_data['groups'] if group['partner_ids'][0] in staff_partner_ids]
File "home/odoo/src/enterprise/saas-17.1/appointment/models/calendar_event.py", line 392, in <listcomp>
gantt_data['groups'] = [group for group in gantt_data['groups'] if group['partner_ids'][0] in staff_partner_ids]
```
This commit will check for the presence of partner_ids. If they are present, it will schedule the appointment; otherwise, it will not.
sentry-4934421570
Forward-Port-Of: odoo/enterprise#60084
Forward-Port-Of: odoo/enterprise#59117Issue --> Method `_query_partners` does a search on `res.partner` which is used in the return value. This return value is then looped over in the method `_build_partner_dicts` to create the rows on the partner ledger. If the number of returned `res.partner` records exceed a certain number, there is an overutilzation of memory when getting fields id, name and trust in method `_get_report_line_partners` leading to a MemoryError when loading the partner ledger report. Solution --> Replace
Original PR description
Issue --> Method `_query_partners` does a search on `res.partner` which is used in the return value. This return value is then looped over in the method `_build_partner_dicts` to create the rows on…
Issue --> Method `_query_partners` does a search on `res.partner` which is used in the return value. This return value is then looped over in the method `_build_partner_dicts` to create the rows on the partner ledger. If the number of returned `res.partner` records exceed a certain number, there is an overutilzation of memory when getting fields id, name and trust in method `_get_report_line_partners` leading to a MemoryError when loading the partner ledger report. Solution --> Replace the `search` call with a `search_fetch` call and store the specific field values in cache. This prevents the fetch of the field values. Flamegraph before  After  Peak memory utilization reduced from 1.9GB to 1.3GB for about 150k `res.partner` records opw-3785731 Forward-Port-Of: odoo/enterprise#59948
Steps to reproduce: ------------------- - in My Timesheet, click on start; - add a project, a task and a description; - click on search icon in the grid (magnifying glass); Issue: ------ The list view never opens. Cause: ------ When the component performs the `onWillStart` hook, we add the timesheet with the current timer and put it into edit mode. This will have the effect of making a new render (destroy the component and create a new one). This will create a new component and re
Original PR description
Steps to reproduce: ------------------- - in My Timesheet, click on start; - add a project, a task and a description; - click on search icon in the grid (magnifying glass); Issue: ------ The list view never opens. Cause: ------ When the component performs the `onWillStart` hook, we add the timesheet with the current timer and put it into edit mode. This will have the effect of making a new render (destroy the component and create a new one). This will create a new component and repeat the process. Solution: --------- Let the component load the timesheet during the `onWillStart` but manage the edit mode during the `onMounted` hook. opw-3788661 Forward-Port-Of: odoo/enterprise#59896
…bles In a report (DIN5008 layout for example), have an invalid table -- containing "t" nodes where HTML doesn't expect them, within another invalid table. Before this commit, all the tables were not converted to classic div elements, and other conversions were wrongly applied. After this commit, all tables are converted, leaving other irrelevant nodes untouched. opw-3741137 Forward-Port-Of: odoo/enterprise#60090
Original PR description
…bles In a report (DIN5008 layout for example), have an invalid table -- containing "t" nodes where HTML doesn't expect them, within another invalid table. Before this commit, all the tables were not converted to classic div elements, and other conversions were wrongly applied. After this commit, all tables are converted, leaving other irrelevant nodes untouched. opw-3741137 Forward-Port-Of: odoo/enterprise#60090
[[BUG][17.0] viin_sales_unlink- Xảy ra lỗi khi xóa SO](https://viindoo.com/web#id=51865&cids=1&menu_id=289&model=viin.helpdesk.ticket&view_type=form) - This PR - - Fix bug when delete SO **Step** - Create SO - Confirm SO, add delivered If the product is a warehouse product - Create Invoice - Delete Invoice - Cancel SO - Delete SO **Output** - Displays the error totals.subtotals order is not iterable **Reason** - When unlink SO, tax value no longer exists, so, return
Original PR description
[[BUG][17.0] viin_sales_unlink- Xảy ra lỗi khi xóa SO](https://viindoo.com/web#id=51865&cids=1&menu_id=289&model=viin.helpdesk.ticket&view_type=form) - This PR - - Fix bug when delete SO **Step** - Create SO - Confirm SO, add delivered If the product is a warehouse product - Create Invoice - Delete Invoice - Cancel SO - Delete SO **Output** - Displays the error totals.subtotals order is not iterable **Reason** - When unlink SO, tax value no longer exists, so, return value of totals is false, and when try loop totals.subtotals_order (undefine value) will be display this error **Solution** - Check the total input value. If there is no value or the return value is false, return it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159018
…arch view Description of the issue/feature this PR addresses: The closed ("paid") filter in the search view does not consider the reversed state and is technically closed. Current behavior before PR: Currently, when you select the "paid" and "unpaid" filters on the invoices list, it does not provide a complete view of all the universe of invoices as the reversed status is not reflected within its domain. Desired behavior after PR is merged: I propose that the closed ("paid") filter
Original PR description
…arch view
Description of the issue/feature this PR addresses:
The closed ("paid") filter in the search view does not consider the reversed state and is technically closed.
Current behavior before PR:
Currently, when you select the "paid" and "unpaid" filters on the invoices list, it does not provide a complete view of all the universe of invoices as the reversed status is not reflected within its domain.
Desired behavior after PR is merged:
I propose that the closed ("paid") filter takes into account the reversed state. Consequently, upon selecting both "paid" and "unpaid" filters, it should present a complete universe of invoices.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#154204Add a bunch of QOL improvements in the results page design: NB: In order to stay stable-compatible, using "d-none" to hide elements and using the "fs-x" class to resize the texts instead of changing the header tags. - Display the survey results page in half page size to prevent having too much blank space between the tables columns - The filter buttons are now displayed under the survey title - Show the leaderboard bar on the print preview - Changing the eye dropdown icon to a caret for
Original PR description
Add a bunch of QOL improvements in the results page design: NB: In order to stay stable-compatible, using "d-none" to hide elements and using the "fs-x" class to resize the texts instead of changing…
Add a bunch of QOL improvements in the results page design: NB: In order to stay stable-compatible, using "d-none" to hide elements and using the "fs-x" class to resize the texts instead of changing the header tags. - Display the survey results page in half page size to prevent having too much blank space between the tables columns - The filter buttons are now displayed under the survey title - Show the leaderboard bar on the print preview - Changing the eye dropdown icon to a caret for fold/unfold - Align questions to the left to be on the same level as the sections - Add an horizontal scroll to the matrix and simple/multiple choices tables when the screen is not wide enough to display all the data - Reduce vertical spacing between elements to gain space - Reduce simple/multiple choices tables line height - Reduce survey title, section title and KPIs font size - Display the "Correct", "Partial", "Responded" and "Skipped" badges on a single line and set a rounded border around. - Removing the "Result Overview" title - Removing survey description, section description and question description Task-3707687 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152263
Currently, a traceback appears when you attempt to generate a Facturae document for a credit note created manually. ### Steps to reproduce * install `l10n_es_edi_facturae` * create a credit not manually (not from an invoice) * confirm and attempt to generate the Facturae EDI file You should be me with a traceback: `ValueError: not enough values to unpack (expected 1, got 0)` ### Cause To generate the EDI document, the system needs the credit note to have a link to the refunded
Original PR description
Currently, a traceback appears when you attempt to generate a Facturae document for a credit note created manually. ### Steps to reproduce * install `l10n_es_edi_facturae` * create a credit not manually (not from an invoice) * confirm and attempt to generate the Facturae EDI file You should be me with a traceback: `ValueError: not enough values to unpack (expected 1, got 0)` ### Cause To generate the EDI document, the system needs the credit note to have a link to the refunded invoice. However, in this case, there's no invoice since the credit note was created manual. opw-3786219 opw-3772085 opw-3811170 Forward-Port-Of: odoo/odoo#158283
Steps to reproduce: - Open the project in mobile view - go to the kanban view enable task stages - add one new staged with large name you can see name is misaligned Issue: - In mobile view task stage name is misaligned Solution: - Adding class 'o_text_overflow' to not overflow name in kanban view task-3602610 Forward-Port-Of: odoo/odoo#145915
Original PR description
Steps to reproduce: - Open the project in mobile view - go to the kanban view enable task stages - add one new staged with large name you can see name is misaligned Issue: - In mobile view task stage name is misaligned Solution: - Adding class 'o_text_overflow' to not overflow name in kanban view task-3602610 Forward-Port-Of: odoo/odoo#145915
Add a test for exporting the source terms of modules. This will allow automated scripts to fetch latest terms Backport save_test_file with a parameter on date_format to have predictable filenames Forward-Port-Of: odoo/odoo#159846 Forward-Port-Of: odoo/odoo#154624
Original PR description
Add a test for exporting the source terms of modules. This will allow automated scripts to fetch latest terms Backport save_test_file with a parameter on date_format to have predictable filenames Forward-Port-Of: odoo/odoo#159846 Forward-Port-Of: odoo/odoo#154624
Description of the issue/feature this PR addresses: module: hr_recruitment_survey Current behavior before PR: when retaking the survey, the survey input not map with the applicant id, so if you retake 5 time, only the 1st survey has value of applicant_id Desired behavior after PR is merged: all survey retakes have the same applicant id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159833
Original PR description
Description of the issue/feature this PR addresses: module: hr_recruitment_survey Current behavior before PR: when retaking the survey, the survey input not map with the applicant id, so if you retake 5 time, only the 1st survey has value of applicant_id Desired behavior after PR is merged: all survey retakes have the same applicant id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159833
At the moment, the partner being used to get the information for the efaktur module is the partner set on the invoice. This is wrong, since if the partner set on the invoice is a child record of a company partner you cannot set most of these fields. To fix this issue, we will update in order to fetch the efaktur related fields from the commercial partner instead. (vat, along with all efaktur specific information used in the process) --- I confirm I have signed the CLA and read the PR g
Original PR description
At the moment, the partner being used to get the information for the efaktur module is the partner set on the invoice. This is wrong, since if the partner set on the invoice is a child record of a company partner you cannot set most of these fields. To fix this issue, we will update in order to fetch the efaktur related fields from the commercial partner instead. (vat, along with all efaktur specific information used in the process) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160192 Forward-Port-Of: odoo/odoo#160108
Currently when a time off using an overtime is written to for any reason, it will compare the duration of the overtime with the number_of_hours_display. However, the duration check will always be triggered since overtime duration is number_of_hours_display * -1 This causes problems if an overtime time off is modified for any reason and the employee does not have enough total_overtime --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of:
Original PR description
Currently when a time off using an overtime is written to for any reason, it will compare the duration of the overtime with the number_of_hours_display. However, the duration check will always be triggered since overtime duration is number_of_hours_display * -1 This causes problems if an overtime time off is modified for any reason and the employee does not have enough total_overtime --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160055
-Before this commit the url is like /blog/1/feed then it will become a redirect 301 url to /blog/travel-1/feed which is not good for SEO. Therefore we change to slug(blog) to ensure no redirect occur 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#160503 Forward-Port-Of: odoo/odoo#160438
Original PR description
-Before this commit the url is like /blog/1/feed then it will become a redirect 301 url to /blog/travel-1/feed which is not good for SEO. Therefore we change to slug(blog) to ensure no redirect occur 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#160503 Forward-Port-Of: odoo/odoo#160438
Before this commit: Using the "Download logs" button from the IoT box form view will fail every time due to an Internal Server Error on the IoT side. ```py File "/home/pi/odoo/odoo/tools/misc.py", line 189, in file_path FileNotFoundError: File not found: /var/log/odoo/odoo-server.log ``` This happened due to changes introduced in: https://github.com/odoo/odoo/pull/99658 The changes enforced to double check that the file path was in an odoo addons (for security reasons). However, it
Original PR description
Before this commit: Using the "Download logs" button from the IoT box form view will fail every time due to an Internal Server Error on the IoT side. ```py File "/home/pi/odoo/odoo/tools/misc.py", line 189, in file_path FileNotFoundError: File not found: /var/log/odoo/odoo-server.log ``` This happened due to changes introduced in: https://github.com/odoo/odoo/pull/99658 The changes enforced to double check that the file path was in an odoo addons (for security reasons). However, it is generally not the case, thus the error After this commit: The log file is downloaded as intended opw-3827121 Forward-Port-Of: odoo/odoo#159186
Current behaviour: --- When you generate a Delivery Slip for a list of kit and non kit products with no backorder, kit and non kit products get mixed. ie: there are kit products in the section "products not associated with a kit" Steps to reproduce: --- 1. Create 4 products (K1,P1,P2,C1,C2) 2. Create a Bills of Materials for K1 3. Set Type as Kit 4. Add C1 and C2 as components 5. Create a sale quotation for K1, P1, P2 6. Set the quantity at 4 for all products 7. On the quotation,
Original PR description
Current behaviour: --- When you generate a Delivery Slip for a list of kit and non kit products with no backorder, kit and non kit products get mixed. ie: there are kit products in the section…
Current behaviour: --- When you generate a Delivery Slip for a list of kit and non kit products with no backorder, kit and non kit products get mixed. ie: there are kit products in the section "products not associated with a kit" Steps to reproduce: --- 1. Create 4 products (K1,P1,P2,C1,C2) 2. Create a Bills of Materials for K1 3. Set Type as Kit 4. Add C1 and C2 as components 5. Create a sale quotation for K1, P1, P2 6. Set the quantity at 4 for all products 7. On the quotation, click on Delivery 8. In Done, put 4 for P1 and 3 for C1,C2,P2 9. Validate and select No Backorder 10. Click on Print, Delivery Slip 11. In the document: 12. P2 is in the kit section (K1) 13. C1,C2 in the "not associated with a kit" section Expected behaviour: --- Only C1 and C2 should be in the K1 section Only P1 and P2 should be in the "Products not associated with a kit" section opw-3568390 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159138 Forward-Port-Of: odoo/odoo#144276
**Steps to reproduce the bug:** - Create a storable product “P1” and "P2": - Weight "P1": 1kg - Weight "P2": 2kg - Create a picking with the product “P1” - Change the product of the move to “P2” Problem: The picking weight is not updated opw-[3754884](https://www.odoo.com/web#id=3754884&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#159997 Forward-Port-Of: odoo/odoo#159722
Original PR description
**Steps to reproduce the bug:**
- Create a storable product “P1” and "P2":
- Weight "P1": 1kg
- Weight "P2": 2kg
- Create a picking with the product “P1”
- Change the product of the move to “P2”
Problem:
The picking weight is not updated
opw-[3754884](https://www.odoo.com/web#id=3754884&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#159997
Forward-Port-Of: odoo/odoo#159722Currently some VAT examples that contain other terms than only the number are always displayed in English. This commit makes sure they can be translated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159724 Forward-Port-Of: odoo/odoo#158629
Original PR description
Currently some VAT examples that contain other terms than only the number are always displayed in English. This commit makes sure they can be translated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159724 Forward-Port-Of: odoo/odoo#158629
- replace order summary by a dropdown like mobile view - remove 'Pay With' title - match 'Choose delivery method' style with 'Choose payment method' - make order summary sticky so that 'Pay now' is always accessible task-3741412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160415 Forward-Port-Of: odoo/odoo#154035
Original PR description
- replace order summary by a dropdown like mobile view - remove 'Pay With' title - match 'Choose delivery method' style with 'Choose payment method' - make order summary sticky so that 'Pay now' is always accessible task-3741412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160415 Forward-Port-Of: odoo/odoo#154035
- menu combo will not ask to select an item, if there only one in the category. - self-order do not show last screen with order number, when prices = 0.00. - kiosk: close button too small: we don't notice it on large screens as it's not where we look. before:  after:  - 30 sec to close
Original PR description
- menu combo will not ask to select an item, if there only one in the category. - self-order do not show last screen with order number, when prices = 0.00. - kiosk: close button too small: we don't…
- menu combo will not ask to select an item, if there only one in the category. - self-order do not show last screen with order number, when prices = 0.00. - kiosk: close button too small: we don't notice it on large screens as it's not where we look. before:  after:  - 30 sec to close the "ticket number" screen since 5 minutes is too long. - self: My Orders outline with semi transparent background. before:  after:  - self: order date on closed orders. - fix: when you select a product with a variant but do not choose a variant and click on "discard" it is no longer possible to cancel the order and return to the home page. Task-3801901 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159623
Currently, in Russian, the variable 'field' is translated into Russian as 'поле' which causes an error. Error: `KeyError: 'поле'` This commit fixes this issue by updating the translated variable into the original variable. sentry-5141195219
Original PR description
Currently, in Russian, the variable 'field' is translated into Russian as 'поле' which causes an error. Error: `KeyError: 'поле'` This commit fixes this issue by updating the translated variable into the original variable. sentry-5141195219
Before this commit, when the clickbot detected an error dialog, it stopped the test and throw an error saying that an error dialog was detected. This information is not enough to check why, and how, the error dialog was produced. Now, we also log the content of the error dialog as well as all the information of the last rpc that was in error. closes odoo/odoo#160103 X-original-commit: 4f26b324a30c5120ea60b6b42fef6cd6000d2859 Forward-Port-Of: odoo/odoo#160336 Forward-Port-Of: odoo/odoo#
Original PR description
Before this commit, when the clickbot detected an error dialog, it stopped the test and throw an error saying that an error dialog was detected. This information is not enough to check why, and how, the error dialog was produced. Now, we also log the content of the error dialog as well as all the information of the last rpc that was in error. closes odoo/odoo#160103 X-original-commit: 4f26b324a30c5120ea60b6b42fef6cd6000d2859 Forward-Port-Of: odoo/odoo#160336 Forward-Port-Of: odoo/odoo#160272
**Steps to reproduce:** 1- Create a purchase order and assign a project to its Analytic distribution 2- Go to the assigned project's 'Project Updates' 3- Click on Purchase order smart button **Current behavior before PR:** When trying to view the purchase orders linked to a project you will either get a message saying this ID doesn't exist or you will get an empty list view. This is happening because we are fetching the purchase order line ids and passing those ids to the view not the
Original PR description
**Steps to reproduce:** 1- Create a purchase order and assign a project to its Analytic distribution 2- Go to the assigned project's 'Project Updates' 3- Click on Purchase order smart button **Current behavior before PR:** When trying to view the purchase orders linked to a project you will either get a message saying this ID doesn't exist or you will get an empty list view. This is happening because we are fetching the purchase order line ids and passing those ids to the view not the ids for the purchase order itself https://github.com/odoo/odoo/blob/saas-17.1/addons/project_purchase/models/project_project.py#L31:L33 **Desired behavior after PR is merged:** We are now passing the ids of the purchase order to the view. opw-3794848 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159345
The aim of this commit is to prevent the statistical error detection to interupt automated flow. From now on, the error detection wizard on `action_post` will only be triggered for manually created invoice. Context: Payments made through our website wouldn't be reconcile with their invoice because the flow supposed to post the invoice silently failed due to the `validate.account.move` wizard being returned by `action_post`. Before this commit: To be able to pass the error detection te
Original PR description
The aim of this commit is to prevent the statistical error detection to interupt automated flow. From now on, the error detection wizard on `action_post` will only be triggered for manually created invoice. Context: Payments made through our website wouldn't be reconcile with their invoice because the flow supposed to post the invoice silently failed due to the `validate.account.move` wizard being returned by `action_post`. Before this commit: To be able to pass the error detection test with an automated flow, you needed to setup a context key. That meant setting the context key anywhere an automated action could take place. After this commit: The automated detection error wizard `validate.account.move` will only be brought up through the `action_post` where the key is explicitely set. opw-3830725 Forward-Port-Of: odoo/odoo#160384
- Create a Partner who is a valid Peppol participant - Clear their UBL format - they are still displayed as valid (Bug 1) - Create an invoice for that partner and confirm it. The Peppol state changes to 'ready' - Erase eas or endpoint on that partner and verify - the partner is now not a valid Peppol participant - Reset the invoice to draft, confirm again: the peppol move state is still `ready` (Bug 2) 1. Do not set a participant as valid if a peppol-incompatible edi format has been selec
Original PR description
- Create a Partner who is a valid Peppol participant - Clear their UBL format - they are still displayed as valid (Bug 1) - Create an invoice for that partner and confirm it. The Peppol state changes to 'ready' - Erase eas or endpoint on that partner and verify - the partner is now not a valid Peppol participant - Reset the invoice to draft, confirm again: the peppol move state is still `ready` (Bug 2) 1. Do not set a participant as valid if a peppol-incompatible edi format has been selected 2. Only save Peppol move state if it's processing/done already. Otherwise, let users clear it by resetting to draft. (until we implement giving them control over this field) opw-3784945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160591 Forward-Port-Of: odoo/odoo#159852
**Current behavior:** Creating an ewallet loyalty program and removing the default value for `trigger_product_ids` without adding another in its place will result in any ewallet created using that program to not have its balance deducted after being used in a sale order. **Expected behavior:** The default product should not be required here, nor should any product, seeing as there is no `required` constraint on this field nor any related ones. **Steps to reproduce:** 1. Create an e
Original PR description
**Current behavior:** Creating an ewallet loyalty program and removing the default value for `trigger_product_ids` without adding another in its place will result in any ewallet created using that…
**Current behavior:**
Creating an ewallet loyalty program and removing the default
value for `trigger_product_ids` without adding another in its
place will result in any ewallet created using that program to
not have its balance deducted after being used in a sale order.
**Expected behavior:**
The default product should not be required here, nor should any
product, seeing as there is no `required` constraint on this
field nor any related ones.
**Steps to reproduce:**
1. Create an ewallet loyalty program and remove the Top-up
ewallet product
2. Create an ewallet, give it some balance, and use it in an
order
3. Check the balance of the wallet to see the erroneous behavior
**Cause of the issue:**
In the _program_check_compute_points() method of `sale.order` in
`sale_loyalty`, the conditional block:
`if not products_per_rule.get(rule):
continue`
will normally prevent rules belonging to ewallet program types
from going further in the method because they have the default
ewallet top-up product in their domain. When the continue is not
reached, they will reach this line:
`amount_paid = sum(max(0, line.price_total) for
line in order_lines if line.product_id in rule_products)`
which will end up offsetting the actual subtraction of a SOLs
`points_cost` from an ewallet `loyalty.card`'s balance.
**Fix:**
Add another check prior to the calculation of order points which
prevents orders with applied ewallet coupons without any top-up
products from reaching the problematic code. If an ewallet
program doesn't have any `trigger_product_ids`, it shouldn't
ever need to perform such calculations.
opw-3756134
Forward-Port-Of: odoo/odoo#157421This is done together with an enterprise commit in order to avoid creating mail alias automatically on journals imported via FEC files, in France. Indeed, such files could contain journals with different codes but same name, each of which would try creating an alias with the same name, raising an error. OPW 3813584 Forward-Port-Of: odoo/odoo#160168 Forward-Port-Of: odoo/odoo#159455
Original PR description
This is done together with an enterprise commit in order to avoid creating mail alias automatically on journals imported via FEC files, in France. Indeed, such files could contain journals with different codes but same name, each of which would try creating an alias with the same name, raising an error. OPW 3813584 Forward-Port-Of: odoo/odoo#160168 Forward-Port-Of: odoo/odoo#159455
[FIX] portal: display avatar when read access right are fulfilled Steps to reproduce the bug: - Enable the comments on a blog. - Add a comment. -> Problem: The avatar of the comment is the default placeholder image. The problem appears since [1]. This commit was created to bypass the read access of an image if a correct `token` was provided in the dataset of the `.o_portal_chatter` element. The problem is that since [1], if the `.o_portal_chatter` element does not have a `token` (o
Original PR description
[FIX] portal: display avatar when read access right are fulfilled Steps to reproduce the bug: - Enable the comments on a blog. - Add a comment. -> Problem: The avatar of the comment is the default…
[FIX] portal: display avatar when read access right are fulfilled Steps to reproduce the bug: - Enable the comments on a blog. - Add a comment. -> Problem: The avatar of the comment is the default placeholder image. The problem appears since [1]. This commit was created to bypass the read access of an image if a correct `token` was provided in the dataset of the `.o_portal_chatter` element. The problem is that since [1], if the `.o_portal_chatter` element does not have a `token` (or a `hash` and a `pid` since [2]) in its dataset, the avatar images are displayed as the default placeholder image by default. The goal of this commit is to correct this behavior; if there is no token provided, the previously used `/web/image` route is used to show the avatar. Thanks to this route, the avatar is displayed if the read access is fulfilled. If it is not the case, the default placeholder image is displayed. [1]: https://github.com/odoo/odoo/commit/d4eb996cd3caea3fbb822437057a6a5a8a722293 [2]: https://github.com/odoo/odoo/commit/7f69708bcce3b3c4b096d89cb0ec354998eac191 opw-3749422 Forward-Port-Of: odoo/odoo#160240 Forward-Port-Of: odoo/odoo#157652
Steps: - Install project app. - Share a project which contains a task and sub-task and project should have allow milestone - Go to task form in project sharing. - Go to milestone field of sub-task page. Issue: - Milestone field has can create and can open options enable and because of that portal user able to create edit or open milestone and which leads to tracebacks Cause: - There was no options added to prevent those attribute from that field for project sharing views. Fix: -
Original PR description
Steps: - Install project app. - Share a project which contains a task and sub-task and project should have allow milestone - Go to task form in project sharing. - Go to milestone field of sub-task page. Issue: - Milestone field has can create and can open options enable and because of that portal user able to create edit or open milestone and which leads to tracebacks Cause: - There was no options added to prevent those attribute from that field for project sharing views. Fix: - Added option to prevent those operation for project sharing view. Note: Add this options in blockby page in FW port. task-3764782 Forward-Port-Of: odoo/odoo#160514 Forward-Port-Of: odoo/odoo#155358
At the moment, duplicating a website is not possible in the sense of duplicating content, pages, etc. It is still available as an action from the form view, and it could make sense to start up a new website with a few common values (social media? etc?)... but many of website fields are technical fields that should not be copied and many are dubious to copy and not even visible in the form view. Really, duplicating a website at the moment is misleading. This commit disables the possibility from t
Original PR description
At the moment, duplicating a website is not possible in the sense of duplicating content, pages, etc. It is still available as an action from the form view, and it could make sense to start up a new website with a few common values (social media? etc?)... but many of website fields are technical fields that should not be copied and many are dubious to copy and not even visible in the form view. Really, duplicating a website at the moment is misleading. This commit disables the possibility from the form view. In the future, we want to focus on the ability to export / import a full website, but that's not for now. opw-3782830 Forward-Port-Of: odoo/odoo#160463
Problem: When the user sets a warning message for a product, the message will always display even if the warning type is no-message. Purpose: The product's warning message should not display if the warning type is no message. Steps to Reproduce on Runbot17: 1.Install Sales 2.Enable Sale Warnings in Setting > Sales 3.Modify the sale warnings for a product 4.Create a quotation 5.Click on the catalog and look for the modified product 6.Observe the warning opw-3806520 Description of
Original PR description
Problem: When the user sets a warning message for a product, the message will always display even if the warning type is no-message. Purpose: The product's warning message should not display if the warning type is no message. Steps to Reproduce on Runbot17: 1.Install Sales 2.Enable Sale Warnings in Setting > Sales 3.Modify the sale warnings for a product 4.Create a quotation 5.Click on the catalog and look for the modified product 6.Observe the warning opw-3806520 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#159795
### Issue When handling a non-200 reponse with a large payload (>65536 bytes), download.js fails to decode the payload properly on Chrome/WebKit. This is because the content is parsed using WebKit's `DOMParser.parseFromString`, which creates several Text nodes if the text would exceed 65536 bytes. Then, only the textContent of the second Text node is passed to `JSON.parse()`, which fails because it is not valid JSON. See [this StackOverflow comment](https://stackoverflow.com/questions/6
Original PR description
### Issue When handling a non-200 reponse with a large payload (>65536 bytes), download.js fails to decode the payload properly on Chrome/WebKit. This is because the content is parsed using WebKit's…
### Issue When handling a non-200 reponse with a large payload (>65536 bytes), download.js fails to decode the payload properly on Chrome/WebKit. This is because the content is parsed using WebKit's `DOMParser.parseFromString`, which creates several Text nodes if the text would exceed 65536 bytes. Then, only the textContent of the second Text node is passed to `JSON.parse()`, which fails because it is not valid JSON. See [this StackOverflow comment](https://stackoverflow.com/questions/67738121/in-what-cases-do-browsers-create-multiple-adjacent-text-nodes/67774415#67774415) and [the WebKit code](https://github.com/WebKit/WebKit/blob/68ae0fde5f959e056fbd6700f1ca7fa652cd1ffa/Source/WebCore/html/parser/HTMLConstructionSite.cpp#L584-L592) ### Steps to reproduce This example works only in 17.1 and master due to the larger files now generated by the Romanian SAF-T export. However, you can reproduce it in any version by raising an InternalServerError with a response content larger than 65536 bytes in any controller called by `download()`. 1. Install l10n_ro_saft on a 17.1 database 2. Switch to 'RO Company' 3. Go to partner 'Azure Interior' and remove the address details (this will make the report generation return an error containing the report content) 4. Go to Accounting -> Reports -> General Ledger 5. Click on the arrow next to 'PDF' and click on 'SAF-T'. taskid: 3790302 Forward-Port-Of: odoo/odoo#160577 Forward-Port-Of: odoo/odoo#156672
- Add new tax groups for VAT at 5%, 13%, and 15% - Add taxes of 5% and 15% - Archive VAT taxes of 5% in sales and 12% - Configure tax group accounts for the new tax groups - Add new foreign account tax position tax template at 15% VAT 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#160020 F
Original PR description
- Add new tax groups for VAT at 5%, 13%, and 15% - Add taxes of 5% and 15% - Archive VAT taxes of 5% in sales and 12% - Configure tax group accounts for the new tax groups - Add new foreign account tax position tax template at 15% VAT 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#160020 Forward-Port-Of: odoo/odoo#159596
In 2024 the SRI changes income withholding taxes. We update minor data and create new taxes for the new percentages Forward-Port-Of: odoo/odoo#157912 Forward-Port-Of: odoo/odoo#156740
Original PR description
In 2024 the SRI changes income withholding taxes. We update minor data and create new taxes for the new percentages Forward-Port-Of: odoo/odoo#157912 Forward-Port-Of: odoo/odoo#156740