Wednesday, March 27, 2024
32 changes · saas-17.1
Resolved issues and error corrections
This fix prevents the City and District dropdowns from appearing empty during checkout unless the selected country is Peru. It improves the checkout experience for shoppers on Peruvian websites by showing only relevant address fields.
Original PR description
### Steps to reproduce: - Install **l10n_pe_website_sale** module. - Switch to **PE Company**. - While Enabling the debug mode, Go to **Website** > **Configuration** > **Websites** and add a new website for the **PE Company**. - Go to **Website** > **Shop**, Switch to the new website and add a product to the cart. - Checkout the cart. - In the address section, Notice how both **City** and **District** select boxes are visible and empty! Both should only be visible when the selected Country is Peru (PE) ### Investigation: - 9f957eff4060c8680d73d608a176c0646d9aeb9b moved the method `_onChangeCountry` to another file and hence override of it wasn't in effect opw-3793838
This update prevents errors in the restaurant point-of-sale screen when the system is idle or when users click certain selected product categories. It improves reliability for staff during ordering and helps avoid interruptions at checkout.
Original PR description
Previously, being idle in POS restaurant could cause an error. This was due to setSelectedCategory being set to 0 without a category selected. Also, clicking a selected category with a parent led to an error. This commit fixes these issues. opw-3824557 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The sales subscription dashboards now avoid showing errors when demo data is not installed. Empty dashboard sections are left blank instead, making the dashboards usable in clean or production-like databases.
Original PR description
Before this fix, errors occurred in certain sections of the sales subscription dashboard when attempting to load it without demo data. This PR resolves the problem by incorporating IFERROR into the formulas to leave them empty in case of errors. Task ID: 3754211
This update corrects a bug that caused the system to repeatedly recalculate expense product costs, which could lead to inaccurate accounting records. The fix ensures that expense costs are only calculated when necessary, improving data accuracy and reducing potential discrepancies in financial reporting. This change improves the reliability of expense tracking.
Original PR description
Fix a bug introduced by 67901a4429c69fbba96c32af5d8f58aff54f0be5 When an expense is submitted and for the steps after, there is no need to recompute the product_cost as it may be confusing or generate discrepancies with the account move by changing the totals. task-3580004 Forward-Port-Of: odoo/odoo#155277 Forward-Port-Of: odoo/odoo#141400
Miscellaneous changes
[This commit] fixed an issue with the menu cache. Unfortunately, during the forward port, we missed updating the cache key according to what has been done in [this other commit]. This commit updates the cache key and improves the test. Steps to reproduce the bug fixed by this commit: - Render a website without a record URL in the menu (to fill the cache) - Edit the website's menu - Add a link to a product page (e.g., customizable-desk) - Add a link to another product (e.g., chair-floor-pr
Original PR description
[This commit] fixed an issue with the menu cache. Unfortunately, during the forward port, we missed updating the cache key according to what has been done in [this other commit]. This commit updates…
[This commit] fixed an issue with the menu cache. Unfortunately, during the forward port, we missed updating the cache key according to what has been done in [this other commit]. This commit updates the cache key and improves the test. Steps to reproduce the bug fixed by this commit: - Render a website without a record URL in the menu (to fill the cache) - Edit the website's menu - Add a link to a product page (e.g., customizable-desk) - Add a link to another product (e.g., chair-floor-protection) - Save the menu - Click on the menu link to go to customizable-desk => At this point, the active menu element is correct - Click on the menu link to go to chair-floor-protection => The active menu element does not update This issue does not occur if there is a record like URL in the menu before the first render. [This commit]: https://github.com/odoo/odoo/commit/970c173530e5523d0e3242ad84dae6fe5e332d68 [this other commit]:https://github.com/odoo/odoo/commit/595aa248433246959a5fa9288e477091701c6a35 opw-3694651 opw-3750925 opw-3781668 Forward-Port-Of: odoo/odoo#159429
*: website_sale This is a follow-up of [1], which missed some occurrence of the same issue that it fixed. E.g. - Add a delay to the "write" of the event model - Go to /event/<event_id>/community - Enter edit mode - Click on the page - Enable the room creation option => The page reloads but nothing seems to have been done... it is actually *being* done: the page reloaded too soon. Note: this commit also marks some other occurrences which are not buggy but might be in the future
Original PR description
*: website_sale This is a follow-up of [1], which missed some occurrence of the same issue that it fixed. E.g. - Add a delay to the "write" of the event model - Go to /event/<event_id>/community - Enter edit mode - Click on the page - Enable the room creation option => The page reloads but nothing seems to have been done... it is actually *being* done: the page reloaded too soon. Note: this commit also marks some other occurrences which are not buggy but might be in the future if not properly changed. To be adapted in the master forward-port. [1]: https://github.com/odoo/odoo/commit/556ae457b02e9c077d09fa9c3f9f1e6c6e26b345 Forward-Port-Of: odoo/odoo#159393 Forward-Port-Of: odoo/odoo#159316
Currently, on sale orders, you cannot access parent's fiscal positions from a branch. ### Steps to reproduce * install `sale_management` * set up a company hierarchy. Let's say we have two companies P and C such that C is a branch of P. * let's say that P has a fiscal position F * switch to company C * attempt to set fiscal position F on a sale order You will see that F does not appear on the list. opw-3773335 Forward-Port-Of: odoo/odoo#159042
Original PR description
Currently, on sale orders, you cannot access parent's fiscal positions from a branch. ### Steps to reproduce * install `sale_management` * set up a company hierarchy. Let's say we have two companies P and C such that C is a branch of P. * let's say that P has a fiscal position F * switch to company C * attempt to set fiscal position F on a sale order You will see that F does not appear on the list. opw-3773335 Forward-Port-Of: odoo/odoo#159042
* Enable Peppol * Create a partner with: - Name: Test Peppol - Country: Belgium - Email: test-peppol@customer.example.com - Electronic Invoice Format: BIS Billing 3.0 - Peppol e-address: (blank) - Peppol endpoint: (blank) * Create an invoice and confirm it * Click on "Send & Print" => In the wizard that open, there are no option to select either Peppol nor any EDI format. Once `account_peppol` is installed, if a partner has an EDI format set but no Peppol in
Original PR description
* Enable Peppol * Create a partner with: - Name: Test Peppol - Country: Belgium - Email: test-peppol@customer.example.com - Electronic Invoice Format: BIS Billing 3.0 - Peppol e-address: (blank) - Peppol endpoint: (blank) * Create an invoice and confirm it * Click on "Send & Print" => In the wizard that open, there are no option to select either Peppol nor any EDI format. Once `account_peppol` is installed, if a partner has an EDI format set but no Peppol information (EAS & Endpoint) we should still allow the user to send/print the invoice with partner's EDI format. Also the Peppol warning was never shown on the wizard as the option was always disabled when the partner was not fully configured, so now the option is shown but unchecked by default if partner is not ready. OPW-3698904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158582
This commit "fixes" a weird behavior in Firefox where a MouseEvent ("mouseenter" in this case) can be triggered from the target's TEXT_NODE, even if it shouldn't... Note: even though this isn't clearly defined in the spec, MouseEvent shouldn't be dispatched for TEXT_NODE, as implemented in Blink or WebKit... But not everyone agrees (cf. tickets linked below). Steps to reproduce: - open website - go into edit mode - actually edit the page - add a snippet to the page - click on the "Dis
Original PR description
This commit "fixes" a weird behavior in Firefox where a MouseEvent ("mouseenter" in this case) can be triggered from the target's TEXT_NODE, even if it shouldn't... Note: even though this isn't…
This commit "fixes" a weird behavior in Firefox where a MouseEvent ("mouseenter" in this case) can be triggered from the target's TEXT_NODE, even if it shouldn't...
Note: even though this isn't clearly defined in the spec, MouseEvent shouldn't be dispatched for TEXT_NODE, as implemented in Blink or WebKit... But not everyone agrees (cf. tickets linked below).
Steps to reproduce:
- open website
- go into edit mode
- actually edit the page
- add a snippet to the page
- click on the "Discard" button and move very fast out of it => the error `el.matches is not a function` is "sometimes" raised (if you got the right timing)
References:
- https://w3c.github.io/uievents/#event-type-mouseenter
- https://bugzilla.mozilla.org/show_bug.cgi?id=185889
- https://bugzilla.mozilla.org/show_bug.cgi?id=42717
- https://bugzilla.mozilla.org/show_bug.cgi?id=103055
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#158810Current behavior: When printing a receipt with a QR code on an iOS device, the QR code was too small and couldn't be scanned Steps to reproduce: - Setup an ePos printer for the PoS - Activate QRCode on receipt option - Start a PoS session on an iOS device - Add some product to the order and validate it - On the receipt screen click on the print button - Try to scan the QR Code on the ticket (it's probably too small) Note: If you don't have an iOS device you can use browserstack and
Original PR description
Current behavior: When printing a receipt with a QR code on an iOS device, the QR code was too small and couldn't be scanned Steps to reproduce: - Setup an ePos printer for the PoS - Activate QRCode on receipt option - Start a PoS session on an iOS device - Add some product to the order and validate it - On the receipt screen click on the print button - Try to scan the QR Code on the ticket (it's probably too small) Note: If you don't have an iOS device you can use browserstack and use ngrok to expose your local server to the internet and connect to it on browserstack. You can do the same process to expose the printer so that you will be able to print from browserstack. opw-3788988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159185 Forward-Port-Of: odoo/odoo#157423
Prior to this PR, `oi` icons were not adapted when RTL was defined in frontend. This is because RTL adaptations were defined in the backend bundle. This PR moves the RTL adaptations to be used wherever `oi` icons can be defined. task-3794966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159150 Forward-Port-Of: odoo/odoo#157214
Original PR description
Prior to this PR, `oi` icons were not adapted when RTL was defined in frontend. This is because RTL adaptations were defined in the backend bundle. This PR moves the RTL adaptations to be used wherever `oi` icons can be defined. task-3794966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159150 Forward-Port-Of: odoo/odoo#157214
Before this commit sol field wasn't editable when user don't have any sales access and it was editable for timesheet page and project form view. This commit make SOL field in task form editable to be consistant with project form and timesheet page of tast form. task-3764793 Forward-Port-Of: odoo/odoo#158547 Forward-Port-Of: odoo/odoo#155339
Original PR description
Before this commit sol field wasn't editable when user don't have any sales access and it was editable for timesheet page and project form view. This commit make SOL field in task form editable to be consistant with project form and timesheet page of tast form. task-3764793 Forward-Port-Of: odoo/odoo#158547 Forward-Port-Of: odoo/odoo#155339
In order to be able to copy the courses that have the visibility set to 'member'/'Course attendees' we need to be able to copy the enroll of the course, since this visibility requires that we have enroll set to invite and If we are unable to copy it will always be open which is the default opw-3749209 Forward-Port-Of: odoo/odoo#155843
Original PR description
In order to be able to copy the courses that have the visibility set to 'member'/'Course attendees' we need to be able to copy the enroll of the course, since this visibility requires that we have enroll set to invite and If we are unable to copy it will always be open which is the default opw-3749209 Forward-Port-Of: odoo/odoo#155843
If the move in the test is created at 23:59:59, and the wizard on the next day at 00:00:01, the test will fail because the wizard takes today as the date at creation. We just add a freeze_time (for this test only, as the other tests in the class don't have the issue). Linked to runbot error 60478 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157981
Original PR description
If the move in the test is created at 23:59:59, and the wizard on the next day at 00:00:01, the test will fail because the wizard takes today as the date at creation. We just add a freeze_time (for this test only, as the other tests in the class don't have the issue). Linked to runbot error 60478 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157981
Steps to reproduce ================== - Create a new Invoice => The tab title is `Odoo - Draft Invoice (* NewId_0x7f545c9d6980)` Cause of the issue ================== In 17, the display_name is computed for the tab title https://github.com/odoo/odoo/blob/82fd8e702588d2cc5bdad474ed21188257cc7397/addons/web/static/src/views/form/form_controller.js#L342 opw-3794671 Forward-Port-Of: odoo/odoo#159301
Original PR description
Steps to reproduce ================== - Create a new Invoice => The tab title is `Odoo - Draft Invoice (* NewId_0x7f545c9d6980)` Cause of the issue ================== In 17, the display_name is computed for the tab title https://github.com/odoo/odoo/blob/82fd8e702588d2cc5bdad474ed21188257cc7397/addons/web/static/src/views/form/form_controller.js#L342 opw-3794671 Forward-Port-Of: odoo/odoo#159301
When the user creates a new ribbon without a background color, a traceback will appear. Steps to reproduce the error: - Install "website_sale" - Go to Website > eCommerce > Products - Pick a product > Sales > Create a new ribbon without a background color - Save & Close Traceback: ``` TypeError: argument of type 'bool' is not iterable File "odoo/http.py", line 2251, in __call__ response = request._serve_db() File "odoo/http.py", line 1826, in _serve_db return self._t
Original PR description
When the user creates a new ribbon without a background color, a traceback will appear. Steps to reproduce the error: - Install "website_sale" - Go to Website > eCommerce > Products - Pick a product…
When the user creates a new ribbon without a background color,
a traceback will appear.
Steps to reproduce the error:
- Install "website_sale"
- Go to Website > eCommerce > Products
- Pick a product > Sales > Create a new ribbon without a background color
- Save & Close
Traceback:
```
TypeError: argument of type 'bool' is not iterable
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/web/models/models.py", line 74, in web_save
self = self.create(vals)
File "<decorator-gen-471>", line 2, in create
File "odoo/api.py", line 420, in _model_create_multi
return create(self, [arg])
File "addons/website_sale/models/product_ribbon.py", line 24, in create
if 'bg_color' in vals and not '!important' in vals['bg_color']:
```
https://github.com/odoo/odoo/blob/806a60d9766e4e04f461a0fb7c824cf5f5c7d5ae/addons/website_sale/models/product_ribbon.py#L24 Here, when the user creates a new ribbon without a background color,
"bg_color" will be False, so when it tries to check "vals['bg_color']".
It will lead to the above traceback.
sentry-5077714703
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#158561Our certificate for aeat seems to not be valid anymore. We don't have a replacement currently. The flow is still tested with bizkaia or gipuzkoa (mostly just different servers/addresses, but same flow/xml), where the certificate is still accepted. We remove this test that fail every day. Linked to Runbot error 25907 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157278
Original PR description
Our certificate for aeat seems to not be valid anymore. We don't have a replacement currently. The flow is still tested with bizkaia or gipuzkoa (mostly just different servers/addresses, but same flow/xml), where the certificate is still accepted. We remove this test that fail every day. Linked to Runbot error 25907 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157278
Forward-Port-Of: odoo/odoo#159262
Original PR description
Forward-Port-Of: odoo/odoo#159262
Before this commit, if a button had the attribute special="close" on the footer of an x2many dialog, the dialog was not closed. This occurs because the view button hook searches the dialog close functions put in the environment by the dialog component, and in this case is another component that initialize the hook, and the function is not found. Now, the view button hook will use the dialog close function put in the environment by the dialog service. Forward-Port-Of: odoo/odoo#159121
Original PR description
Before this commit, if a button had the attribute special="close" on the footer of an x2many dialog, the dialog was not closed. This occurs because the view button hook searches the dialog close functions put in the environment by the dialog component, and in this case is another component that initialize the hook, and the function is not found. Now, the view button hook will use the dialog close function put in the environment by the dialog service. Forward-Port-Of: odoo/odoo#159121
Before this commit, attempting to invoice an order paid by cash in a new session, with cash rounding enabled only for cash payments in the PoS config, would result in an unbalanced entries error. opw-3813932 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158781
Original PR description
Before this commit, attempting to invoice an order paid by cash in a new session, with cash rounding enabled only for cash payments in the PoS config, would result in an unbalanced entries error. opw-3813932 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158781
When an expression had no figure type, the condition "expression.figure_type != 'string'" was true and so we tried to round the value. But when the value is None, the code will crash. Now if the expression has no figure type we get the column type of the expression, but it can happen that an expression is not link to a column. If that's the case we don't round the expression. task: 3776104 Forward-Port-Of: odoo/enterprise#59314 Forward-Port-Of: odoo/enterprise#57913
Original PR description
When an expression had no figure type, the condition "expression.figure_type != 'string'" was true and so we tried to round the value. But when the value is None, the code will crash. Now if the expression has no figure type we get the column type of the expression, but it can happen that an expression is not link to a column. If that's the case we don't round the expression. task: 3776104 Forward-Port-Of: odoo/enterprise#59314 Forward-Port-Of: odoo/enterprise#57913
The wrong number was used for identifying the user to the Belastingdienst through SBR when submitting their Tax Report. This new field has to be added through a new module but will be correctly merged in master. opw-3786956 Forward-Port-Of: odoo/enterprise#59217 Forward-Port-Of: odoo/enterprise#58485
Original PR description
The wrong number was used for identifying the user to the Belastingdienst through SBR when submitting their Tax Report. This new field has to be added through a new module but will be correctly merged in master. opw-3786956 Forward-Port-Of: odoo/enterprise#59217 Forward-Port-Of: odoo/enterprise#58485
The computed stored field l10n_mx_edi_payment_method_id of account_move in l10n_mx_edi can lead to MemoryErrors during module installation in some large databases. To fix that, this commit first creates the field's column in _auto_init, avoiding the recomputations that overfill the field_cache and lead to MemoryErrors. Then, since inside the field's compute method the field should be set to a specific payment_method defined in the module's data files, change the post_init_hook to set the paym
Original PR description
The computed stored field l10n_mx_edi_payment_method_id of account_move in l10n_mx_edi can lead to MemoryErrors during module installation in some large databases. To fix that, this commit first creates the field's column in _auto_init, avoiding the recomputations that overfill the field_cache and lead to MemoryErrors. Then, since inside the field's compute method the field should be set to a specific payment_method defined in the module's data files, change the post_init_hook to set the payment_method to the correct id in the database after data files loading. I missed it in PR odoo/enterprise#30929 because this field was changed to a computed field starting v15. opw-3018535 Forward-Port-Of: odoo/enterprise#58804 Forward-Port-Of: odoo/enterprise#34974
A lot of clients are blocked because they have a bad VAT number somewhere. If the compacting (remove spaces, dots, ...) gives an error, it will just not compact the number and put the original one. opw-3816072 Forward-Port-Of: odoo/enterprise#59319 Forward-Port-Of: odoo/enterprise#59282
Original PR description
A lot of clients are blocked because they have a bad VAT number somewhere. If the compacting (remove spaces, dots, ...) gives an error, it will just not compact the number and put the original one. opw-3816072 Forward-Port-Of: odoo/enterprise#59319 Forward-Port-Of: odoo/enterprise#59282
Prevents the user to reset to draft a tax closing entry if subsequent closing entries are already posted. This way, the user is forced to reset to draft progressively back in time the closing entries. Accounting wise, this case should not happen. It is by the way prevented by the irreversible_lock_date module (which can be however uninstalled). This mechanism solves an issue with carryovers that need to be progressively recomputed when resetting to draft a closing entry. Another issue has als
Original PR description
Prevents the user to reset to draft a tax closing entry if subsequent closing entries are already posted. This way, the user is forced to reset to draft progressively back in time the closing entries. Accounting wise, this case should not happen. It is by the way prevented by the irreversible_lock_date module (which can be however uninstalled). This mechanism solves an issue with carryovers that need to be progressively recomputed when resetting to draft a closing entry. Another issue has also been fixed. The 'Closing Entry' button in the Tax Report has inconsistent behavior when the closing entry is already posted and then reset to draft. This issue was solved in 17 in this commit: https://github.com/odoo/enterprise/commit/49f664db942f3b7f5d343ac7a42608839b5595bf. It is backported in order to make the draft closing entry flow as smooth as possible. task-3520338 Forward-Port-Of: odoo/enterprise#59372 Forward-Port-Of: odoo/enterprise#52875
STEP TO REPRODUCE: ================== * Go on Appraisal application * Select an appraisal * Click on "ask feedback" button * Add in recipients field an employee without user linked to him task: 3818033 Forward-Port-Of: odoo/enterprise#59464 Forward-Port-Of: odoo/enterprise#59125
Original PR description
STEP TO REPRODUCE:
==================
* Go on Appraisal application
* Select an appraisal
* Click on "ask feedback" button
* Add in recipients field an employee without user linked to him
task: 3818033
Forward-Port-Of: odoo/enterprise#59464
Forward-Port-Of: odoo/enterprise#59125When a task and a ticket share the same ID, the _search_user_timer_id method will not work and provide the wrong result when using User Timer as the filter. Steps to reproduce: Having a task and a ticket with the same ID. Start the timer in the task. Go to the ticket and filter by "User Timer is set" There will be a ticket without a timer running but still showing in the search result. Cause The search method did not take into consideration of model. Solution Add model as a condi
Original PR description
When a task and a ticket share the same ID, the _search_user_timer_id method will not work and provide the wrong result when using User Timer as the filter. Steps to reproduce: Having a task and a ticket with the same ID. Start the timer in the task. Go to the ticket and filter by "User Timer is set" There will be a ticket without a timer running but still showing in the search result. Cause The search method did not take into consideration of model. Solution Add model as a condition when searching timer records Forward-Port-Of: odoo/enterprise#59398
Wrong conflict resolution when forward porting odoo/enterprise@7ff6e2b04110d1e3c046388927409ec46d39800e Task-3778173 Forward-Port-Of: odoo/enterprise#59420
Original PR description
Wrong conflict resolution when forward porting odoo/enterprise@7ff6e2b04110d1e3c046388927409ec46d39800e Task-3778173 Forward-Port-Of: odoo/enterprise#59420
https://www2.partena-professional.be/LegalPortal/servlet/servlet.FileDownload?file=00P3X00002H45q2UAB Forward-Port-Of: odoo/enterprise#59418
Original PR description
https://www2.partena-professional.be/LegalPortal/servlet/servlet.FileDownload?file=00P3X00002H45q2UAB Forward-Port-Of: odoo/enterprise#59418
### Steps to reproduce: - Install **field service** app. - Go to **field service**, and convert the view to **Calendar**. - Click on a task and try to drag it. You **_can't_** drag and drop a task. ### Investigation: - the `date_start` option is `planned_date_start` https://github.com/odoo/enterprise/blob/dab59cb6dea28f13b6b984b19d844fc9ad6f2006/industry_fsm/views/fsm_views.xml#L91 - which is a **computed -readonly-** field https://github.com/odoo/enterprise/blob/a29e55f7ac02a0c2b34c9714
Original PR description
### Steps to reproduce: - Install **field service** app. - Go to **field service**, and convert the view to **Calendar**. - Click on a task and try to drag it. You **_can't_** drag and drop a task.…
### Steps to reproduce: - Install **field service** app. - Go to **field service**, and convert the view to **Calendar**. - Click on a task and try to drag it. You **_can't_** drag and drop a task. ### Investigation: - the `date_start` option is `planned_date_start` https://github.com/odoo/enterprise/blob/dab59cb6dea28f13b6b984b19d844fc9ad6f2006/industry_fsm/views/fsm_views.xml#L91 - which is a **computed -readonly-** field https://github.com/odoo/enterprise/blob/a29e55f7ac02a0c2b34c9714397c5a1322785833/project_enterprise/models/project_task.py#L31 - That's why, we can't drag the task. - The `planned_date_start` field was added because the `start_date_begin` field was **optional** and so to be able to view tasks with only a deadline a no start date, the field `planned_date_start` was added with the compromise of not being able to drag the task - The `planned_date_begin ` field is now **required** tho. and so no need to make such compromise as an fsm task will always have a start date `start_date_begin` opw-3750403 Forward-Port-Of: odoo/enterprise#58316
During this commit: https://github.com/odoo/enterprise/commit/02252c3af7637835e34d0c19a609e1aa05b5a653#diff-fcb2837955e2fcf5fb3885f86c0f12f8facd7cd24d73e1f151957c33db381f9e A duplicate variable was introduced. This commit will remove that. no task-id Forward-Port-Of: odoo/enterprise#59432
Original PR description
During this commit: https://github.com/odoo/enterprise/commit/02252c3af7637835e34d0c19a609e1aa05b5a653#diff-fcb2837955e2fcf5fb3885f86c0f12f8facd7cd24d73e1f151957c33db381f9e A duplicate variable was introduced. This commit will remove that. no task-id Forward-Port-Of: odoo/enterprise#59432
Issue: ------ It is possible to change the recurrence of a product if it has already been sold (correct behaviour). The customer receives a warning, but the `recurring_invoice` field is still set to `True`, whereas it may have been set to `False` before the operation. Solution: --------- Prevent the `recurring_invoice` field from being changed if a confirmed sale order line contains this product, to avoid confusion. opw-3457160 Forward-Port-Of: odoo/enterprise#59367
Original PR description
Issue: ------ It is possible to change the recurrence of a product if it has already been sold (correct behaviour). The customer receives a warning, but the `recurring_invoice` field is still set to `True`, whereas it may have been set to `False` before the operation. Solution: --------- Prevent the `recurring_invoice` field from being changed if a confirmed sale order line contains this product, to avoid confusion. opw-3457160 Forward-Port-Of: odoo/enterprise#59367