Tuesday, March 21, 2023
48 changes · master
Enhancements to existing features
Drag-and-drop behavior in the web interface can now require a longer press before starting. This helps prevent accidental dragging when users are simply clicking or making small pointer movements.
Original PR description
This commit introduces a "delay" parameter used to drag elements on a long mousedown instead of a short one. This is coupled with the "tolerance" parameter to define the area in which the mousedown is considered uninterrupted. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Salary simulation links for Belgian fleet payroll now always treat the company car as new. This keeps simulations aligned with the intended payroll assumptions and reduces ambiguity for employees reviewing compensation offers.
Original PR description
task - 3209443
The timesheet validation screen now changes the validate button color based on whether all timesheets are already validated. This helps managers quickly see when there is still validation work to do versus when everything is complete.
Original PR description
In this commit, If all the timesheets are validate then the color of the validated button will be secondary otherwise it will be primary. task-2813765
Resolved issues and error corrections
Fixed an issue in Knowledge where choosing a random icon for an article could select emojis that should be blocked. Random article icons now use only approved emojis, helping keep content presentation appropriate for users.
Original PR description
This commit fixes a bug introduced in c33fe997f270a086150b628ab1021e9469e89c02 where the addIcon function was modified to accomodate the Discuss refactor. Before this commit when adding a random icon to an article, the random selection of icons would always return the banned emojis, which is the opposite of the desired behavior. Now the icon is always an authorized emoji. task-3239114
Features or functions removed from Odoo
The accounting app no longer includes the redundant tax audit field, which was previously used to show how journal items affected tax report lines. Tax report calculations now use a simpler approach, reducing unnecessary complexity without changing expected reporting outcomes.
Original PR description
the tax_audit field was introduced in v13 and it served the purpose of providing users with improved visibility regarding the impact of move lines on report lines. The computation of the sign for each move line when resolving tax grid amounts has now been simplified using the formula (tax_tag_invert * sign of the tag * balance). Consequently, the tax_audit field has become redundant and is no longer required. Task-id: 3196711 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This update tidies the website sales, digital products, and loyalty areas by improving file organization, naming, and internal code structure. It helps keep the system easier to maintain and reduces the risk of issues from outdated or misplaced configuration, without introducing major user-facing changes.
Original PR description
* Correct file & class names * Code simplification * Imports cleanup * privatize method not meant to be called in rpc * wrong view inheritance target (not containing the targeted hook) * ... --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
This pull request changes the Project app, but the provided description does not explain the specific issue or business outcome. Based on the available information, it appears to be a small project-related change with limited expected impact.
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
This change updates the Project app, but the pull request details do not describe the specific user-facing behavior. Based on the limited information, it appears to be a small adjustment with low expected business impact.
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
Sudo is necessary to delete user notifications on auto-delete. Which makes sense as the recipient would have an email for it anyway. The sudo was there as far back as 2018: c5c369355d095312d44a4793d6b77f7841577c12 Then transfered in this change: 036a739b62d05d437a277125e76c10e99c0f44e9 And removed in the recent optimization here: e38bfd25df1bb25e7e5695b536052d5a0c85c5c4 task-3225207 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forw
Original PR description
Sudo is necessary to delete user notifications on auto-delete. Which makes sense as the recipient would have an email for it anyway. The sudo was there as far back as 2018: c5c369355d095312d44a4793d6b77f7841577c12 Then transfered in this change: 036a739b62d05d437a277125e76c10e99c0f44e9 And removed in the recent optimization here: e38bfd25df1bb25e7e5695b536052d5a0c85c5c4 task-3225207 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#114828
Before this commit - since [1] - a traceback occurs when opening a kanban group config menu if the view has "records_draggable" and "groups_draggable" attributes set to false Explanation - the kanban renderer template do not set a group id on o_kanban_group elements when the aforementioned attrs are false - the kanban renderer then use a selector in order to give the kanban groups config menus their container element (used for positioning the dropdown). - as there is no elements that mat
Original PR description
Before this commit - since [1] - a traceback occurs when opening a kanban group config menu if the view has "records_draggable" and "groups_draggable" attributes set to false Explanation - the kanban renderer template do not set a group id on o_kanban_group elements when the aforementioned attrs are false - the kanban renderer then use a selector in order to give the kanban groups config menus their container element (used for positioning the dropdown). - as there is no elements that matches that selector: a traceback occur later in the usePosition hook positioning logic. After this commit - this is fixed by always setting ids on the group elements. [1]: https://github.com/odoo/odoo/commit/65e43dd88115b46e2d8585cf6dd7af4a89693e68#diff-823da6a5974aafef6ec7d54b4d410ccd8dc54e1892aee57c3bb62ff8a0414826R21 Taskid: 3231051 Forward-Port-Of: odoo/odoo#115813 Forward-Port-Of: odoo/odoo#115730
> **[FIX] web: refocus date field in editable list** > > Before this commit > - an editable list will not refocus a date field after a pick of a date > > After this commit > - it will > > TaskId: 3184929 Forward-Port-Of: odoo/odoo#115817 Forward-Port-Of: odoo/odoo#115656
Original PR description
> **[FIX] web: refocus date field in editable list** > > Before this commit > - an editable list will not refocus a date field after a pick of a date > > After this commit > - it will > > TaskId: 3184929 Forward-Port-Of: odoo/odoo#115817 Forward-Port-Of: odoo/odoo#115656
Add a selection field on the partner to choose the EDI format. Merge the `cii_` and `ubl_` fields. Add an `endpoint_value` and `eas_code` on the partner. These values are read when generating the Bis 3 (or one of its derivatives) to fill the `EndpointID` and the `@schemeID` in the xml. We can remove `l10n_nl_oin` and `l10n_nl_kvk` which are only used by electronic invoicing, and replace every usage of them by the new fields `endpoint_value` and `eas_code` (since for NL partners, they shoul
Original PR description
Add a selection field on the partner to choose the EDI format. Merge the `cii_` and `ubl_` fields. Add an `endpoint_value` and `eas_code` on the partner. These values are read when generating the Bis 3 (or one of its derivatives) to fill the `EndpointID` and the `@schemeID` in the xml. We can remove `l10n_nl_oin` and `l10n_nl_kvk` which are only used by electronic invoicing, and replace every usage of them by the new fields `endpoint_value` and `eas_code` (since for NL partners, they should necessarily represent the KVK or OIN number: eas code '0106' or '0190'). We can also remove the `l10n_lu_peppol_id` module which was only there to allow an arbitrary number to be set on the `EndpointID` (for instance, for public administration that doesn't have a vat number). task-3232845 upgrade: https://github.com/odoo/upgrade/pull/4445 Forward-Port-Of: odoo/odoo#115627
Since 16.2, a condition was added to _get_available_qr_methods : ``` if self.env.company.country_id.code == 'CH': rslt.append(('ch_qr', _("Swiss QR bill"), 10)) ``` This condition was not allowing a multi-company call, and caused another issue. Once the method was called to check on the eligible QR choices, the ORM would consider the current company to be the US default one. Hence the condition would never be fulfilled and a stacktrace would appear : ``` Oh s
Original PR description
Since 16.2, a condition was added to _get_available_qr_methods :
```
if self.env.company.country_id.code == 'CH':
rslt.append(('ch_qr', _("Swiss QR bill"), 10))
```
This condition was not allowing a multi-company call, and caused another issue.
Once the method was called to check on the eligible QR choices, the ORM would consider the current company to be the US default one.
Hence the condition would never be fulfilled and a stacktrace would appear :
```
Oh snap!
Wrong value for account.move.qr_code_method: 'ch_qr'
```
Reverted back to the unconditional behaviour, and will check this occurence with the framework team.
Forward-Port-Of: odoo/odoo#115848Steps to reproduce: - Install Sales, Subscriptions or similar app. - Go to Sales, and try to save a favorite filter without name. - It can also be done in the order lines of the Subscriptions, if we try to add a product and select "search more", inside the new window try to add a favorite filter without name. Issue: We got a traceback that's not user friendly instead of the proper warning message, this is because inside the `saveFavorite` method we check if the description is empt
Original PR description
Steps to reproduce: - Install Sales, Subscriptions or similar app. - Go to Sales, and try to save a favorite filter without name. - It can also be done in the order lines of the Subscriptions, if we try to add a product and select "search more", inside the new window try to add a favorite filter without name. Issue: We got a traceback that's not user friendly instead of the proper warning message, this is because inside the `saveFavorite` method we check if the description is empty, but we can't use `.length` because when we don't fill any name, the description is `undefined`. Solution: Removing the `.length` check, and just checking if the description is undefined or not. Forward bot up to master. opw-3200499 Forward-Port-Of: odoo/odoo#114791
Description of the issue/feature this PR addresses: Desired behavior after PR is merged: Increasing the floating point precision of the rate in accrual plan levels to 5 digits and displaying it correctly by removing the unnecessary trailing zeros after the coma using JS. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113825 Forward-Port-Of: odoo/odoo#112520
Original PR description
Description of the issue/feature this PR addresses: Desired behavior after PR is merged: Increasing the floating point precision of the rate in accrual plan levels to 5 digits and displaying it correctly by removing the unnecessary trailing zeros after the coma using JS. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#113825 Forward-Port-Of: odoo/odoo#112520
The pictures of the employees were no longer showing in the kiosk mode as it tried to read on `hr.employee` instead of the `hr.employee.public` model. Forward-Port-Of: odoo/odoo#115875
Original PR description
The pictures of the employees were no longer showing in the kiosk mode as it tried to read on `hr.employee` instead of the `hr.employee.public` model. Forward-Port-Of: odoo/odoo#115875
Step to reproduce: - Install E-learning module - Go to any course and set `Display` to `Documentation` - Click on `Go to website` and open editor - Click on `Theme`, then in `Theme Colors` section, click on the palette and select the first custom colors (black-white-gray) Issue: The background of the submenu (just under `Course` tab) is transparent (while it should be black, like main menu) and the links are not well displayed (white/light text color). (Same i
Original PR description
Step to reproduce: - Install E-learning module - Go to any course and set `Display` to `Documentation` - Click on `Go to website` and open editor - Click on `Theme`, then in `Theme Colors` section,…
Step to reproduce:
- Install E-learning module
- Go to any course and set `Display` to `Documentation`
- Click on `Go to website` and open editor
- Click on `Theme`, then in `Theme Colors` section, click on the
palette and select the first custom colors (black-white-gray)
Issue:
The background of the submenu (just under `Course` tab) is
transparent (while it should be black, like main menu) and the links
are not well displayed (white/light text color).
(Same issue with navbar brand and toggler when reducing screen width)
Cause:
The background of the submenu is always set to transparent but
the text color change depending if the top main menu background
is dark or light.
Lines that make the issue: https://github.com/odoo/odoo/blob/693092f2c90e36735c6896b6c6e7d795406453e9/addons/website/static/src/scss/website.scss#L240-L252
Solution:
Set the text color (and the background of the toggler) to
`light` color if background is dark (determined with
`color-yiq($body-bg)`), otherwise use `dark` color.
opw-3086750
Forward-Port-Of: odoo/odoo#115200
Forward-Port-Of: odoo/odoo#111644**ISSUE** A header button in the list view with "confirm" attribute doesn't show a confirmation dialog when clicked. This is different to the header buttons from the form view. **SOLUTION** In order to achieve similar behaviour, we reuse the BUTTON_CLICK_PARAMS which originated from thew view_compiler and make sure that buttons parsed from the other views also contain the correct set of clickParams. TASK-ID: 3216357 --- I confirm I have signed the CLA and read the PR guide
Original PR description
**ISSUE** A header button in the list view with "confirm" attribute doesn't show a confirmation dialog when clicked. This is different to the header buttons from the form view. **SOLUTION** In order to achieve similar behaviour, we reuse the BUTTON_CLICK_PARAMS which originated from thew view_compiler and make sure that buttons parsed from the other views also contain the correct set of clickParams. TASK-ID: 3216357 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115779 Forward-Port-Of: odoo/odoo#115542
This problem occurs because the foreach using by the xml trigger a full rerender of the node in owl. To avoid these weird behavior, we now keep the scrollTop of the scroll item, the column should remain at the same place the end user was when clicking on the 'load more' button Steps to reproduce: - Open a kanban view with enough records for a 'load more' button to be displayed - click on Load more => the column remains scrolled all the way down, making the user lose track of where they we
Original PR description
This problem occurs because the foreach using by the xml trigger a full rerender of the node in owl. To avoid these weird behavior, we now keep the scrollTop of the scroll item, the column should remain at the same place the end user was when clicking on the 'load more' button Steps to reproduce: - Open a kanban view with enough records for a 'load more' button to be displayed - click on Load more => the column remains scrolled all the way down, making the user lose track of where they were before clicking on the button => bug Task ID: 3196763 Forward-Port-Of: odoo/odoo#115936 Forward-Port-Of: odoo/odoo#115706
**Current behavior before PR:** Portal users are not able to join RTC Calls in Discuss. **Desired behavior after PR is merged:** Portal users are able to join RTC Calls. Task-3050534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115778 Forward-Port-Of: odoo/odoo#105522
Original PR description
**Current behavior before PR:** Portal users are not able to join RTC Calls in Discuss. **Desired behavior after PR is merged:** Portal users are able to join RTC Calls. Task-3050534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115778 Forward-Port-Of: odoo/odoo#105522
Before this commit, you could search `account.tax.repartition.line` and get records from all the existing companies, which is not supposed to happen. It should only return records of the `active_company_ids`. That was because there were no `ir.rule` preventing that. This fixes the issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115493 Forward-Port-Of: odoo/odoo#114718
Original PR description
Before this commit, you could search `account.tax.repartition.line` and get records from all the existing companies, which is not supposed to happen. It should only return records of the `active_company_ids`. That was because there were no `ir.rule` preventing that. This fixes the issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115493 Forward-Port-Of: odoo/odoo#114718
Several status bar buttons having long names combined with several status bar field items results to terrible layout. To make it a little better: - We wrap the status bar buttons so that each button will have single-line label. - We also prevent the container of the statusbar field items from shrinking until a max-width of 50%. - In case there is multiple lines of status bar buttons and single line of statusbar field items, we keep the vertical alignment of the statusb
Original PR description
Several status bar buttons having long names combined with several status bar field items results to terrible layout. To make it a little better: - We wrap the status bar buttons so that each button…
Several status bar buttons having long names combined with several status
bar field items results to terrible layout.
To make it a little better:
- We wrap the status bar buttons so that each button will have single-line
label.
- We also prevent the container of the statusbar field items from shrinking
until a max-width of 50%.
- In case there is multiple lines of status bar buttons and single line
of statusbar field items, we keep the vertical alignment of the
statusbar field items at the top.
This solution is not really very good but it's okayish.
A better solution can be like providing a way to allow dropdown menu for
the "extra" buttons that won't fit in a single line. For the future?
TASK-ID: 3215622
**FOR ILLUSTRATION**
**Before**
<img width="1512" alt="Screenshot 2023-03-20 at 09 40 46" src="https://user-images.githubusercontent.com/3245568/226288324-bf602bad-9907-41cb-a651-5eea9f7c45f8.png">
**After**
<img width="1512" alt="Screenshot 2023-03-20 at 09 38 55" src="https://user-images.githubusercontent.com/3245568/226288300-e8d34019-4090-4524-960f-5336d2583ef4.png">
<img width="1103" alt="Screenshot 2023-03-20 at 11 16 12" src="https://user-images.githubusercontent.com/3245568/226312795-3f72cf35-37d1-412b-959b-273648c6c3fc.png">
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#115803Purpose ======= Allow to use the following domain in views ``` [('properties', '=', [])] ``` To be able to show / hide elements based on the fact that the properties is empty or not. Task-3213639 Forward-Port-Of: odoo/odoo#115920 Forward-Port-Of: odoo/odoo#114526
Original PR description
Purpose
=======
Allow to use the following domain in views
```
[('properties', '=', [])]
```
To be able to show / hide elements based on the fact that the properties is empty or not.
Task-3213639
Forward-Port-Of: odoo/odoo#115920
Forward-Port-Of: odoo/odoo#114526This change updates the Project app with a small routing-related adjustment. The pull request description does not provide business details, so the expected impact appears limited and specific to project management behavior.
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
Attribute Error: 'frozendict' object has no attribute 'default_product_id' trace back that occurs in stock/stock_quant: action_inventory_at_date was caught by sentry. See:- https://drive.google.com/file/d/1db6ujpr74m6IgosnCTQHuGNHPVcJh3t7/view?usp=share_link steps to produce:- * Install inventory module * Select any product from menuitem/reporting/stock * Click replinish button & from that replinish wizard, select the product again * Then click forecasted stat button and in forecas
Original PR description
Attribute Error: 'frozendict' object has no attribute 'default_product_id' trace back that occurs in stock/stock_quant: action_inventory_at_date was caught by sentry. See:- https://drive.google.com/file/d/1db6ujpr74m6IgosnCTQHuGNHPVcJh3t7/view?usp=share_link steps to produce:- * Install inventory module * Select any product from menuitem/reporting/stock * Click replinish button & from that replinish wizard, select the product again * Then click forecasted stat button and in forecast click On Hand button * Then click Inventory At Date. * At this moment you find a trace back. Because default_product_id is not getting from context in inventory. sentry:-3952193922 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115638
*: point_of_sale,pos_loyalty,pos_restaurant Previously, the payment button was larger than the others and next to the numpad. The other buttons were managed by a mixin and arranged in a predefined order. Now, the payment button only stays in place when the "order" button is not present, currently it can only be present if the restaurant module is installed and a printer configured. When it is present, it takes the place of the payment button and the latter is added to the mixins wi
Original PR description
*: point_of_sale,pos_loyalty,pos_restaurant Previously, the payment button was larger than the others and next to the numpad. The other buttons were managed by a mixin and arranged in a predefined order. Now, the payment button only stays in place when the "order" button is not present, currently it can only be present if the restaurant module is installed and a printer configured. When it is present, it takes the place of the payment button and the latter is added to the mixins with the other buttons --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#114189
This commit fixes the exported fields list used by the export dialog. Since the list was deducted from the column titles, it was not possible to get the complete attributes required to filter them. Now we use the real fields fetched from the RPC in the dialog. It fetches the correct list of exportable fields, and the defaultExportList props only serves to list fields associated with visible columns. It is now possible to filter fields correctly, and improve the reliability of the export featu
Original PR description
This commit fixes the exported fields list used by the export dialog. Since the list was deducted from the column titles, it was not possible to get the complete attributes required to filter them. Now we use the real fields fetched from the RPC in the dialog. It fetches the correct list of exportable fields, and the defaultExportList props only serves to list fields associated with visible columns. It is now possible to filter fields correctly, and improve the reliability of the export feature, to use the data from the RPC instead of using the data deducted from the visible columns only. A test has been added to verify the presence of a field that has the defaut_exportable attribute in the export list by default. task-3203958 Forward-Port-Of: odoo/odoo#114524
OSError: cannot read from timed out object while evaluating a "model._fetch_mails()", it occurs because when we try to quit a POP server of incoming mail using the "pop_server.quit()" method, sometimes it is not able to reach the remote server to quit the pop server, so it throws an OSError. see https://drive.google.com/file/d/1Xh4gnS5xUSB4e_XOshyC7r5814gEXSdR/view?usp=sharing We added "pop_server.quit()" to the try block; if it fails to quit the server, a warning will be displayed usi
Original PR description
OSError: cannot read from timed out object while evaluating a "model._fetch_mails()", it occurs because when we try to quit a POP server of incoming mail using the "pop_server.quit()" method, sometimes it is not able to reach the remote server to quit the pop server, so it throws an OSError. see https://drive.google.com/file/d/1Xh4gnS5xUSB4e_XOshyC7r5814gEXSdR/view?usp=sharing We added "pop_server.quit()" to the try block; if it fails to quit the server, a warning will be displayed using the logger. sentry-3932133536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#112948
This commit fixes the name_search traceback on project tags when the `project_id` in context is set to `False`. Prior to commit odoo/odoo@05855b6b this check was still relevant since the implementation used the ORM search method. Since this commit, project_id must be an integer to be used in the SQL query. Steps to reproduce: - Open Project menu; - Go to My Tasks menu; - Create a new task; - Open task; - Click on Tags field. Current Behavior: ``` File "/home/src/odoo/odoo/model
Original PR description
This commit fixes the name_search traceback on project tags when the `project_id` in context is set to `False`. Prior to commit odoo/odoo@05855b6b this check was still relevant since the…
This commit fixes the name_search traceback on project tags when the `project_id` in context is set to `False`.
Prior to commit odoo/odoo@05855b6b this check was still relevant since the implementation used the ORM search method. Since this commit, project_id must be an integer to be used in the SQL query.
Steps to reproduce:
- Open Project menu;
- Go to My Tasks menu;
- Create a new task;
- Open task;
- Click on Tags field.
Current Behavior:
```
File "/home/src/odoo/odoo/models.py", line 1605, in name_search
ids = self._name_search(name, args, operator, limit=limit)
File "/home/src/odoo/addons/project/models/project.py", line 2756, in
_name_search
self.env.cr.execute(query, params)
File "/home/src/odoo/odoo/sql_db.py", line 313, in execute
res = self._obj.execute(query, params)
psycopg2.errors.UndefinedFunction: operator does not exist: integer =
boolean
LINE 9: ON task.project_id = false
^
HINT: No operator matches the given name and argument types. You might
need to add explicit type casts.
```
Expected Behavior:
- No traceback and standard name_search behavior.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#115959
Forward-Port-Of: odoo/odoo#115922Forward-Port-Of: odoo/odoo#115962
Original PR description
Forward-Port-Of: odoo/odoo#115962
Before this commit: If the ePos printer is reachable but is configured incorrectly (change of Device ID, etc.) or have an issue (missing paper, etc.), a generic error message will be given: "Please check if the printer has enough paper and is ready to print." This is too generic considering the amount of issue that can happen and the fact that the printer itself does send to us a `code` which give good indication on the origin of the issue. The list of these codes can be seen at: https:/
Original PR description
Before this commit: If the ePos printer is reachable but is configured incorrectly (change of Device ID, etc.) or have an issue (missing paper, etc.), a generic error message will be given: "Please…
Before this commit: If the ePos printer is reachable but is configured incorrectly (change of Device ID, etc.) or have an issue (missing paper, etc.), a generic error message will be given: "Please check if the printer has enough paper and is ready to print." This is too generic considering the amount of issue that can happen and the fact that the printer itself does send to us a `code` which give good indication on the origin of the issue. The list of these codes can be seen at: https://files.support.epson.com/pdf/pos/bulk/server_direct_print_um_en_revk.pdf#page=52 In version 14 this code was given in the error message. But this feature was lost in the versions above & Trying to print a receipt from the PoS with a wrongly configured ePoS printer will just pop the confirmation popup: 'Do you want to print using the web printer?' Without giving any details regarding the errors causing the issue After this commit: A more precise error message is given: - Containing the printer error code - Giving recommendation on how to search online to solve the issue - On the specific case of the `Device ID` setting changed, give more details on the value to use & The error pop-up with the error details is displayed first. Then the confirmation one opw-3188576 opw-3071709 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115783 Forward-Port-Of: odoo/odoo#114199
In RTL mode, sub dropdown carret are inverted so when a item menu in a dropdown is checked, the carret and the check icon are on the same pseudo-element (e.g. `::befor`). In this commit, when the carret of a sub dropdown is on the left we set the check icon on the `::after` pseudo-element to avoid CSS rules collision. Steps to reproduce: * Select/configure a RTL language in Odoo for the current user * Open the Sales app * Filter by the Create Date and select a sub option => BUG the chec
Original PR description
In RTL mode, sub dropdown carret are inverted so when a item menu in a dropdown is checked, the carret and the check icon are on the same pseudo-element (e.g. `::befor`). In this commit, when the carret of a sub dropdown is on the left we set the check icon on the `::after` pseudo-element to avoid CSS rules collision. Steps to reproduce: * Select/configure a RTL language in Odoo for the current user * Open the Sales app * Filter by the Create Date and select a sub option => BUG the check icon and the carret are on the same pseudo-element `::before` Task ID: 3234638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115911 Forward-Port-Of: odoo/odoo#115723
Current behavior: When using FIFO/AVCO and automated valuation, the accounting entries for PoS orders where not correct if the ship later function was used and the order was not invoiced. The COGS entries were created with an amount of 0. But when the shipping was done nothing was done to correct the entries. Steps to reproduce: - Make sure you are using anglo saxon accounting - Create a product with automated valuation and FIFO/AVCO - Create a PoS order with the product - Validate the o
Original PR description
Current behavior: When using FIFO/AVCO and automated valuation, the accounting entries for PoS orders where not correct if the ship later function was used and the order was not invoiced. The COGS entries were created with an amount of 0. But when the shipping was done nothing was done to correct the entries. Steps to reproduce: - Make sure you are using anglo saxon accounting - Create a product with automated valuation and FIFO/AVCO - Create a PoS order with the product - Validate the order using the ship later option but do not invoice it - The accounting entries for the expense are created with an amount of 0 (wich makes sense because the product is not shipped yet) - Validate the picking - The accounting entries is still the same. opw-3027579 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#114435 Forward-Port-Of: odoo/odoo#112003
In planning, create a shift that starts yesterday and ends tomorrow. Select filter "Today". The shift should be visible. Except it is not. In this commit, we modify the domains to make the shifts that intersect the selected period (today, last week,...) visible. Forward-Port-Of: odoo/enterprise#38455
Original PR description
In planning, create a shift that starts yesterday and ends tomorrow. Select filter "Today". The shift should be visible. Except it is not. In this commit, we modify the domains to make the shifts that intersect the selected period (today, last week,...) visible. Forward-Port-Of: odoo/enterprise#38455
When updating the SAT status of Odoo-side cancelled invoices, l10n_mx_edi_cfdi_* fields are set to False. The system will therefore try to retrieve the supplier_rfc, customer_rfc, ... values from the CFDI attachment. Currently, the SAT always answers with 'No Encontrado' when l10n_mx_edi_40 is installed. That's because in l10n_mx_edi_40/account_edi_format `_post_invoice_edi`, the attachment is renamed to '%s-%s-MX-Invoice-4.0.xml'. To fix that, this commit introduces a new method `l10n_m
Original PR description
When updating the SAT status of Odoo-side cancelled invoices, l10n_mx_edi_cfdi_* fields are set to False. The system will therefore try to retrieve the supplier_rfc, customer_rfc, ... values from the CFDI attachment. Currently, the SAT always answers with 'No Encontrado' when l10n_mx_edi_40 is installed. That's because in l10n_mx_edi_40/account_edi_format `_post_invoice_edi`, the attachment is renamed to '%s-%s-MX-Invoice-4.0.xml'. To fix that, this commit introduces a new method `l10n_mx_edi_get_invoice_attachment` in account_edi_format. This method is overrriden in l10n_mx_edi_40 so that the correct attachment is used. opw-3205787 Forward-Port-Of: odoo/enterprise#38370 Forward-Port-Of: odoo/enterprise#38269
Just some small UI touches to make the bank reconciliation widget a bit more readable and remove unnecessary margins. A screenshot with the expected changes can be viewed in the task details. task: 3218226 Forward-Port-Of: odoo/enterprise#38023
Original PR description
Just some small UI touches to make the bank reconciliation widget a bit more readable and remove unnecessary margins. A screenshot with the expected changes can be viewed in the task details. task: 3218226 Forward-Port-Of: odoo/enterprise#38023
Before this commit, the group columns in helpesk overview overlapped each others. This commit fixes the column's width to prevent them to overlap. task id: 3129146 Forward-Port-Of: odoo/enterprise#38426 Forward-Port-Of: odoo/enterprise#38320
Original PR description
Before this commit, the group columns in helpesk overview overlapped each others. This commit fixes the column's width to prevent them to overlap. task id: 3129146 Forward-Port-Of: odoo/enterprise#38426 Forward-Port-Of: odoo/enterprise#38320
*: pos_preparation_display This PR makes the enterprise modules compatible with the modification in Odoo community. Previously in PoS, the payment button was larger than the others and next to the numpad. The other buttons were managed by a mixin and arranged in a predefined order. Now, the payment button only stays in place when the "order" button is not present, currently it can only be present if the restaurant module is installed and a printer configured. When it is present,
Original PR description
*: pos_preparation_display This PR makes the enterprise modules compatible with the modification in Odoo community. Previously in PoS, the payment button was larger than the others and next to the numpad. The other buttons were managed by a mixin and arranged in a predefined order. Now, the payment button only stays in place when the "order" button is not present, currently it can only be present if the restaurant module is installed and a printer configured. When it is present, it takes the place of the payment button and the latter is added to the mixins with the other button --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#37988
In backend it's allowed to create a new inventory line with a product tracked by serial but without specify it (to only track at delivery level). However in backend it's not possible via the button to create a new line because the form view has a required on the form if the product is tracked. It's not risky to remove it because there is a warning message at validation to ensure it's not a mistake that the serial has not been set Forward-Port-Of: odoo/enterprise#37281 Forward-Port-Of: odo
Original PR description
In backend it's allowed to create a new inventory line with a product tracked by serial but without specify it (to only track at delivery level). However in backend it's not possible via the button to create a new line because the form view has a required on the form if the product is tracked. It's not risky to remove it because there is a warning message at validation to ensure it's not a mistake that the serial has not been set Forward-Port-Of: odoo/enterprise#37281 Forward-Port-Of: odoo/enterprise#37057
Steps to reproduce: - Create a partner with belgian country and VAT. - Create a 1.000 EUR invoice with this partner using the "0% Non EU" tax. - Fully reverse the invoice. - Duplicate the original invoice and apply the domestic "21%" tax. - Open the partner VAT listing. Observed behavior: The turnover column of the partner is 0.0 and the VAT amount is 210 EUR. Desired behavior: The turnover column should be equal to 1.000 EUR. The problem was coming from 'tax_report_line_49' tags
Original PR description
Steps to reproduce: - Create a partner with belgian country and VAT. - Create a 1.000 EUR invoice with this partner using the "0% Non EU" tax. - Fully reverse the invoice. - Duplicate the original invoice and apply the domestic "21%" tax. - Open the partner VAT listing. Observed behavior: The turnover column of the partner is 0.0 and the VAT amount is 210 EUR. Desired behavior: The turnover column should be equal to 1.000 EUR. The problem was coming from 'tax_report_line_49' tags that are used for both domestic and foreign operations. There was no way to distinguish them using tags alone. Which is why we need to filter out the move lines having this "0% Non EU" tax. opw-3188086 Forward-Port-Of: odoo/enterprise#38373 Forward-Port-Of: odoo/enterprise#37931
Before this PR, it was not possible to see when a partner's credit limit was reached. Now, the limit is displayed when a partner has a balance due that is greater than his credit limit. TaskId: 3039896 Forward-Port-Of: odoo/enterprise#36775
Original PR description
Before this PR, it was not possible to see when a partner's credit limit was reached. Now, the limit is displayed when a partner has a balance due that is greater than his credit limit. TaskId: 3039896 Forward-Port-Of: odoo/enterprise#36775
1) Before this commit empty lines from planning was displaying in next week instead of current week because of domain used to get empty line was similer to get empty lines from last week. This commit fix the domain issue by giving correct domain to get empty lines from slots. 2) Before this commit empty lines from past week in grid view was not showing because of wrong parent method to add empty line from past week. This commit correct the method name to display empty lines in gri
Original PR description
1) Before this commit empty lines from planning was displaying in next week instead of current week because of domain used to get empty line was similer to get empty lines from last week. This commit fix the domain issue by giving correct domain to get empty lines from slots. 2) Before this commit empty lines from past week in grid view was not showing because of wrong parent method to add empty line from past week. This commit correct the method name to display empty lines in grid to fix above mention issue. Forward-Port-Of: odoo/enterprise#38382
## Current behaviour You are able to have to have multiple times the same person as an approver to a request. ## Expected behaviour Approvers should be unique per request, it doesn't make sense to have multiple times the same person as approver on a request. ## Steps to reproduce - Install Approvals - Create a new request, add 2 lines of the same approver - Save, no error is thrown, so we have 2 lines with the same name. ## Reason for the problem There is nothing no constraint on
Original PR description
## Current behaviour You are able to have to have multiple times the same person as an approver to a request. ## Expected behaviour Approvers should be unique per request, it doesn't make sense to have multiple times the same person as approver on a request. ## Steps to reproduce - Install Approvals - Create a new request, add 2 lines of the same approver - Save, no error is thrown, so we have 2 lines with the same name. ## Reason for the problem There is nothing no constraint on the uniqueness of the approvers per request. ## Fix Add an `@api.constrains` on the `approver_ids` of the request. ## Affected versions - 14.0 - 15.0 - saas-15.2 - 16.0 - saas-16.1 - master --- opw-3175530 Forward-Port-Of: odoo/enterprise#38411 Forward-Port-Of: odoo/enterprise#37559
In this module GSTR-1 return data set as per point of sale orders and we need to include PoS details in the GSTR-1 report. Forward-Port-Of: odoo/enterprise#35709
Original PR description
In this module GSTR-1 return data set as per point of sale orders and we need to include PoS details in the GSTR-1 report. Forward-Port-Of: odoo/enterprise#35709
When checking if the BS is balanced with a script,it seems that some accounts were missing in the BS and some sign were reverse, this pr corrects that task-id: 3041738 Forward-Port-Of: odoo/enterprise#38122
Original PR description
When checking if the BS is balanced with a script,it seems that some accounts were missing in the BS and some sign were reverse, this pr corrects that task-id: 3041738 Forward-Port-Of: odoo/enterprise#38122
When checking if the BS is balanced with a script,it seems that some accounts were missing in the BS and some sign were reverse, this pr corrects that task-id: 3041738 Forward-Port-Of: odoo/enterprise#38150
Original PR description
When checking if the BS is balanced with a script,it seems that some accounts were missing in the BS and some sign were reverse, this pr corrects that task-id: 3041738 Forward-Port-Of: odoo/enterprise#38150
This commit fixes a bug in the planning app which prevented the success/failure pop-up notification to appear when a user shared the planning through the "Publish & Send" button. task-3216317 Forward-Port-Of: odoo/enterprise#37796
Original PR description
This commit fixes a bug in the planning app which prevented the success/failure pop-up notification to appear when a user shared the planning through the "Publish & Send" button. task-3216317 Forward-Port-Of: odoo/enterprise#37796
This commit fixes a server error that is thrown in the front end when a non-user employee without any shifts in the planning tries to access it. task-3216317 Forward-Port-Of: odoo/enterprise#37797
Original PR description
This commit fixes a server error that is thrown in the front end when a non-user employee without any shifts in the planning tries to access it. task-3216317 Forward-Port-Of: odoo/enterprise#37797