Monday, June 10, 2024
80 changes · saas-17.3
Resolved issues and error corrections
This fixes a small visual issue on invoices when a second currency is enabled. The words between currency and payment term options now line up correctly, making the invoice form cleaner and easier to read.
Original PR description
Install account_accountant Activate Second currency Create an invoice => The "or" and the "in" are not aligned. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Arabic-English invoice report now avoids showing the same product name more than once when the description already includes it. This makes printed invoices clearer for customers and prevents duplicate or triplicate product lines when Arabic is enabled.
Original PR description
Problem: The arabic_english_invoice report displays product name twice since the description includes the product name by default. Solution:The report should only display the description if the description is not the same as the products' name. Otherwise, the report should display the products' name in the same language as the customer. Steps to Reproduce on Runbot: Install sale, l10n_sa, l10n_gcc_invoice Switch to SA Company Create a product with sales description Create an invoice with the product from step 3 Print the invoice report Observe the product name is displayed twice If Arabic is enabled as a language, the product name will be displayed three times, with the 3rd being in Arabic. Ticket link opw-3768196 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The accounting settings now use clearer wording to distinguish regular line discounts from early payment discounts. This helps users choose the right option and reduces confusion when configuring discount-related features.
Original PR description
We have two settings about discounts that are not linked to the same features (one is line discounts, and the other is Early Payment discounts). They are next to each other but not clear at all. Updating text on settings to differentiate between early payments and discounts. Enterprise PR: https://github.com/odoo/enterprise/pull/62039 task-3908720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Demo mode registration for Peppol now follows the updated flow and correctly creates the required EDI user. The Peppol Services button is also hidden in demo mode, reducing confusion for users testing the setup.
Original PR description
The registration flow changed and the demo mode mocking was not adjusted properly, skipping the step of creating an edi user. Additionally, we need to hide Peppol Services button in demo mode by adding a non-stored `account_peppol_edi_mode` field. task-3971063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Duplicating a regular spreadsheet pivot table no longer triggers a crash caused by global filter handling. The fix ensures Odoo-specific global filter logic is only applied to Odoo pivots, improving reliability when users work with spreadsheet pivot tables.
Original PR description
How to reproduce: - go to a runbot (starting saas-17.3, when we introduce the pivot tables) - insert a pivot table (spreadsheet pivot) (select a zone -> top bar menu > insert > pivot table) - go to its sidepanel and click "duplicate pivot" ==> crash The plugin PivotCoreGlobalFilterPlugin mishandles the command `DUPLICATE_PIVOT` as it does not differentiate Odoo pivot (which it should handle) and a non-odoo pivot. Task-3970711 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 fixes an issue where highlighted messages in the chatter were not properly passed to the display area. Users can now more reliably see the message they searched for or were directed to, making navigation in conversations clearer.
Original PR description
Before this PR: Chatter passes `messageHighlight` in it's childEnv by fetching it using a getter. This getter is overridden in it's patch. But in the patch the `messageHighlight` is set after calling `super.setup`. So, when the getter is called `messageHighlight` is never set. So, `messageHighlight` never gets passed down to it's child. After this PR: We set `messageHighlight` before calling `super.setup`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes Point of Sale demo setup behave more consistently by hiding setup choices when demo scenarios are already installed. It also ensures restaurant demo selection works across companies by creating the needed configuration when the restaurant option is installed.
Original PR description
1. When installing point_of_sale with demo, we should immediately hide the scenario options because all the scenarios are already installed. 2. When in a differenct company in demo mode, selecting a restaurant scenario when pos_restaurant is not yet installed should not only install the pos_restaurant module but also create the select scenario config.
This fixes an issue where employee grouping in the Attendance app could ignore filters selected by the user in the Gantt view. Business users will now see attendance information grouped only for the relevant employees, making filtered planning and review screens more accurate.
Original PR description
The current state of _read_group_employee_id ignores the user domain and thus filtering To fix this we apply the domain in the case a user_domain is used in the gantt view
The course content list now hides unwanted borders around disabled icon buttons. This keeps course pages looking cleaner and avoids visual confusion for learners browsing unavailable content.
Original PR description
## Issue In Course List, After v17.3 + There a topless border in icons where button is disabled. Which looks weird and doesn't make sense as we don't need any border there. ## Technical This issue came from this commit odoo@7d66dcb , where `disabled="1"` was added inside the button. The default `btn.disabled` has button outline in [bootstrap](https://github.com/odoo/odoo/blob/51af11c9180fe48ba3492ffd3402a22bde211318/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L3048-L3053) code. That's why the border is appearing there. ## After this PR There will be no borders where icon buttons are disabled. Task-3975450
This update fixes an internal automated test for chat messages so it no longer depends on timing quirks. It helps keep quality checks stable and reduces false failures in the mail app testing pipeline.
Original PR description
The `mark as read when opening chat window` test is incorrect. It receives a message outside the thread focus to have one unread message, then opens the chat window to verify the message is read. The `setFocus` parameter of the `contains` helper is used to remove focus, but it can only focus an element, not blur it. This causes the test to pass only due to the delay between opening the chat window and the mark as read RPC. Properly blurring the composer fixes the issue. fixes runbot-65485
This fixes an issue where customers could receive incorrectly formatted SMS messages from the point of sale. Customer text messages now use the proper message body, improving communication clarity after POS orders.
Original PR description
Before this commit: ==================== A broken SMS body message was sent to the customer. After this commit: =================== The SMS body is now accurately formatted and sent to the customer task -3969131
The attendance screen's In/Out Mode grouping has been corrected so users can filter and review attendance records as expected. This helps HR teams get more reliable views of employee check-in and check-out data without confusion.
Original PR description
task-3961391
This fixes an issue where saved favorite filters could be missed or shown inconsistently when created without a related active record. Users should now see the expected saved filters for the same action, improving reliability in search workflows.
Original PR description
This commit fixes a bug that was introduced by https://github.com/odoo/odoo/pull/163184. Bug Description: When a favorite filter is created from the search bar without an active_id in the global context, the embedded_parent_res_id variable is assigned a False value. However, since embedded_parent_res_id is an integer, it defaults to 0 in the database. Consequently, when retrieving filters for the same action, the newly created favorite filter appears because the system searches for a False value for embedded_parent_res_id , but a 0 value is stored in the database. Solution: Modify the action_domain to fetch both False and 0 values. 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
The spreadsheet context menu now shows the option to use a cell value as a global filter only for the appropriate pivot header cells. This avoids offering an action in cases where it should not apply, reducing confusion for users working with pivot-based spreadsheets.
Original PR description
The context menu (and clickable cell) `use_global_filter` should take the value of the underlying pivot formula, and apply it to the matching global filters. This works, but was supposed to work only for `ODOO.PIVOT.HEADER` formulas, and not simple `ODOO.PIVOT` formulas. This commit fixes the visibility of the `use_global_filter` option in the context menu, so that it is only visible for `ODOO.PIVOT.HEADER`. Also removed/changed tests that were testing that the menu was visible for positional `ODOO.PIVOT` formulas. Task: 3714696 X-original-commit: 746e71c86caf4b458d40759102dfd20a3236c16c
The appointment scheduling share availability button now keeps the proper visual placement on smaller screens. This avoids a confusing raised appearance and improves the booking interface for users on compact displays.
Original PR description
Fix the share availabilities button elevation happening on lower screen sizes. related PR: odoo/enterprise#51755 Task-3975976
The wording for deferred entry settings in Accounting has been updated to be clearer and more consistent with nearby settings. This helps users better understand the option when configuring accounting behavior.
Original PR description
Update deferred entries settings text to be clearer and consistent with surrounding settings text updated in: https://github.com/odoo/odoo/pull/164539 task-3908720
This update makes an internal automated test for attendance planning more stable by avoiding a timing issue. It helps reduce false build failures, making development and releases smoother without changing user-facing behavior.
Original PR description
The test "Future Open Ended record not displayed" could fail if for some reason the domain used to fetchData is computed 1 second or more after the mocked datetime has been applied. In that case the domain constructed in AttendanceGanttModel contains the open ended record and the second assertion fails. Here we choose a safer mocked datetime. see build https://runbot.odoo.com/runbot/build/63759517
The appointment scheduling Gantt view now correctly shows the button for adding closing days again. This restores a missing action that helps users block unavailable dates directly from the planning view.
Original PR description
Since [1] the button never rendered due to the getter `showAddLeaveButton` not properly bound to the component. [1]: https://github.com/odoo/enterprise/commit/d18639785e622d97102227103d62ddb3a2716be6
This fix improves the attendance Gantt view so previously active employees are included when expanding grouped results over a wider time window. It helps managers review attendance information more reliably, especially around employees who were active in the relevant period.
Original PR description
Increase window size for previously active employees
Miscellaneous changes
Reproduce: * Create a database without demo data * Complete some information related to the main company (i.e. from the database manager form) * Install `account` * In the settings, in debug mode, trigger the installation of the demo data manually Result: The data manually set on the company is overridden to be in US, making the demo data of `account` lose its localized aspect. If for some reason the CoA could not be reloaded, we even don't have any demo at all because `try_loading` won'
Original PR description
Reproduce: * Create a database without demo data * Complete some information related to the main company (i.e. from the database manager form) * Install `account` * In the settings, in debug mode, trigger the installation of the demo data manually Result: The data manually set on the company is overridden to be in US, making the demo data of `account` lose its localized aspect. If for some reason the CoA could not be reloaded, we even don't have any demo at all because `try_loading` won't do anything at all. Solution: Do not override value possibly set by the user in the database configuration. We use the company name as a heuristic. If there is already a chart template installed (because the installation of a `l10n` module triggered it), then we try to load the dynamic demo data when loading the demo XML file. Forward-Port-Of: odoo/odoo#168232 Forward-Port-Of: odoo/odoo#166315
**Steps:** - Go to project > task > archive a task - Open portal view of project > go to the same project - Filter the search view by choosing 'Archived' - Click on the archived task **Issue:** - Session error when trying to open the archive task **Cause:** - By clicking on the archived task, page is refreshed and it tries to open the kanban view again and hence gives session expire error **Fix:** - Hiding the archived filter as suggested by the specs of the task because it seems
Original PR description
**Steps:** - Go to project > task > archive a task - Open portal view of project > go to the same project - Filter the search view by choosing 'Archived' - Click on the archived task **Issue:** - Session error when trying to open the archive task **Cause:** - By clicking on the archived task, page is refreshed and it tries to open the kanban view again and hence gives session expire error **Fix:** - Hiding the archived filter as suggested by the specs of the task because it seems to be irrelevant in project sharing - Passing the correct context so that it will take all the tasks in counting and not just the active tasks. **Affected version**: saas-16.3 - master **Task**-3690536 Forward-Port-Of: odoo/odoo#150866
### Steps to reproduce: - Create a storable product with a vendor (in the pruchase tab) - Create a buy reordering rule with that vendor for that product - Select the reordering rule line and snooze it for one day - Create a sale order for #### > the snoozed reordering rule is triggered ### Cause of the issue: The `snoozed_untill` field of the orderpoint is not taken into account by the `_trigger_scheduler` to determine which auto-trigger orderpoint should be applied: https://gith
Original PR description
### Steps to reproduce: - Create a storable product with a vendor (in the pruchase tab) - Create a buy reordering rule with that vendor for that product - Select the reordering rule line and snooze it for one day - Create a sale order for #### > the snoozed reordering rule is triggered ### Cause of the issue: The `snoozed_untill` field of the orderpoint is not taken into account by the `_trigger_scheduler` to determine which auto-trigger orderpoint should be applied: https://github.com/odoo/odoo/blob/4f43eb2e69224c9cb271b6e2ca7533d929333985/addons/stock/models/stock_move.py#L2132-L2138 opw-3901613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168201 Forward-Port-Of: odoo/odoo#165567
**Current behavior:** Depending on the created picking type and product costing method, unlocking a validated picking and changing the quantity field of a move will not update the qty_received field of the respective purchase order line. **Expected behavior:** These values will be synchronized. **Steps to reproduce:** 1. Make a purchase order with a following combination: A) `picking_type = receipt` `product cost_method != standard` B) `picking_type = dropship`
Original PR description
**Current behavior:** Depending on the created picking type and product costing method, unlocking a validated picking and changing the quantity field of a move will not update the qty_received field…
**Current behavior:**
Depending on the created picking type and product costing
method, unlocking a validated picking and changing the quantity
field of a move will not update the qty_received field of the
respective purchase order line.
**Expected behavior:**
These values will be synchronized.
**Steps to reproduce:**
1. Make a purchase order with a following combination:
A) `picking_type = receipt`
`product cost_method != standard`
B) `picking_type = dropship`
(product cost_method is arbitrary)
2. Confirm the order, validate the picking
3. Unlock the picking and change the quantity value of the stock
move
4. Observe that the purchase order's qty_received value does not
change
**Cause of the issue:**
In the case of the receipt picking type, when creating a stock
valuation layer for the related move with a 'standard' product
costing method we do not call `_get_price_unit()`. This method
will compute the qty_received value of a purchase order line.
After we unlock the picking and change the move quantity, this
field will not be recomputed (because it is stored). Thus, it is
not updated.
The dropship case is similar, except in the creation of a
dropship SVL, `_get_price_unit()` is called before checking the
product's cost method- so the bug always occurs.
**Fix:**
Make the purchase order line's qty_received field depend on it's
stock moves' quantities.
Reorder the conditional in the dropship SVL creation so it
matches that of the incoming SVL creation- this is for
improving consistency rather than a necessary modification for
the fix.
opw-3863510
Forward-Port-Of: odoo/odoo#166366If customer returned to confirmation step,by clicking back arrow from already confirmed sale order in portal view, if they would not refresh they would get an error that this Sale Order is not able to be confirmed. Now, in this case, double confirmation is skipped. opw-3819450 Forward-Port-Of: odoo/odoo#161525
Original PR description
If customer returned to confirmation step,by clicking back arrow from already confirmed sale order in portal view, if they would not refresh they would get an error that this Sale Order is not able to be confirmed. Now, in this case, double confirmation is skipped. opw-3819450 Forward-Port-Of: odoo/odoo#161525
Steps to reproduce ================== - Go to CRM - Switch to the graph view - Use the Pie Chart mode - Click on any label => The visibility of the dataset is toggled but the label should be crossed out Solution ======== From the Chart.js v3 migration guide, we can see this > Element.hidden was replaced by chart level status, usable with getDataVisibility(index) / toggleDataVisibility(index) https://www.chartjs.org/docs/latest/migration/v3-migration.html opw-3935183
Original PR description
Steps to reproduce ================== - Go to CRM - Switch to the graph view - Use the Pie Chart mode - Click on any label => The visibility of the dataset is toggled but the label should be crossed out Solution ======== From the Chart.js v3 migration guide, we can see this > Element.hidden was replaced by chart level status, usable with getDataVisibility(index) / toggleDataVisibility(index) https://www.chartjs.org/docs/latest/migration/v3-migration.html opw-3935183 Forward-Port-Of: odoo/odoo#168372 Forward-Port-Of: odoo/odoo#167785
A fix's term was changing during the fw-port, but it's pot file was not re-exported to match. Therefore, re-export so that it translates properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168377 Forward-Port-Of: odoo/odoo#167745
Original PR description
A fix's term was changing during the fw-port, but it's pot file was not re-exported to match. Therefore, re-export so that it translates properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168377 Forward-Port-Of: odoo/odoo#167745
**Steps:** Go to Sales > Products > Products Move to the tab of attributes and variants Create a new attribute with display type as multi-checkbox Add only one value for the attribute created Click on the website stat button **Issue:** When multi-checkbox has single value, it is not displayed on website **Cause:** Attributes selection is hidden if there is only one value available and it's not a custom value **Fix:** Disabling the feature of hiding attributes with single value wh
Original PR description
**Steps:** Go to Sales > Products > Products Move to the tab of attributes and variants Create a new attribute with display type as multi-checkbox Add only one value for the attribute created Click on the website stat button **Issue:** When multi-checkbox has single value, it is not displayed on website **Cause:** Attributes selection is hidden if there is only one value available and it's not a custom value **Fix:** Disabling the feature of hiding attributes with single value when display type is multi-checkbox **Affected Version:** 17.0 ~ master **Task**-3753005 Forward-Port-Of: odoo/odoo#168071 Forward-Port-Of: odoo/odoo#157243
Before this PR, the `website_livechat_chatbot_flow_tour` was failing in no-demo builds. This test uses the demo portal user, which is not available in these cases. This PR fixes the issue by creating a portal user for this test. fixes runbot-65497 Forward-Port-Of: odoo/odoo#168429
Original PR description
Before this PR, the `website_livechat_chatbot_flow_tour` was failing in no-demo builds. This test uses the demo portal user, which is not available in these cases. This PR fixes the issue by creating a portal user for this test. fixes runbot-65497 Forward-Port-Of: odoo/odoo#168429
**Steps to reproduce:** (!!! Spanish EDI credentials required !!!) - Install l10n_es_edi_sii - Switch to a Spanish company (e.g. ES Company) - Configure Spanish Localization - Create an invoice - Process it by the ES E-invoicing service - Once processed, an electronic document containing the response of the E-invoicing service is created (i.e. jsondump.json) **Issue:** When sending the invoice via "SEND & PRINT" button, the "jsondump.json" file is added in the attachments. opw-37209
Original PR description
**Steps to reproduce:** (!!! Spanish EDI credentials required !!!) - Install l10n_es_edi_sii - Switch to a Spanish company (e.g. ES Company) - Configure Spanish Localization - Create an invoice - Process it by the ES E-invoicing service - Once processed, an electronic document containing the response of the E-invoicing service is created (i.e. jsondump.json) **Issue:** When sending the invoice via "SEND & PRINT" button, the "jsondump.json" file is added in the attachments. opw-3720984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167950
Current behavior: --- Expiry dates are computed from today's date and expiration time, it should be based on scheduled date. Steps to reproduce: --- 1. Go to Inventory 2. Go to Configuration > Operations Types 3. Click on Receipts 4. Check "Show Detailed Operations" box 5. Check "Pre-fill Detailed Operations" box 6. Go back to Inventory > Products 7. Create a new product 8. Go to the Inventory tab 9. At Tracking, put "By lots" 10. Check "Expiration date" Box 11. At "Expiration D
Original PR description
Current behavior: --- Expiry dates are computed from today's date and expiration time, it should be based on scheduled date. Steps to reproduce: --- 1. Go to Inventory 2. Go to Configuration > Operations Types 3. Click on Receipts 4. Check "Show Detailed Operations" box 5. Check "Pre-fill Detailed Operations" box 6. Go back to Inventory > Products 7. Create a new product 8. Go to the Inventory tab 9. At Tracking, put "By lots" 10. Check "Expiration date" Box 11. At "Expiration Date" input 10 12. Go back to Inventory > Receipts 13. Make a new receipt 14. At "Scheduled Date" input a new date 15. At "Add a line" add the product 16. Expiration date is today + 10 17. It should be new date + 10 Fix: --- Replaced today with scheduled_date opw-3813132 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167834 Forward-Port-Of: odoo/odoo#164179
Inspired by 8eba16db6fdf26b5a1e0a10d7f03863eb0d40632 Forward-Port-Of: odoo/odoo#167827 Forward-Port-Of: odoo/odoo#166959
Original PR description
Inspired by 8eba16db6fdf26b5a1e0a10d7f03863eb0d40632 Forward-Port-Of: odoo/odoo#167827 Forward-Port-Of: odoo/odoo#166959
task-3597205 Forward-Port-Of: odoo/odoo#168128 Forward-Port-Of: odoo/odoo#159477
Original PR description
task-3597205 Forward-Port-Of: odoo/odoo#168128 Forward-Port-Of: odoo/odoo#159477
Before this commit, when receiving a chatter notification, clicking on notification opens chat window to the oldest message. This happens because the default scroll top for all chatter threads was 0, taking into account that a chatter thread in form view is in DESC mode (i.e. messages are ordered from top to bottom, from newest to oldest). However, chatter in chat window is displayed in ASC mode like channels (i.e. messages are ordered from top to bottom, from oldest to newest). Scrolltop
Original PR description
Before this commit, when receiving a chatter notification, clicking on notification opens chat window to the oldest message. This happens because the default scroll top for all chatter threads was 0,…
Before this commit, when receiving a chatter notification, clicking on notification opens chat window to the oldest message. This happens because the default scroll top for all chatter threads was 0, taking into account that a chatter thread in form view is in DESC mode (i.e. messages are ordered from top to bottom, from newest to oldest). However, chatter in chat window is displayed in ASC mode like channels (i.e. messages are ordered from top to bottom, from oldest to newest). Scrolltop 0 means newest in chatter form view, but this becomes oldest in chat window with ASC order. This commit fixes the issue by normalizing the storing of thread scroll positions to ASC, so that default value is "bottom" regardless of order to display. in ASC, this is handled like before, but in DESC mode it translates "bottom" to 0. opw-3891999 Before  After  Forward-Port-Of: odoo/odoo#168291 Forward-Port-Of: odoo/odoo#167760
## Issue: When creating an activity linked to a record like a lead, if we edit this activity, for example from To-Do to Meeting, we lose the context from the Lead and have a bad context based on the activity instead, resulting in an improper link in the calendar. ## Steps to reproduce: 1. Install CRM (this will also install the rest of the required modules). 2. Create or use an existing Lead. 3. Create a new To-Do activity. 4. Click on edit for this activity and change it to Meeting. 5
Original PR description
## Issue: When creating an activity linked to a record like a lead, if we edit this activity, for example from To-Do to Meeting, we lose the context from the Lead and have a bad context based on the…
## Issue: When creating an activity linked to a record like a lead, if we edit this activity, for example from To-Do to Meeting, we lose the context from the Lead and have a bad context based on the activity instead, resulting in an improper link in the calendar. ## Steps to reproduce: 1. Install CRM (this will also install the rest of the required modules). 2. Create or use an existing Lead. 3. Create a new To-Do activity. 4. Click on edit for this activity and change it to Meeting. 5. Now click on Open Calendar and place the activity. 6. Click on the calendar event we have just created, and we will see a link to "Activity". Click on it. ## Solution: To ensure the proper link to the Lead/Opportunity, we need to pass the right context when editing the activity. This issue arose from changes made in `activity_service.js` and the addition of the model `mail.activity.schedule`, which separates the edit and create functions, unlike the behavior we had in 16.0. opw-3942711 Before  After  Forward-Port-Of: odoo/odoo#168099 Forward-Port-Of: odoo/odoo#167996
Before this commit, there was a race condition in the way kanban progressbar were handled: when the kanban view was reloaded, two (sequences of) rpcs were done: 1) by the model, to load the data (e.g. 1 web_read_group followed by n web_search_read) 2) by the progress bar hook, to load progressbar data. 1 and 2 weren't synchronized, and if 2 returned after 1, the view wasn't re-rendered to reflect the new progressbar data. This issue was caused by a misuse of owl reactivity: in th
Original PR description
Before this commit, there was a race condition in the way kanban progressbar were handled: when the kanban view was reloaded, two (sequences of) rpcs were done: 1) by the model, to load the data…
Before this commit, there was a race condition in the way kanban
progressbar were handled: when the kanban view was reloaded, two
(sequences of) rpcs were done:
1) by the model, to load the data (e.g. 1 web_read_group followed
by n web_search_read)
2) by the progress bar hook, to load progressbar data.
1 and 2 weren't synchronized, and if 2 returned after 1, the view
wasn't re-rendered to reflect the new progressbar data. This issue
was caused by a misuse of owl reactivity: in the progressbar hook,
in onWillUpdateProps, we didn't call loadProgressBar on the reactive
version of the progressbar state, so changes in that state didn't
trigger a rendering.
Fixing this highlighted a bunch of other issues, all of them kind
of related to the fact that the model and the progressbar don't
synchronize when fetching their data. In particular, scenarios
where the progressbar data was loaded before the kanban data failed,
because the rendering triggered by the progressbar state mutation
(now that it is reactive) altered its caches (see `getGroupInfo`)
or even the groups (see `applyFilter`), with almost outdated
datapoints that were about to be replaced (as soon as the new root
would be loaded).
Properly fixing this isn't possible in stable versions as it might
require an in-depth rework of the way the progressbar interacts
with the model. This will be done in master.
For stable, we found a workaround that seems to be enough: instead
of hooking on `onWillUpdateProps` to reload the progressbar (i.e.
in parallel of the model), we hook on `onWillRender` (i.e. once
the model has loaded the data), and we only load the progressbar
data when the root changed (i.e. as often as before). But by doing
that sequentially, we ensure that the data are always loaded first,
and that the rendering produced by the mutations done on the
progressbar state is done with the correct datapoints.
Master task-3928143
opw-3634027
Forward-Port-Of: odoo/odoo#167178
Forward-Port-Of: odoo/odoo#149626This commit updates the logic to enable the modification of quantities for combo products in the cart. Task ID: 3872513 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168254 Forward-Port-Of: odoo/odoo#166695
Original PR description
This commit updates the logic to enable the modification of quantities for combo products in the cart. Task ID: 3872513 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168254 Forward-Port-Of: odoo/odoo#166695
Steps to reproduce: ------------------- - create a project - create an invoice with Analytic Distribution for the project - go to the project's updates - in profitability section, click on "Customer Invoices" Issue: ------ A notification appears: ``` It seems the record with ID X cannot be found. It might have been deleted. ``` Cause: ------ The arguments in JSON format are: ``` "["other_invoice_revenues", [["id", "in", [X]]], X]" ``` with X not corresponding to the invoice
Original PR description
Steps to reproduce: ------------------- - create a project - create an invoice with Analytic Distribution for the project - go to the project's updates - in profitability section, click on "Customer Invoices" Issue: ------ A notification appears: ``` It seems the record with ID X cannot be found. It might have been deleted. ``` Cause: ------ The arguments in JSON format are: ``` "["other_invoice_revenues", [["id", "in", [X]]], X]" ``` with X not corresponding to the invoice id. They are determined by the method `_get_action_for_profitability_section`. In which the ids are `invoices_move_lines.ids` (in `_get_revenues_items_from_invoices`). Solution: --------- Find the `account.move` from the `account.move.line`. Note: Introduced with the commit abd40a461c289bfe092784977077ceb1c7ef12f3 opw-3924836 Forward-Port-Of: odoo/odoo#168260 Forward-Port-Of: odoo/odoo#167721
In "Task-3890068 OPW-3787054" the customer is facing the issue regarding the activity. on clicking on activity they are getting all the records instead of the filtered data. Solution: 1) Added the code to enable "late" or "today" activity filter by default. 2) Added the on-click into the XML to get the activity for the appropriate button. Before PR: Not able to get the filtered record Video: https://drive.google.com/file/d/1s2K-1-n9y2hmRJhrxyZXGgGRoZ1KACSv/view?usp=sharing After PR
Original PR description
In "Task-3890068 OPW-3787054" the customer is facing the issue regarding the activity. on clicking on activity they are getting all the records instead of the filtered data. Solution: 1) Added the code to enable "late" or "today" activity filter by default. 2) Added the on-click into the XML to get the activity for the appropriate button. Before PR: Not able to get the filtered record Video: https://drive.google.com/file/d/1s2K-1-n9y2hmRJhrxyZXGgGRoZ1KACSv/view?usp=sharing After PR: Enable the filter (late, today and future activities) Video: https://drive.google.com/file/d/1a2mRHfZeHqvPcDHyIa6PlKyYw1HiImv7/view?usp=sharing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168112 Forward-Port-Of: odoo/odoo#162567
**Steps:** - Go to Sales > Products > Products > Any Product - Click Documents smart button > Create New - Type = URL - Name = Something - URL = Something - Sales Visibility = Inside Quote - Save > Error **Issue:** - For the type 'url' and sales visibility 'Inside quote', the record will never get the correct mimetype of the url document, resulting into the false condition everytime as pdf quote builder specifically checks for mimetype 'pdf'. **Fix:** - If the sale visibility is '
Original PR description
**Steps:** - Go to Sales > Products > Products > Any Product - Click Documents smart button > Create New - Type = URL - Name = Something - URL = Something - Sales Visibility = Inside Quote - Save > Error **Issue:** - For the type 'url' and sales visibility 'Inside quote', the record will never get the correct mimetype of the url document, resulting into the false condition everytime as pdf quote builder specifically checks for mimetype 'pdf'. **Fix:** - If the sale visibility is 'Inside quote', the type should always be File and not URL. If not the case, warning or validation error will be raised. **Affected Version:** 17 ~ master **opw:** 3964066 Forward-Port-Of: odoo/odoo#168310
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166788
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166788
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#164514
Original PR description
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#164514
Before this commit, when a product had multiple categories, it was shown in all its categories in the x/z reports. This commit changes the feature so that the product is only shown in one category (first in sequence). task-id: 3973199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168171
Original PR description
Before this commit, when a product had multiple categories, it was shown in all its categories in the x/z reports. This commit changes the feature so that the product is only shown in one category (first in sequence). task-id: 3973199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168171
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Planning : fix the spacing issue in slot conflict warning -------------- Steps to reproduce: - Open planning - Click on a slot which has already been allocated and add select both role and project - Open the first task in the slot to get the slot conflict warning text. Issue: - There is a large gap between Slot timings and percentage. Cause: - The whole warning is in a d-grid where conflict slot timings are one and other total hours role and project are another part of both l
Original PR description
Planning : fix the spacing issue in slot conflict warning -------------- Steps to reproduce: - Open planning - Click on a slot which has already been allocated and add select both role and project -…
Planning : fix the spacing issue in slot conflict warning
--------------
Steps to reproduce:
- Open planning
- Click on a slot which has already been allocated and add select both role and project
- Open the first task in the slot to get the slot conflict warning text.
Issue:
- There is a large gap between Slot timings and percentage.
Cause:
- The whole warning is in a d-grid where conflict slot timings are one and other total hours role and project are another part of both length 1fr.
- So whenever there is project name and role_id it makes the both of same length 1fr which adds the gap in true sense.
Selection:
- Using auto for the first part makes sure that the timing section does have fixed length.
- Also the timing section of the grid is the same unlike the the details section
Industry : fix creation of non-fsm task in fsm
------------
Steps to reproduce:
- Open Field Service
- Create a task so that a conflict b/w task is created
- Click on the conflicting task and click on edit
- In the form a conflict warning is shown
- Click on 'Check It Out'
- In the view opened view click on any empty slot
Issues:
- The issue is that in the opened form Field Service is not selected as default
project the task is set to 'Private'
Cause:
- Missing context causing this
Solution:
- Passing a context in the action window solves the issue.
task:3850839
Forward-Port-Of: odoo/enterprise#60602Versions -------- - 15.0e+ Steps ----- 1. If current UTC time is before 11:00, set user tz to Pacific/Niue; 2. if current UTC time is after 11:00, set user tz to Pacific/Kiritimati; 3. go to Helpdesk; 4. enable timesheets for a helpdesk team; 5. open a ticket of that helpdesk team; 6. start timer; 7. stop timer; 8. create timesheet. Issue ----- The date of the timesheet is set to the UTC date instead of the user date, which is one day off. Cause ----- The wizard creating
Original PR description
Versions -------- - 15.0e+ Steps ----- 1. If current UTC time is before 11:00, set user tz to Pacific/Niue; 2. if current UTC time is after 11:00, set user tz to Pacific/Kiritimati; 3. go to Helpdesk; 4. enable timesheets for a helpdesk team; 5. open a ticket of that helpdesk team; 6. start timer; 7. stop timer; 8. create timesheet. Issue ----- The date of the timesheet is set to the UTC date instead of the user date, which is one day off. Cause ----- The wizard creating timesheets adds a `Datetime.now()` value to `date`, which defaults to UTC time. Solution -------- Remove this line, allowing timesheets to be created with the default value, which does get adjusted for user timezone. opw-3834908 Forward-Port-Of: odoo/enterprise#63806 Forward-Port-Of: odoo/enterprise#63073
The issue: Inside the function _l10n_co_edi_generate_xml, the variable 'tax' at line 272 will be overridden by the 'account.tax' record which leads to a traceback in the second iteration, saying 'account.tax' object doesn't have a 'get' attribute Expected behavior: To not throw a traceback and generate the xml opw-3899575 Forward-Port-Of: odoo/enterprise#63277 Forward-Port-Of: odoo/enterprise#62290
Original PR description
The issue: Inside the function _l10n_co_edi_generate_xml, the variable 'tax' at line 272 will be overridden by the 'account.tax' record which leads to a traceback in the second iteration, saying 'account.tax' object doesn't have a 'get' attribute Expected behavior: To not throw a traceback and generate the xml opw-3899575 Forward-Port-Of: odoo/enterprise#63277 Forward-Port-Of: odoo/enterprise#62290
Before this PR: The 8-column report for the "current year earnings" account type (equity_unaffected) incorrectly included the previous balance. This caused inconsistencies in reports, leading to imbalances between debit/credit and debtor/creditor columns, as well as assets/liabilities. Previously, this issue could be addressed by modifying the include_initial_balance boolean in the "account.user.type" model. However, this boolean is now computed and resides in the "account.account" model, ma
Original PR description
Before this PR: The 8-column report for the "current year earnings" account type (equity_unaffected) incorrectly included the previous balance. This caused inconsistencies in reports, leading to imbalances between debit/credit and debtor/creditor columns, as well as assets/liabilities. Previously, this issue could be addressed by modifying the include_initial_balance boolean in the "account.user.type" model. However, this boolean is now computed and resides in the "account.account" model, making it uneditable. After this PR: This fix ensures the "current year earnings" account reflects only the activity for the current period, excluding the previous balance. This change eliminates the need to rely on the include_initial_balance state for this account, leading to a consistent and accurate 8-column report. Forward-Port-Of: odoo/enterprise#63699 Forward-Port-Of: odoo/enterprise#60713
In previous commit https://github.com/odoo/enterprise/commit/099531438fe9ef7b008a2b281780ed3ee2175692 we added a new tag check. As we tought it was empty for non-nordic countries, we thought it was fine to have it in first place but happens it is sometimes filled in other countries but not with the payment reference, as in Switzerland. We now check to fill payment_ref, in order: 1. NtryDtls>RmtInf>Ustrd 2. NtryDtls>RmtInf>Strd>CdtrRefInf>Ref 3. Ntry>AddtlNtryInf (was buggy before https://g
Original PR description
In previous commit https://github.com/odoo/enterprise/commit/099531438fe9ef7b008a2b281780ed3ee2175692 we added a new tag check. As we tought it was empty for non-nordic countries, we thought it was fine to have it in first place but happens it is sometimes filled in other countries but not with the payment reference, as in Switzerland. We now check to fill payment_ref, in order: 1. NtryDtls>RmtInf>Ustrd 2. NtryDtls>RmtInf>Strd>CdtrRefInf>Ref 3. Ntry>AddtlNtryInf (was buggy before https://github.com/odoo/enterprise/pull/62703) 4. NtryDtls>RmtInf>Strd>AddtlRmtInf opw-3923665 opw-3971080 opw-3932651 opw-3918491 Forward-Port-Of: odoo/enterprise#64004
task-3597205 Forward-Port-Of: odoo/enterprise#63869 Forward-Port-Of: odoo/enterprise#59539
Original PR description
task-3597205 Forward-Port-Of: odoo/enterprise#63869 Forward-Port-Of: odoo/enterprise#59539
Button draft was not display on received vendor bills. opw-3903120 Forward-Port-Of: odoo/enterprise#64020
Original PR description
Button draft was not display on received vendor bills. opw-3903120 Forward-Port-Of: odoo/enterprise#64020
…on report steps to reproduce: - add new appraisal of employee and confirm it. - add new skills and update existing ones. - check the skill evaluation report issue: A newly created skill doesn't appear in the report since the previous skill level may contain null while creating new records. fix: Apply a left join on the report so that it can provide accurate results. also, add a subquery based on the last completed appraisal, since the last `appraisal_id` is updated on the pending
Original PR description
…on report steps to reproduce: - add new appraisal of employee and confirm it. - add new skills and update existing ones. - check the skill evaluation report issue: A newly created skill doesn't appear in the report since the previous skill level may contain null while creating new records. fix: Apply a left join on the report so that it can provide accurate results. also, add a subquery based on the last completed appraisal, since the last `appraisal_id` is updated on the pending state too. task-3810220 Forward-Port-Of: odoo/enterprise#64035 Forward-Port-Of: odoo/enterprise#60088
Purpose: -------- The frontend room view uses the "background-image" property to add a background image if one has been set on the room. This causes several 404 errors in qunit tests because the test room does not exist, resulting in a "room not found" exception when the browser tries to get the background image. This commit patches the view in the tests to remove the url part of the background-image property, so that the background image is not fetched anymore. In order to make th
Original PR description
Purpose: -------- The frontend room view uses the "background-image" property to add a background image if one has been set on the room. This causes several 404 errors in qunit tests because the test room does not exist, resulting in a "room not found" exception when the browser tries to get the background image. This commit patches the view in the tests to remove the url part of the background-image property, so that the background image is not fetched anymore. In order to make this patch possible, the background-image property value has been moved inside a getter. Task-3943099 Forward-Port-Of: odoo/enterprise#62990
Versions -------- - 17.0+ Steps ----- 1. Go to an employee w/ a running contract; 2. open their working schedule; 3. change lunch breaks from the default 12:00 to 12:30; 4. go to the Payroll app; 5. check the work entries of the employee. Issue ----- Each work entry has two rows: 1. first half of working day, pill takes up the entire column; 2. second half of working day, pill takes up half a column. Cause ----- Commit 19c957264ed reworked how gantt pills get rounded, maki
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to an employee w/ a running contract; 2. open their working schedule; 3. change lunch breaks from the default 12:00 to 12:30; 4. go to the Payroll app; 5.…
Versions -------- - 17.0+ Steps ----- 1. Go to an employee w/ a running contract; 2. open their working schedule; 3. change lunch breaks from the default 12:00 to 12:30; 4. go to the Payroll app; 5. check the work entries of the employee. Issue ----- Each work entry has two rows: 1. first half of working day, pill takes up the entire column; 2. second half of working day, pill takes up half a column. Cause ----- Commit 19c957264ed reworked how gantt pills get rounded, making it so that a if a record extends on a day/half-day/hour/month for even a minute, the pill includes it. Because the half-day is hardcoded to 12:00, this means that a lunch break that's one minute later than that will display the first shift as a full day in work entry gantt view. Solution -------- Partially re-introduce the old pill rounding logic for this specific view/module. Add it to the hr_gantt module so the same visual issue gets resolved in hr_attendance_gantt views. For versions 17.3+: Because of the changes to gantt columns introduced by d18639785e622d97102227103d62ddb3a2716be6, the old pill rounding logic was no longer feasible, and new logic was introduced to halve pills spanning 2 half-days if they end before 14:00. opw-3895160 Forward-Port-Of: odoo/enterprise#63643 Forward-Port-Of: odoo/enterprise#62390