Monday, April 29, 2024
17 changes · master
Enhancements to existing features
Shoppers who return from a product page to the shop page are now brought back to the exact spot they were browsing instead of the top of the page. This makes browsing large catalogs smoother and reduces frustration during shopping.
Original PR description
Before this commit: When users navigated back from a product page using the breadcrumb or the back button of the browser to the /shop, they were redirected to the top of the /shop page. This was frustrating for users browsing a large catalog, as it disrupted their current shopping flow. After this commit: When a user navigates back to the /shop page from a product page, s/he is taken back to the location from exactly where s/he left off. This thing aids in better user experience. task-3277056
This update modernizes internal tests for form dialog behavior in the web module. It helps maintain product quality and reduces the risk of future regressions without changing the user experience.
Original PR description
task-3705027 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 modernizes internal tests for the selection and creation dialog in the web module. It helps maintain quality and reliability for a common interface component without changing the user-facing behavior.
Original PR description
task-3705027 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
Resolved issues and error corrections
Projects created from templates through service product sales now bring back archived tasks as active tasks, so teams see the full planned work after confirming a quotation. Manually duplicating an archived project also restores its tasks, while keeping task status where appropriate, reducing missed work in copied projects.
Original PR description
When a project template have some archived task and a (service) product template duplicate the project, the tasks are copied on quotation confirm but the archived one remain archived. To reproduce behavior: - Install `sale_project` - Create a billable project as template - Create steps and tasks (archive at least one task) - Create a service product with create project & task on order then select your project template - Create a quotation with the product freshly created and confirm it - Go tho the Project created for SO and see that the (archived) tasks are not unarchived. task-3525361 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Commit [1] made a mistake when adapting the `guardedCatch` handler. [1]: https://github.com/odoo/odoo/commit/fcb16a3b1bd373726ffb54f0fbe41fb6d1784769 Forward-Port-Of: odoo/odoo#163486
Original PR description
Commit [1] made a mistake when adapting the `guardedCatch` handler. [1]: https://github.com/odoo/odoo/commit/fcb16a3b1bd373726ffb54f0fbe41fb6d1784769 Forward-Port-Of: odoo/odoo#163486
Corrected a typo in the web tour service to help the guided tour feature work as intended. This is a small maintenance fix that reduces the chance of errors in product walkthroughs or onboarding flows.
An error occurred when attempting to change the language in my profile and clicking on save. 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 / Click on ``Save`` Traceback: ``` ValueError: too many values to unpack (expected 1) File "odoo/models.py", line 5848, in ensure_one _id, = self._ids Valu
Original PR description
An error occurred when attempting to change the language in my profile and clicking on save. Steps to reproduce: - Install the ``sale_management`` and ``hr`` module - Settings / Translations /…
An error occurred when attempting to change the language in my profile and clicking on save.
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 / Click on ``Save``
Traceback:
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5848, in ensure_one
_id, = self._ids
ValueError: Expected singleton: product.template('n', 'e', 'w')
File "odoo/http.py", line 2254, in __call__
response = request._serve_db()
File "odoo/http.py", line 1830, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1850, 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 1828, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1835, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2060, 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 742, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/action.py", line 69, 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 received the record ID as ('n', 'e', 'w') while attempting
to change the language, resulting in the page being refreshed.
This commit resolves the mentioned issue by appending ``New`` in breadcrumbs if 'record_id' is 'new'.
[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-pr
Forward-Port-Of: odoo/odoo#163087Before this commit, when a service throw an error when starting, the makeMockEnv does not register a cleanup for the created env and the next tests would crash because an env already exists. After this commit, the cleaner is registered just after the env creation to be sure it will be executed. Forward-Port-Of: odoo/odoo#163471
Original PR description
Before this commit, when a service throw an error when starting, the makeMockEnv does not register a cleanup for the created env and the next tests would crash because an env already exists. After this commit, the cleaner is registered just after the env creation to be sure it will be executed. Forward-Port-Of: odoo/odoo#163471
Steps to Reproduce on Runbot: - Install MRP - Create a second warehouse - Go to Warehouse -> Routes -> Manufacturing. - Set the "Supplied Warehouse" to the first warehouse. - In Inventory > Opertaions > Replenishment - Create a new Replenishment with Manufacturing route - click on Replenishment information (small "i" button) - Expected singelton traceback error. Fix: get_lead_time in Manufacturing expects a single rule using _get_rule to determine the correct rule as the comment sug
Original PR description
Steps to Reproduce on Runbot: - Install MRP - Create a second warehouse - Go to Warehouse -> Routes -> Manufacturing. - Set the "Supplied Warehouse" to the first warehouse. - In Inventory > Opertaions > Replenishment - Create a new Replenishment with Manufacturing route - click on Replenishment information (small "i" button) - Expected singelton traceback error. Fix: get_lead_time in Manufacturing expects a single rule using _get_rule to determine the correct rule as the comment suggested opw-3838099 Forward-Port-Of: odoo/odoo#163318
Previously, when receiving a new email to create a job applicant for an existing partner, the process would inadvertently erase the phone and mobile numbers on the partner by using the inverse method. With this commit, the behavior is adjusted so that phone numbers are only written in the inverse method on the partner if there is a number present on the applicant. This prevents the inadvertent removal of phone numbers on the partner when creating new applicants for existing partners. Add
Original PR description
Previously, when receiving a new email to create a job applicant for an existing partner, the process would inadvertently erase the phone and mobile numbers on the partner by using the inverse…
Previously, when receiving a new email to create a job applicant for an existing partner, the process would inadvertently erase the phone and mobile numbers on the partner by using the inverse method. With this commit, the behavior is adjusted so that phone numbers are only written in the inverse method on the partner if there is a number present on the applicant. This prevents the inadvertent removal of phone numbers on the partner when creating new applicants for existing partners. Additionally, this commit ensures that phone numbers from the partner are computed on the applicant as if they were related non-stored fields. This avoids the need for manual re-encoding of numbers later and prevents the inverse method from being forced again. Furthermore, to optimize the process, email changes are now only processed using the inverse method if the normalized version of the email is different. This prevents unnecessary method calls on the highly used res.partner model when the email is updated, particularly for cases where the normalized version remains the same. Previously, changing the partner's email from `jke@odoo.com` to `"JKE" jke@odoo.com` would resend all waiting sign requests because the normalized versions of the email were distinct. While ideally, this check could be performed within the sign request code itself, this optimization now helps prevent unnecessary overrides across all modules simultaneously. 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#163495
We are in the context of anglo-saxon accounting, when selling a product having an automated valuation. The invoice linked to the `pos.order` should have its stock output line reconciled with its counterpart in the stock valuation journal. That is what happens if you create the invoice directly from point of sale. Currently, if you do not create the invoice, keep the session open and then click the "Invoice" button on the pos order, the stock output line will not be reconciled. This
Original PR description
We are in the context of anglo-saxon accounting, when selling a product having an automated valuation. The invoice linked to the `pos.order` should have its stock output line reconciled with its counterpart in the stock valuation journal. That is what happens if you create the invoice directly from point of sale. Currently, if you do not create the invoice, keep the session open and then click the "Invoice" button on the pos order, the stock output line will not be reconciled. This happens because in `action_pos_order_invoice`, the picking is created after the invoice. But the reconciliation happens when creating the invoice. As it doesn't have its valuation counterpart yet (which is created from the picking), it then do not reconcile with anything. The fix here is to create the picking before. opw-3702345 Forward-Port-Of: odoo/odoo#162594 Forward-Port-Of: odoo/odoo#154595
See discussions on https://github.com/odoo/odoo/pull/85494/. TLDR: webp image format needs to be supported, but we should avoid going through the Pillow library as it is largely unsafe for that format. jpg attachment are created in JS at upload time. Wkhtmltopdf doesn't support webp, so, in reports, we should display one of those jpg copies This work is handled by `ir.qweb: _get_converted_image_data_uri` which is used as: ```xml <img src="image_data_uri(some_b64value)" /> ``` The mentionn
Original PR description
See discussions on https://github.com/odoo/odoo/pull/85494/. TLDR: webp image format needs to be supported, but we should avoid going through the Pillow library as it is largely unsafe for that…
See discussions on https://github.com/odoo/odoo/pull/85494/. TLDR: webp image format needs to be supported, but we should avoid going through the Pillow library as it is largely unsafe for that format. jpg attachment are created in JS at upload time. Wkhtmltopdf doesn't support webp, so, in reports, we should display one of those jpg copies This work is handled by `ir.qweb: _get_converted_image_data_uri` which is used as: ```xml <img src="image_data_uri(some_b64value)" /> ``` The mentionned PR did not however adapt the ir.qweb.field.image that, when passed the option `qweb_img_raw_data` should return a base64 url such as `data:[mimetype],base64,[datas]`. usage: ```xml <span t-field="object.image_field" t-options-qweb_img_raw_data="1" /> ``` Hence, before this commit, there was a crash as we tried to pass that value to PIL. After this commit, there is no crash, and the image displays correctly as JPG in the PDF opw-3859423 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#161931
Since commit 7d2baaa0c726a7b0dd4fe7226862f960c9c59b73 ("Unity read"), we are able to pass a full specification to subfields in a view and retrive records directly according to that specification. This could include "order". In the case of a list view that has a `widget="handle"`, this order is automatically set to "[handle_field] ASC". Before the unity read feature, it did not cause problems for one2manys because the ids of records were retrieved in python using the "natural order" of the
Original PR description
Since commit 7d2baaa0c726a7b0dd4fe7226862f960c9c59b73 ("Unity read"), we are able to pass a full specification to subfields in a view and retrive records directly according to that specification.…
Since commit 7d2baaa0c726a7b0dd4fe7226862f960c9c59b73 ("Unity read"), we are able to pass a full specification to subfields in a view and retrive records directly according to that specification. This could include "order".
In the case of a list view that has a `widget="handle"`, this order is automatically set to "[handle_field] ASC".
Before the unity read feature, it did not cause problems for one2manys because the ids of records were retrieved in python using the "natural order" of the model (the `model._order` slot), which usually had the right parameters. (see `sale.order.line` for example). When fetching the ids of the one2many, those were already sorted in natural order.
In unity read, the natural order is overriden by the specification and became only "[handle_field] ASC". This was insufficient as more often than not, sequences on model are set up with a default. So eventually, all records couls have the same sequence. The sorting in SQL becomes undeterminate.
After this commit, we had the sorting key "id ASC" to avoid any unwanted results.
opw-3790378
see discord https://discord.com/channels/678381219515465750/687338039717920792/1231977078564585555 for a detailed discussion.
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#162933Problem: For a peruvian company, there is many choices of identification type and when creating an invoice, the identification type is always "RUC" whatever the identification type really is Steps to reproduce: - Install the "contacts" and the "accounting" apps - Add a peruvian company from the settings and set the "fiscal localization" as "Peru" for this company - Create a new contact from Peru and set the "Identification Number" as DNI and fill in the number - Create an invoice for thi
Original PR description
Problem: For a peruvian company, there is many choices of identification type and when creating an invoice, the identification type is always "RUC" whatever the identification type really is Steps to reproduce: - Install the "contacts" and the "accounting" apps - Add a peruvian company from the settings and set the "fiscal localization" as "Peru" for this company - Create a new contact from Peru and set the "Identification Number" as DNI and fill in the number - Create an invoice for this customer and preview the invoice - You will see written on top right "RUC:" instead of "DNI:" Cause: The identification type shown on the invoice is the default one for the country and then is not updated depending on the selection Solution: Replace the field to the selected one for Peru opw-3846814 Forward-Port-Of: odoo/enterprise#61123
### Issue: Grouping by a field.properties in the gantt view will give a traceback. ### Steps to reproduce: - Go on a project - Swap to the gantt view - Create a task in the calendar - Go back to the list view, click on the task - Click on the wheel icon and add a property with a value - Go back to the project and its gantt view - Group by the property you have added to your task #### > traceback ### Cause of the Issue: The fields given in the groupby parameters are added
Original PR description
### Issue: Grouping by a field.properties in the gantt view will give a traceback. ### Steps to reproduce: - Go on a project - Swap to the gantt view - Create a task in the calendar - Go back to the…
### Issue: Grouping by a field.properties in the gantt view will give a traceback. ### Steps to reproduce: - Go on a project - Swap to the gantt view - Create a task in the calendar - Go back to the list view, click on the task - Click on the wheel icon and add a property with a value - Go back to the project and its gantt view - Group by the property you have added to your task #### > traceback ### Cause of the Issue: The fields given in the groupby parameters are added to the read_specification of the "get_gantt_data" by the "_fetchData" method: https://github.com/odoo/enterprise/blob/ab29a91a0acda94fbb98a0f84c8685b34a31fbe5/web_gantt/static/src/gantt_model.js#L635-L638 https://github.com/odoo/enterprise/blob/ab29a91a0acda94fbb98a0f84c8685b34a31fbe5/web_gantt/static/src/gantt_model.js#L915-L920 However, as a fields.properties such as task_properties represent a dictionary of "pseudo field", the "field name" of a given property is of the form "task_properties.hashKey". The read_specification of the gantt view will therefore contain a "field_name" of that form. However, the ORM does not support to read such fields and the code will crash here: https://github.com/odoo/enterprise/blob/ab29a91a0acda94fbb98a0f84c8685b34a31fbe5/web_gantt/models/models.py#L89 pseudo fields such as "task_properties.12c97bca432np24" are not expected to be read (this is not supported by the ORM). ### Fix: If we were to format field names in the "_fetchData" method we would be able to group records by fields.properties in the gantt view. However, the framework is not ready to plainly support this operation as for instance other tracebacks will be encountered when you drag and drop tasks in the gantt view after a group by a given property. It was therefore decided with the framework team to remove the fields.properties from the fields appearing in the groupedBy parameters of the gantt view until these other operations become supported. opw-3847341 Forward-Port-Of: odoo/enterprise#61320 Forward-Port-Of: odoo/enterprise#61128
The default value is removed from `activity_date_deadline_range_type` field, this causes server action scheduled date to be NULL which raises an error when server action is run. To solve the issue we added range type when server action is created. ticket-3884415 Forward-Port-Of: odoo/enterprise#61309
Original PR description
The default value is removed from `activity_date_deadline_range_type` field, this causes server action scheduled date to be NULL which raises an error when server action is run. To solve the issue we added range type when server action is created. ticket-3884415 Forward-Port-Of: odoo/enterprise#61309
Steps to reproduce: --------------------- -Go to the planning module -Activate more than one company -create Sales order in company A -create shift in company B and select sales oder of comapny A -save the record -traceback Issue: ---------------------- On saving, when more than one company is activated and a shift is created for a specific company with an SOL selected from other company, a Singleton Error occurs. Cause: --------------------------- The traceback arises due to i
Original PR description
Steps to reproduce: --------------------- -Go to the planning module -Activate more than one company -create Sales order in company A -create shift in company B and select sales oder of comapny A -save the record -traceback Issue: ---------------------- On saving, when more than one company is activated and a shift is created for a specific company with an SOL selected from other company, a Singleton Error occurs. Cause: --------------------------- The traceback arises due to inability to iterate over multiple companies during this process on creating a shift. Solution: ------------------------ Implemented a looping to iterate over each company, ensuring proper handling of the multiple company on the shift task-3859050 Forward-Port-Of: odoo/enterprise#60391