Saturday, August 31, 2024
26 changes
22 changes
Resolved issues and error corrections
Users can now add a barcode to a product even when no Customer Taxes are set. This prevents an unexpected error screen and keeps product setup workflows running smoothly.
Original PR description
When the user tries to add a barcode without Customer Taxes, a traceback will appear. Traceback: ``` AttributeError: 'product.template' object has no attribute 'super' File "odoo/http.py", line 2374,…
When the user tries to add a barcode without Customer Taxes,
a traceback will appear.
Traceback:
```
AttributeError: 'product.template' object has no attribute 'super'
File "odoo/http.py", line 2374, in __call__
response = request._serve_db()
File "odoo/http.py", line 1904, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1967, 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 1934, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2178, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 223, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 755, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1008, in onchange
record._apply_onchange_methods(field_name, result)
File "odoo/models.py", line 7042, in _apply_onchange_methods
res = method(self)
File "home/odoo/src/enterprise/saas-17.4/product_barcodelookup/models/product_template.py", line 20, in _onchange_barcode
product._update_product_by_barcodelookup(product, barcode_lookup_data)
File "home/odoo/src/enterprise/saas-17.4/product_barcodelookup/models/product_template.py", line 77, in _update_product_by_barcodelookup
product.list_price = self._get_list_price(price)
File "addons/account/models/product.py", line 154, in _get_list_price
return self.super._get_list_price(price)
```
https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b3273f863420e659/addons/account/models/product.py#L146 Here, self.super is used instead of super() .
so, it will lead to the above traceback.
sentry-5766033395
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prPurchase order PDFs now avoid showing an unnecessary tax base line when there is only one VAT rate. This fixes a rounding mismatch for currencies such as Chilean pesos, making printed tax information clearer and consistent.
Original PR description
Steps to reproduce: - Install 'Purchase' - Create a new company with CLP currency. - Select Chile fiscal localization in Settings. - Make a new Request for Quotation - Add any product set price to…
Steps to reproduce: - Install 'Purchase' - Create a new company with CLP currency. - Select Chile fiscal localization in Settings. - Make a new Request for Quotation - Add any product set price to 23.67 - Add VAT of 19% - Confirm the order - Click on the Action button -> Print -> Purchase Order. Issues: On the downloaded pdf, the tax base is displayed as "VAT 19% on $24". It shouldn't be the case as we have a single VAT so no need to display this. The reason for this appearing is because we have a rounding incosistency. Here we apply `currency.round` on the amount. https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b3273f863420e659/addons/account/models/account_tax.py#L2116 This is not the case here. https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b3273f863420e659/addons/account/models/account_tax.py#L2163 Because of this we will have 2 amount in `encountered_base_amounts` whiche means that `'display_tax_base'` will be set to True. https://github.com/odoo/odoo/blob/42fa237296f9b1fa556ae310b3273f863420e659/addons/account/models/account_tax.py#L2188 opw-4039152
Fixed an issue where scheduled activities could show different user avatar and date information when the same record was open in multiple browser tabs. This keeps activity details consistent across tabs, reducing confusion for users working with forms such as Contacts.
Original PR description
Before this commit, when opening a form view of record containing an activity on 2 different tabs, one of tab showed the user avatar while the other doesn't. Steps to reproduce: - open Contact form…
Before this commit, when opening a form view of record containing an activity on 2 different tabs, one of tab showed the user avatar while the other doesn't. Steps to reproduce: - open Contact form view - schedule an activity - open this form view on another tab => the new tab has user avatar on activity while previous tab doesn't This happens because the state of activities is shared between tabs, and the newer tab shares its state to other tabs. However, activity state was not properly passing relational field values notably for the author: instead of passing `type` and `id` identifying values, it only passes `id`. This comes from a typo in code where the `toIdData()` was used on current model (Activity) rather than the target model (Persona), thus only persona id was retrieved. This commit fixes the issue by properly using `toIdData` on target model of relational field. Also the date and datetime fields were not properly serialized, which also result in breaking the datetime in other tabs. This commit also fixes this issue. Task-4143781 Before / After <img width="300" alt="Screenshot 2024-08-28 at 17 10 25" src="https://github.com/user-attachments/assets/e4422b69-8800-4dc3-ba16-515ea6b7392d"> <img width="369" alt="Screenshot 2024-08-28 at 17 10 30" src="https://github.com/user-attachments/assets/4d5783bd-2935-4630-8ea1-d94264b739bf">
Miscellaneous changes
Steps to reproduce: - Install timesheets, project and accounting - Enable "Analytic accounting" in accounting settings - Accounting > Accounting > Analytic items - Goup by Billing type - 2 different 'Materials' Change was made in 3d3f4109a06445b6ce9606770085c763ea206b35. This is ambiguous and clashes with the previously used items in 15.0. https://github.com/odoo/odoo/blob/ec106bfaaede527857a028bf1956b309aad3dc51/addons/sale_timesheet/models/account.py#L17 opw-4080234 --- I confir
Original PR description
Steps to reproduce: - Install timesheets, project and accounting - Enable "Analytic accounting" in accounting settings - Accounting > Accounting > Analytic items - Goup by Billing type - 2 different 'Materials' Change was made in 3d3f4109a06445b6ce9606770085c763ea206b35. This is ambiguous and clashes with the previously used items in 15.0. https://github.com/odoo/odoo/blob/ec106bfaaede527857a028bf1956b309aad3dc51/addons/sale_timesheet/models/account.py#L17 opw-4080234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177933 Forward-Port-Of: odoo/odoo#177388
3 changes
Resolved issues and error corrections
This fixes an issue where recruitment document processing used the wrong field when matching candidates. It helps ensure resumes and related documents are routed or linked to the correct recruitment records.
1 change
Resolved issues and error corrections
This update corrects a test that verifies portal users can create and edit knowledge articles. The test was passing incorrectly because it wasn't properly checking access permissions. The fix ensures the test now correctly validates that portal users have the right permissions to perform these actions.
Original PR description
Since odoo/enterprise#38575, portal users can create/edit knowledge articles. However, the test that checks that feature is not correct: - it does not call `check_access_rights()` (for ACLs); - it uses a `res.partner` instead of a `res.users` in `with_user()`. Because the test only checks access rules with a non-existing user, no rules are found, and the check is therefore trivial. In other words, the test passes by accident :-( The fix consists in creating a portal user for the corresponding "customer" contact, and add the expected calls to `check_access_rights()`.
No visual bug, just a small coding mistake made with [1]. [1]: https://github.com/odoo/odoo/commit/e2cd6940bd29670ea0e76cd4bb95489a12588f55 Related to task-3957198 Forward-Port-Of: odoo/odoo#178059
Original PR description
No visual bug, just a small coding mistake made with [1]. [1]: https://github.com/odoo/odoo/commit/e2cd6940bd29670ea0e76cd4bb95489a12588f55 Related to task-3957198 Forward-Port-Of: odoo/odoo#178059
When the l10n_es_pos module is installed, the post_init_hook attempts to create an account journal for each Spanish company using a chart template. However, the method does not verify whether the journal already exists for the company, leading to potential duplication errors. Steps to Reproduce: - Create a journal for a Spanish company with the code 'SINV'. - Install the Point of Sale module and the l10n_es_pos module. - An error is raised because the journal 'SINV' already exists. Solu
Original PR description
When the l10n_es_pos module is installed, the post_init_hook attempts to create an account journal for each Spanish company using a chart template. However, the method does not verify whether the journal already exists for the company, leading to potential duplication errors. Steps to Reproduce: - Create a journal for a Spanish company with the code 'SINV'. - Install the Point of Sale module and the l10n_es_pos module. - An error is raised because the journal 'SINV' already exists. Solution: This fix adds a check to ensure the journal does not already exist before attempting to create it. opw-4108466 Forward-Port-Of: odoo/odoo#176953
[FIX] hr_holidays: take time into account during deserialization Steps to reproduce: - Install Time Off - Set your time-zone to UTC+1 - Modify your working schedules for Monday Morning to start at 00:30 - Create a leave for Monday and Tuesday in the Time Off app Issues: The calendar show 3 days for the leave. This is due to the field `all_day`, since it's set we will deserialize the record with the function `deserializeDate`. https://github.com/odoo/odoo/blob/44a1b163481b0b781028
Original PR description
[FIX] hr_holidays: take time into account during deserialization Steps to reproduce: - Install Time Off - Set your time-zone to UTC+1 - Modify your working schedules for Monday Morning to start at…
[FIX] hr_holidays: take time into account during deserialization Steps to reproduce: - Install Time Off - Set your time-zone to UTC+1 - Modify your working schedules for Monday Morning to start at 00:30 - Create a leave for Monday and Tuesday in the Time Off app Issues: The calendar show 3 days for the leave. This is due to the field `all_day`, since it's set we will deserialize the record with the function `deserializeDate`. https://github.com/odoo/odoo/blob/44a1b163481b0b781028ce337d72fbb0c8730475/addons/web/static/src/views/calendar/calendar_model.js#L503-L509 This function doesn't take into account the time in the record, which means that it will just deserialize the date which is Sunday in our case because of the timezone conversion to UTC. Because of this the frontend thinks that the leave takes place from Sunday to Tuesday. We can remove `all_day` thanks to this [fix](https://github.com/odoo/odoo/commit/3ccc6bfa86618b0ca13c13960c15b60f8f75f3ce) which enable `allDaySlot` options by default which allow us to preserve the original behavior of the calendar view in hr_holidays while correctly deserializing the datetime. opw-4043180 Forward-Port-Of: odoo/odoo#173147
SYSCOHADA should stay SYSCOHADA when translated task-4118393 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#177886
Original PR description
SYSCOHADA should stay SYSCOHADA when translated task-4118393 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#177886
**Current behavior before PR:** - When a table was created within an empty list item `(li)`, it was inserted directly inside the `ul` and as a sibling of the list item `(li)`. Furthermore, an additional `li` element was generated after the table. **Desired behavior after PR is merged:** - Now, when a table created inside empty `li` elements, it will be correctly inserted within the list item itself instead of the `ul`. Additionally, no extra `li` element will be generated after the tabl
Original PR description
**Current behavior before PR:** - When a table was created within an empty list item `(li)`, it was inserted directly inside the `ul` and as a sibling of the list item `(li)`. Furthermore, an additional `li` element was generated after the table. **Desired behavior after PR is merged:** - Now, when a table created inside empty `li` elements, it will be correctly inserted within the list item itself instead of the `ul`. Additionally, no extra `li` element will be generated after the table. task-3550599 Forward-Port-Of: odoo/odoo#164304
## Issue: - When creating a kit BoM with two components that the total of their cost share is 100, we get this UserError when saving: 'The total cost share for a BoM's components has to be 100%.'" ## Steps To Reproduce: - Create a BoM of type Kit. - Add 2 components. - Set their cost shares to 99.99 and 0.01. - Save and Notice the error: "The total cost share for a BoM's component have to be 100" ## Solution: - After saving, the [`float_round`](https://github.com/odoo/odoo/blob/048
Original PR description
## Issue: - When creating a kit BoM with two components that the total of their cost share is 100, we get this UserError when saving: 'The total cost share for a BoM's components has to be 100%.'" ##…
## Issue:
- When creating a kit BoM with two components that the total of their cost share is 100, we get this UserError when saving: 'The total cost share for a BoM's components has to be 100%.'"
## Steps To Reproduce:
- Create a BoM of type Kit.
- Add 2 components.
- Set their cost shares to 99.99 and 0.01.
- Save and Notice the error: "The total cost share for a BoM's component have to be 100"
## Solution:
- After saving, the [`float_round`](https://github.com/odoo/odoo/blob/048ed950ad32187a8e7ae7811a5afc87d9ce8ac8/odoo/tools/float_utils.py#L35) method is eventually called. When it reaches the line [`result = rounded_value * rounding_factor`](https://github.com/odoo/odoo/blob/048ed950ad32187a8e7ae7811a5afc87d9ce8ac8/odoo/tools/float_utils.py#L113) with `rounded_value = 9999.0` and `rounding_factor = 0.01`, it returns `99.99000001`.
- A possible fix is to modify the `float_round` method to include a condition before returning the result:
``` python
if precision_digits or precision_rounding:
decimal_places = precision_digits or len(str(precision_rounding).split('.')[1])
return round(result, decimal_places)```
- However, I believe it might be too low-level, so I kept it simple by rounding the `bom.lines` before summing them and returning the UserError`.
opw-4100375
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#177915
Forward-Port-Of: odoo/odoo#177015To reproduce: - Install `account` in a fresh DB - Change the CoA to one which doesn't use anglo-saxon accounting - Notice how anglo-saxon accounting is still activated on the company Analysis: - Since `anglo_saxon_accounting` has a default value of False, we don't bother to specify its value in the templates which don't use it. - So, when switching CoA from one which uses anglo-saxon accounting to one which doesn't, False doesn't get written. Solution: - We explicitly reset it when c
Original PR description
To reproduce: - Install `account` in a fresh DB - Change the CoA to one which doesn't use anglo-saxon accounting - Notice how anglo-saxon accounting is still activated on the company Analysis: -…
To reproduce: - Install `account` in a fresh DB - Change the CoA to one which doesn't use anglo-saxon accounting - Notice how anglo-saxon accounting is still activated on the company Analysis: - Since `anglo_saxon_accounting` has a default value of False, we don't bother to specify its value in the templates which don't use it. - So, when switching CoA from one which uses anglo-saxon accounting to one which doesn't, False doesn't get written. Solution: - We explicitly reset it when changing CoA. - We could have put a default value of False in the template values, but that doesn't combine nicely with the existing code, so this solution is preferred. This has been causing issues for new SaaS databases, since the `saas_worker` first generates a database template for the Accounting app, and only afterwards generates database templates for each localization by changing the CoA. As far as I can see, no other fields need the same treatment. taskid: none Forward-Port-Of: odoo/odoo#178113
In some cases, like when another tests activates a language, the log output can include an extra line. See an example here: https://runbot.odoo.com/runbot/build/66699073 After this commit, we only check for the logs we care about. See also: https://github.com/odoo/odoo/pull/175344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177209
Original PR description
In some cases, like when another tests activates a language, the log output can include an extra line. See an example here: https://runbot.odoo.com/runbot/build/66699073 After this commit, we only check for the logs we care about. See also: https://github.com/odoo/odoo/pull/175344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177209
Before this commit, the user was not able to see the caret icon to indicate autocomplete dropdown in many2one and many2many values. Steps to reproduce: - open documents and then navigate to actions from the configuration. - click on any action and add a rule for any many2many field. - then try to add many2many values to that rule. Observed behavior: No caret is displayed when adding the many2many values. Expected behavior: Now a caret is displayed on hover indicating a dropdown
Original PR description
Before this commit, the user was not able to see the caret icon to indicate autocomplete dropdown in many2one and many2many values. Steps to reproduce: - open documents and then navigate to actions from the configuration. - click on any action and add a rule for any many2many field. - then try to add many2many values to that rule. Observed behavior: No caret is displayed when adding the many2many values. Expected behavior: Now a caret is displayed on hover indicating a dropdown while adding many2many and many2one values. After this commit, the user will be able to see the caret icon to indicate autocomplete dropdown in many2one and many2many values. Task-3777903 Forward-Port-Of: odoo/odoo#178036 Forward-Port-Of: odoo/odoo#158292
Before this commit we had (rare) situation where events would have matching dates, and then Postgres wouldn't guarantee their order, causing issue with pagination. [Reproduce] - have events with the same dates - query the events with and without limit opw-4061191 Forward-Port-Of: odoo/odoo#177553
Original PR description
Before this commit we had (rare) situation where events would have matching dates, and then Postgres wouldn't guarantee their order, causing issue with pagination. [Reproduce] - have events with the same dates - query the events with and without limit opw-4061191 Forward-Port-Of: odoo/odoo#177553
Purpose ======= Fix the traceback appearing when flagging a question or answer without being a moderator. Specification ============= The .forum_answer class has been removed from the element when doing the website_forum redesign (ref: https://github.com/odoo/odoo/commit/4b1cf2e06643171e5ae10ea44648c4db66d09319 ) The element is thus not found and a traceback occurs when trying to perform the animation. Now using the 'o_wforum_answer' element and making sure it exists before callin
Original PR description
Purpose ======= Fix the traceback appearing when flagging a question or answer without being a moderator. Specification ============= The .forum_answer class has been removed from the element when doing the website_forum redesign (ref: https://github.com/odoo/odoo/commit/4b1cf2e06643171e5ae10ea44648c4db66d09319 ) The element is thus not found and a traceback occurs when trying to perform the animation. Now using the 'o_wforum_answer' element and making sure it exists before calling the animation. Task-4058832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173614
Steps to reproduce: - Install `l10n_{ar,pe}_pos` and `l10n_ec_edi_pos` - Enable "Use QR Code on ticket" - Make an order and validate it inside the POS - Open in an incognito window the link given by the QR Code Issues: Internal error, the cause is the multiple else that are added to the `get_info_div` block. This problem is blocking #175591 and #175593 related enterprise PR: https://github.com/odoo/enterprise/pull/68432 Forward-Port-Of: odoo/odoo#176746
Original PR description
Steps to reproduce:
- Install `l10n_{ar,pe}_pos` and `l10n_ec_edi_pos`
- Enable "Use QR Code on ticket"
- Make an order and validate it inside the POS
- Open in an incognito window the link given by the QR Code
Issues:
Internal error, the cause is the multiple else that are added to the `get_info_div` block.
This problem is blocking #175591 and #175593
related enterprise PR: https://github.com/odoo/enterprise/pull/68432
Forward-Port-Of: odoo/odoo#176746This commit fixes an issue that allowed users to paste text containing line breaks inside of a no line break input (like text fields with line_break = False option). This is resolved by replacing line breaks by white spaces on input when the event originates from a paste action. Task 4130435 Forward-Port-Of: odoo/odoo#178044
Original PR description
This commit fixes an issue that allowed users to paste text containing line breaks inside of a no line break input (like text fields with line_break = False option). This is resolved by replacing line breaks by white spaces on input when the event originates from a paste action. Task 4130435 Forward-Port-Of: odoo/odoo#178044
Steps to reproduce: - In a multiple company environment, open Timesheets app - In All Timesheets add a line - While selecting employee we see that we get all the employees from all companies. Issue: - All the employees shouldn't be visible Cause: - An empty domain is getting passed. - Pre saas-17.1 when an empty domain is passed then we get records from within the company. - From saas-17.1 onward an empty gets every possible record. Solution: - Adding the companies to be
Original PR description
Steps to reproduce: - In a multiple company environment, open Timesheets app - In All Timesheets add a line - While selecting employee we see that we get all the employees from all companies. Issue: - All the employees shouldn't be visible Cause: - An empty domain is getting passed. - Pre saas-17.1 when an empty domain is passed then we get records from within the company. - From saas-17.1 onward an empty gets every possible record. Solution: - Adding the companies to be from allowed_company_ids task-3918572 Forward-Port-Of: odoo/odoo#167004
**Current behavior:** Creating a purchase order for >1000 units of a product with a tax that is included in the base price, there will be rounding issues and a corrective SVL will be created with the creation of the invoice which makes it impossible to reset the bill to draft. **Expected behavior:** The SVL value will reflect the true value of the associated moves, no corrective SVL will be created on invoice generation. **Steps to reproduce:** 1. Make a storable product with a cat
Original PR description
**Current behavior:** Creating a purchase order for >1000 units of a product with a tax that is included in the base price, there will be rounding issues and a corrective SVL will be created with the…
**Current behavior:**
Creating a purchase order for >1000 units of a product with a
tax that is included in the base price, there will be rounding
issues and a corrective SVL will be created with the creation of
the invoice which makes it impossible to reset the bill to
draft.
**Expected behavior:**
The SVL value will reflect the true value of the associated
moves, no corrective SVL will be created on invoice generation.
**Steps to reproduce:**
1. Make a storable product with a category having 'average'
costing method
2. Make a purchase tax of 10% with:
`price_include: True`
`repartition_type: tax = {factor_percent: 100, account_id=Tax Paid}`
`include_base_amount': False`
3. Create a purchase order for the product with the new tax,
with a quantity of 1000
4. Confirm the order, validate the picking, create a bill and
confirm it as well
5. Observe that 2 SVL are created (corrective one after the
creation of the invoice)
**Cause of the issue:**
The price unit calculation for the purchase order line's price
unit value is rounded, while the price unit calculation for the
associated account move line is not. The valuation system
compensates for this difference by creating another SVL record.
**Fix:**
Don't round when calculating the price unit for the purchase
order line. We should keep the max amount of precision until
there is an explicit need to round.
opw-3757684
Forward-Port-Of: odoo/odoo#178126
Forward-Port-Of: odoo/odoo#165653added more options to print via cups: - duplex mode (recto/verso), - landscape mode. Task: 3598690 Forward-Port-Of: odoo/odoo#177882
Original PR description
added more options to print via cups: - duplex mode (recto/verso), - landscape mode. Task: 3598690 Forward-Port-Of: odoo/odoo#177882
The tax_discount field was removed in 512574861691. We take the opportunity to also mention our new EDI module. task-4145576 Forward-Port-Of: odoo/odoo#178291
Original PR description
The tax_discount field was removed in 512574861691. We take the opportunity to also mention our new EDI module. task-4145576 Forward-Port-Of: odoo/odoo#178291
Steps to reproduce the bug: - Create two products tracked by Serial Number (SN): “P1” and “P2”. - Update their quantities. - Create a delivery with one unit of each. - Mark it as "To Do". - Go to the detailed operation. - Attempt to edit the "pick from" (`quant_id`) or the serial number of P1. - Save. Problem: The product “P2” is incorrectly updated to “P1”. opw-3995450 Forward-Port-Of: odoo/odoo#177711
Original PR description
Steps to reproduce the bug: - Create two products tracked by Serial Number (SN): “P1” and “P2”. - Update their quantities. - Create a delivery with one unit of each. - Mark it as "To Do". - Go to the detailed operation. - Attempt to edit the "pick from" (`quant_id`) or the serial number of P1. - Save. Problem: The product “P2” is incorrectly updated to “P1”. opw-3995450 Forward-Port-Of: odoo/odoo#177711
Miscellaneous changes
Forward-Port-Of: odoo/enterprise#69208
Original PR description
Forward-Port-Of: odoo/enterprise#69208
ISSUE 1 ======= **Steps to reproduce** 1). Create an event in any appointment type 2). Remove the start date from it -> Traceback occurs **video ref** - https://youtu.be/5NpfiKNdjbc **Technical** in the interval_from_events function when the end time or start time is not defined, it will not be able to unpack the values to their appropriate variables, due to this error occurred. ISSUE 2 ======= **How to reproduce** Step 1) Create an event on resources and set the start time
Original PR description
ISSUE 1 ======= **Steps to reproduce** 1). Create an event in any appointment type 2). Remove the start date from it -> Traceback occurs **video ref** - https://youtu.be/5NpfiKNdjbc **Technical** in the interval_from_events function when the end time or start time is not defined, it will not be able to unpack the values to their appropriate variables, due to this error occurred. ISSUE 2 ======= **How to reproduce** Step 1) Create an event on resources and set the start time = end time Step 2) Click on the edit button -> Traceback video ref - https://youtu.be/csFkJjO6hMQ **Technical** When we set the start = stop then we won't be able to find the interval so we failed to assign the value of the field due to this traceback occurs. **After this PR** Now traceback will not occur. Task-4010880 Forward-Port-Of: odoo/enterprise#67765 Forward-Port-Of: odoo/enterprise#67179