Thursday, March 14, 2024
33 changes · saas-17.1
Enhancements to existing features
This update enables matching of purchase orders that have been marked as 'locked' with Optical Character Recognition (OCR). Previously, locked POs couldn't be matched, limiting automation. This change improves the efficiency of receiving and processing purchase orders, particularly when using OCR scanning.
Original PR description
This change allows for locked purchase orders to be matched with OCR Task: 3798080 Forward-Port-Of: odoo/odoo#157485 Forward-Port-Of: odoo/odoo#157386
This update allows users to send and print invoices with a customized set of options, without relying on default settings. Previously, the send & print function used default computed values, which is now changed to allow for greater flexibility in invoice processing. This simplifies the process for users needing specific print configurations.
Original PR description
…en options Add the possibility to call the send & print with *only* a set of options. All other checkboxes are therefore set to False, instead of their default computed value. Forward-Port-Of: odoo/odoo#157532
Resolved issues and error corrections
Belgian payroll dashboard warnings now calculate affected employees more reliably and exclude archived employees from counts. This prevents mismatch between warning totals and the employee lists users see, reducing confusion for payroll teams.
Original PR description
Since the code is called in a safe_eval, instead of in the codebase in https://github.com/odoo/enterprise/pull/32970 We cannot use a variable in a lambda as it raises a NameError on the employee variable called in the filtered function. So to avoid the filtered function we loop on the leave and aggregate manually by employees.
Miscellaneous changes
Description of the issue/feature this PR addresses: Current behavior before PR: ``` psycopg2.errors.SyntaxError: syntax error at or near ")" LINE 6: AND account_move_line.partner_id IN () ^ ``` 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#141548 Forward-Port-Of: odoo/odoo#141124
Original PR description
Description of the issue/feature this PR addresses:
Current behavior before PR:
```
psycopg2.errors.SyntaxError: syntax error at or near ")"
LINE 6: AND account_move_line.partner_id IN ()
^
```
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#141548
Forward-Port-Of: odoo/odoo#141124This update fixes a minor visual issue during event creation from other records (like leads). The empty button that appeared briefly before saving has been removed, creating a cleaner and more intuitive user experience. This ensures a smoother workflow for users creating events.
Original PR description
Before this commit when you create an event from a lead, a button appears to jump back to the lead but while you're creating the record, it already appears but empty. This commit hides the button in case the res_model_name is null, which happens while we are creating the event and before hitting save. Task: 3747059 Forward-Port-Of: odoo/odoo#154956
This update fixes a technical issue where sending automated emails through scheduled actions in the Lunch app would sometimes display a traceback error to users. Now, users will receive a standard error message instead, preventing disruptions to the email sending process and improving overall system stability.
Original PR description
Steps to reproduce: ----- 1. Have lunch app activated 2. Settings > Technical > Scheduled Actions 3. Run manually a scheduled action to send an automatic email to a lunch provider with "send order by" not equal to email. ** Traceback error ** Changes ------- The user will see an UserError instead of a traceback. opw-3751229 Forward-Port-Of: odoo/odoo#156706 Forward-Port-Of: odoo/odoo#156440
This update corrects a minor error in the Odoo stock management system. Specifically, a stock move was incorrectly identified as 'active' when it should have been marked as 'cancelled'. This ensures accurate inventory tracking and prevents potential issues with order fulfillment.
Original PR description
Correct state for stock move is "cancel". **opw-3783252** Forward-Port-Of: odoo/odoo#157444
This update resolves a visual glitch in the ButtonBox on forms where a single 'stat' button was incorrectly displayed instead of the standard 'More' dropdown. This ensures users always see the expected, consistent ButtonBox experience, improving usability and preventing confusion.
Original PR description
Before this commit, it could happen that the More dropdown was displayed, but it only contained a single stat button. This isn't what we want, as that single button could simply be displayed instead of the More dropdown toggler. Task 3778382 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#156241
This update ensures that the email sent count displayed in the event view accurately reflects all emails sent, including those to attendees who haven't confirmed their attendance. Previously, unconfirmed attendees weren't included in the count, leading to an inaccurate representation of email communication. This fix improves reporting and provides a more complete picture of event outreach efforts.
Original PR description
### [FIX] event: Include unregistered attendee emails in total sent count Before this commit the Email Sent Count (located in the Communication tab of the event view) wasn't including emails sent to…
### [FIX] event: Include unregistered attendee emails in total sent count
Before this commit the Email Sent Count (located in the Communication
tab of the event view) wasn't including emails sent to the attendees who
weren't confirmed.
### [This commit changes]
Event mail scheduler will include seats_uncofirmed into calculation of
the mail_count_done which is the count of emails sent. This is
reflecting the actual number of emails sent.
### [Reproduce]
- Create event E starting in time T (Events/Events)
- Add an "Unconfirmed" attendee
- Add an E-Mail in the Communication tab of the event E
- Set Interval time > T,
- Template: "Email Reminder"
- Trigger "Before the event"
- Run scheduled Action sending email (Scheduled Actions / Event: Mail Scheduler)
- BUG: email sent, but not included in the sent count in the communication tab of the event E
opw-3693626
# Merge plan (Community and Enterprise related PRs)
in 16.3 We are adding whatsapp to fix bundle. Since whatsapp is present in the enterprise repo, fix was put in there. Unfortunetally since `event_test_full` is not depending on the `whatsapp_event` I need to create additional test just for the
whatsapp module. Enterprise PR: https://github.com/odoo/enterprise/pull/58428
Forward-Port-Of: odoo/odoo#157229
Forward-Port-Of: odoo/odoo#153795This update resolves an issue where the system incorrectly calculated credit amounts in journal entries. The fix ensures accurate balance computations by retrieving necessary data from the original record, preventing discrepancies after edits and deletions. This improves the reliability of financial reporting within the accounting module.
Original PR description
Create a new Journal Entry Add a 100$ debit line 1 Add a 100$ debit line 2 Add a new line: system will suggest 200$ credit line 3 Save Delete line 3 Change line 2 amount into 50 Create a new line Issue: the system will compute a credit amount of 50$ This occurs because in the onchange we work with a new record representing the set of changes Commands sent by the orm are: - DELETE of line 3 - UPDATE of line 2 So in the new record we don't have information on line 1. A solution is to recover the data from the stored record opw-3757415 Forward-Port-Of: odoo/odoo#156875
This update fixes a visual issue where column values were misaligned in list views, particularly when using the 'planning' app. The change ensures that column data consistently aligns with its header label, improving the user experience and data readability. This resolves a minor UI inconsistency.
Original PR description
Steps to reproduce: - Install **planning** app. - Go to **planning** app, and convert the view to **List**. - Group by **Resource** -for example-. - Notice how the Allocated Time column values are…
Steps to reproduce: - Install **planning** app. - Go to **planning** app, and convert the view to **List**. - Group by **Resource** -for example-. - Notice how the Allocated Time column values are mis-aligned with the header label. Investigation: - in the planning tree view, notice the property `open_form_view` set to `True` https://github.com/odoo/enterprise/blob/418ea2114c7d935865dc52e5fd5a30d626987190/planning/views/planning_views.xml#L8 - In the `getGroupNameCellColSpan` method: - the `firstAggregateIndex` is `1` belonging to the `allocated_hours` (Allocated Time)column which set the `colspan = firstAggregateIndex = 1` - as `this.hasSelectors` is `true`, `colspan = colspan+1 = 2` (which is the correct value) - but now as the `open_form_view` was set to `True`, the `this.props.onOpenFormView` exists and so the `colspan = colspan+1 = 3` which makes the value be misaligned to the right by one column. The proposed fix: - As the `open_form_view` option add a View button to the end of the row, it makes sense to do the check with the `lastAggregateIndex` inside `getGroupPagerCellColspan` method. - In our case: - the `lastAggregateIndex` is `1` belonging also to the `allocated_hours` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 1 - 1 = 1` - as we don't display optional fields this check fails https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = 1` - Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 2` which is correct. - But what if we wanted to show the optional field `allocated_percentage` would this fix still work? Yes! - the `lastAggregateIndex` is `2` belonging to the `allocated_percentage` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 2 - 1 = 0` - as we do display an optional fields= this check works https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = colspan+1 = 2` - Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 3` which is correct. - One last case, what if we have no aggregates - both firstAggregateIndex` = `lastAggregateIndex` = -1 - we go into the else clause inside `getGroupPagerCellColspan`, making the `colspan = this.state.columns.length > 1 ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = True ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = DEFAULT_GROUP_PAGER_COLSPAN = 1` - if the `open_form_view` was `True`, the colspan becomes `colspan = colspan+1 = 2`. opw-3764616 Forward-Port-Of: odoo/odoo#156647
This update fixes an issue where website images weren't correctly applied when the footer's 'Slide Hover' option was enabled. The change ensures that background images are consistently used across the website layout, improving visual consistency and the overall user experience. This resolves a visual glitch that was impacting how elements interacted with the footer.
Original PR description
Steps to reproduce: - Click on the footer and enable footer "Slide Hover" option - In the theme tab, add a theme bg image - Drag & drop a "Text - Image" snippet (or any snippet without a bg color set, or any snippet with a bg color set and just remove it) - The snippets and page layout in genral will receive a forced color instead of using the bg image set. This is because with the slide hover option, the bg has to be moved from the `#wrapwrap` to the `main`. Indeed, it's the main which is scrolling hover the footer, not the `#wrapwrap`. Without doing that, the elements hover the footer would have a transparent background and would not hide the footer. But the bg image was not considered when doing it, only the bg color. opw-3704746 Forward-Port-Of: odoo/odoo#157077
This update resolves an issue where the overlay disappeared after cropping an image within the website editor. The fix prevents the overlay from being hidden during the cropping process, eliminating the need for extra clicks to re-display it. This improves the user experience for image editing.
Original PR description
Steps to reproduce: 1. Go to the website 2. Drag a snippet that contains an image 3. Select the image block 4. Go to customize the image 5. Go to transform - select crop image 6. Crop and apply changes -> Overlay is hidden Before this commit, after cropping an image the overlay was hidden. To make the overlay visible again, you have to click elsewhere on the snippet and then click on the image again, because the overlay was being hidden. When we perform an image crop, we activate the `hide_overlay` action, which subsequently eliminates the `o_we_overlay_preview` class. This is due to the fact that, during the image-cropping process, the `previewMode` is set to `false.` However, if we wish to keep the overlay visible, We can simply avoid triggering the "hide_overlay" action. task-3392225 Forward-Port-Of: odoo/odoo#127526
This update fixes an issue where the 'Mail Group: Send Guidelines' email template incorrectly displayed the object's ID instead of the actual mail group name. The change updates the email template to use the correct mail group name, ensuring accurate messaging for users receiving these emails. This improves the clarity and professionalism of our email communications.
Original PR description
Steps to reproduce:
------------------
- Have Website and Mail Group installed
- Send Guidelines for a mailing list through the Website app
Issue
-----
{{ object.mail_group_id.name }} appears in the body of the "Mail Group: Send Guidelines" mail template instead of the actual mail group name.
opw-3778512
Forward-Port-Of: odoo/odoo#157591
Forward-Port-Of: odoo/odoo#156569This update fixes an issue where collaborative changes to embedded views in Knowledge were sometimes causing unexpected data loss. The fix prevents unnecessary, recursive sanitization of view content, ensuring a smoother and more reliable collaborative experience. This improves the stability of shared views.
Original PR description
In Knowledge, embedded views anchors have a `data-behavior-props` attribute containing information on how to render the embedded view. That attribute is sometimes updated, and during a collaborative session, receiving such an update as a collaborative step would trigger a full sanitization of the embedded view, possibly discarding some transient content that could break the view, even though it caused no security issue since it is all rendered on a per client basis (each client fully renders its own view). The proposed solution is to sanitize only the attribute of the node and not its content during `_safeSetAttribute`, which is reasonable, because the node content is already sanitized recursively for `add` mutations. task-3060490 Forward-Port-Of: odoo/odoo#157669 Forward-Port-Of: odoo/odoo#157202
This update corrects and completes translations for the Italian language (l10n_it) within the Tax Report feature. Specifically, it addresses missing or inaccurate translations for the VJ grid, ensuring accurate reporting for Italian businesses. This improves the usability and compliance of the Tax Report for Italian users.
Original PR description
Some translations were missing or incorrect for the VJ grid in the Tax Report. Task link: https://www.odoo.com/web#model=project.task&id=3724926 task-3724926 Forward-Port-Of: odoo/odoo#157622
This update addresses an issue where the Microsoft Account integration would fail if a user accessed the callback URL without providing necessary data. By ensuring the `kw` dictionary exists before accessing the 'state' value, the system now gracefully handles this scenario and prevents errors, improving the user experience.
Original PR description
When a user tries to access the URL directly, at that time the value of dictionary `kw` is not available. So the error will be generated. Traceback in sentry: ``` KeyError: 'state' File…
When a user tries to access the URL directly, at that time the value of dictionary `kw` is not available. So the error will be generated.
Traceback in sentry:
```
KeyError: 'state'
File "odoo/http.py", line 2123, in __call__
response = request._serve_db()
File "odoo/http.py", line 1699, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1726, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1840, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 190, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 716, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/microsoft_account/controllers/main.py", line 15, in oauth2callback
state = json.loads(kw['state'])
```
see-
https://github.com/odoo/odoo/blob/9460c82c4724f347a665cae27db60c4c9a6a950b/addons/microsoft_account/controllers/main.py#L15
This commit will solve the above issue by raising the `BadRequest` if the value of dictionary `kw` does not available.
sentry-4377121133
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#131340This update resolves a problem that occurred when upgrading the stock_account module, specifically when using the Austrian localization. The upgrade process incorrectly attempted to recreate stock account properties, leading to a database error. The fix ensures the module checks for existing properties before attempting to create new ones, preventing the error and allowing smooth upgrades.
Original PR description
Steps to reproduce: - Create an empty database (without demo data) - Install stock_account - Go to Invoicing settings - Select Austria as Fiscal Localization - Go to Apps - Try to upgrade…
Steps to reproduce: - Create an empty database (without demo data) - Install stock_account - Go to Invoicing settings - Select Austria as Fiscal Localization - Go to Apps - Try to upgrade stock_account module Issue: A traceback is raised. The module tries to create the default stock accounts properties on the main company, but they already exist, which triggers a violation of the SQL unique constraint (ir_property_unique_index) of "ir.property" on the combination of (fields_id, company_id, res_id) fields. Cause: When "stock_account" module is installed/upgraded, the default stock accounts properties are created for the main company with forcecreate="True" option, which means they will be created if their "xml_id" doesn't exist, even if they are declared inside `<data noupdate="1">`. In this case, they are created with their "xml_id" at the module installation with the following values: - company_id: [the main company] - fields_id: ["property_stock_account_output_categ_id" field of "product.category" model] - res_id: False (to be used as a default value) - value: False When the Austrian localization (or other localizations defining their own stock accounts properties) is selected in the settings, these default properties are deleted and replaced by those coming from the localization package with some similar values but without "xml_id": - company_id: [the main company] - fields_id: ["property_stock_account_output_categ_id" field of "product.category" model] - res_id: False (to be used as a default value) - value: [depends on the localization package] Then, when upgrading "stock_account" module, as the "xml_id" of the default stock accounts properties cannot be found anymore, the upgrade process will try to re-create them and will trigger the SQL unique constraint. Solution: Move the creation of the default stock accounts properties in a python function to check if the default properties already exist based on the combination of "company_id", "fields_id" and "res_id" fields and not based on the "xml_id". opw-3682320 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156728
This commit changes the danish csv report's header to match with the correct Danish documentation requirements. The Danis government's documentation for the annual report accounting file seems to have disprepancies between the PDF and the website. We got a feedback that the generated CSV did not follow the requirements given for regnskab basis at the following link: https://erhvervsstyrelsen.dk/vejledning-upload-af-regnskabsfil-i-regnskab-basis Based on the documentation chapter 3 &
Original PR description
This commit changes the danish csv report's header to match with the correct Danish documentation requirements. The Danis government's documentation for the annual report accounting file seems to have disprepancies between the PDF and the website. We got a feedback that the generated CSV did not follow the requirements given for regnskab basis at the following link: https://erhvervsstyrelsen.dk/vejledning-upload-af-regnskabsfil-i-regnskab-basis Based on the documentation chapter 3 & 4, the top row of the csv file (header) should consists of: KONTONUMMER_20230131, KONTONAVN_20230131, and VAERDI_20230131 task-id: None Forward-Port-Of: odoo/enterprise#58477
In this fix we made the account reports in dark mode look similar to their light mode counterparts task: 3770541 Forward-Port-Of: odoo/enterprise#57773
Original PR description
In this fix we made the account reports in dark mode look similar to their light mode counterparts task: 3770541 Forward-Port-Of: odoo/enterprise#57773
The aim of this commit is handling properly the UK case when we unfold lines in the intrastat report. For some reasons, instead of using GB , we have to use XU for the product origin country code. The problem was that we used this country code to find children lines when the user unfold the Dispatch/Arrival line. As the country code XU doesn't exist, for all these lines, we don't get any children lines. Now, before we build the ID (that we'll use after to fetch children lines), we change the v
Original PR description
The aim of this commit is handling properly the UK case when we unfold lines in the intrastat report. For some reasons, instead of using GB , we have to use XU for the product origin country code. The problem was that we used this country code to find children lines when the user unfold the Dispatch/Arrival line. As the country code XU doesn't exist, for all these lines, we don't get any children lines. Now, before we build the ID (that we'll use after to fetch children lines), we change the value for the right country code. no task id Forward-Port-Of: odoo/enterprise#58620 Forward-Port-Of: odoo/enterprise#58585
To reproduce the issue: - Switch to the `Activity` view. - Click `+ Schedule Activity`. - The dialog box opens up with a list of documents. - Scroll down to spot the `DocumentsInspector` present at the bottom. Reason: - The dialog box renders the list view of the related model, depending on the module it is invoked in. - There is no condition present to evaluate when to display the `DocumentsInspector` and when not to. Fix: - Since the inspector is invoked inside the `Dialog` compon
Original PR description
To reproduce the issue: - Switch to the `Activity` view. - Click `+ Schedule Activity`. - The dialog box opens up with a list of documents. - Scroll down to spot the `DocumentsInspector` present at the bottom. Reason: - The dialog box renders the list view of the related model, depending on the module it is invoked in. - There is no condition present to evaluate when to display the `DocumentsInspector` and when not to. Fix: - Since the inspector is invoked inside the `Dialog` component, we check that condition. After this commit: - We no longer see the inspector inside the Dialog box. Task-3714496 Forward-Port-Of: odoo/enterprise#58484 Forward-Port-Of: odoo/enterprise#56056
Create a tax group without country and property_tax_payable_account_id = False. Create a tax with this group. Create a new tax report, you are redirect to configure tax group. --> Issue this tax group is not show. X-original-commit: 860512b1eee26d0c65bf741173d870df6e76313a Forward-Port-Of: odoo/enterprise#58328
Original PR description
Create a tax group without country and property_tax_payable_account_id = False. Create a tax with this group. Create a new tax report, you are redirect to configure tax group. --> Issue this tax group is not show. X-original-commit: 860512b1eee26d0c65bf741173d870df6e76313a Forward-Port-Of: odoo/enterprise#58328
When using a token payment method the transaction will already be completed during the transaction creation. The subscription should not be marked with pending transaction as the transaction is already completed Forward-Port-Of: odoo/enterprise#57756
Original PR description
When using a token payment method the transaction will already be completed during the transaction creation. The subscription should not be marked with pending transaction as the transaction is already completed Forward-Port-Of: odoo/enterprise#57756
Because end users may not have config access rights. ticket 3647004 Forward-Port-Of: odoo/enterprise#53490
Original PR description
Because end users may not have config access rights. ticket 3647004 Forward-Port-Of: odoo/enterprise#53490
…en options Add the possibility to call the send & print with *only* a set of options. All other checkboxes are therefore set to False, instead of their default computed value. Forward-Port-Of: odoo/enterprise#58574
Original PR description
…en options Add the possibility to call the send & print with *only* a set of options. All other checkboxes are therefore set to False, instead of their default computed value. Forward-Port-Of: odoo/enterprise#58574
This PR fixes 2 issues with multi-line fields: 1. when inserting long lines in multi-line text field and generating the final pdf, the multi-line did not respect its boundaries at all. This happened because font size wasn't applied properly on the frontend, so there was a difference between fontsize inside the textarea and the fontsize when writing lines on the document which caused the lines to overflow horizontally. 2. Text alignment is not applied when generating the final pdf. Chang
Original PR description
This PR fixes 2 issues with multi-line fields: 1. when inserting long lines in multi-line text field and generating the final pdf, the multi-line did not respect its boundaries at all. This happened because font size wasn't applied properly on the frontend, so there was a difference between fontsize inside the textarea and the fontsize when writing lines on the document which caused the lines to overflow horizontally. 2. Text alignment is not applied when generating the final pdf. Changes: 1. remove the fixed textarea font-size property and allow it to be set dynamically based on the zoom factor 2. apply text alignment on the multiline field Task: 3696347 Forward-Port-Of: odoo/enterprise#58035
-Before this commit: When a user lost access to an article which was a favorite, the sidebar was provided with the id of the article anyway, resulting in an error when trying to access its fields, preventing the sidebar from being displayed at all. -After this commit: Articles ids are not provided to the sidebar when they have a favorite related to the current user but that user currently can not access it. opw-3700698 Forward-Port-Of: odoo/enterprise#55590
Original PR description
-Before this commit: When a user lost access to an article which was a favorite, the sidebar was provided with the id of the article anyway, resulting in an error when trying to access its fields, preventing the sidebar from being displayed at all. -After this commit: Articles ids are not provided to the sidebar when they have a favorite related to the current user but that user currently can not access it. opw-3700698 Forward-Port-Of: odoo/enterprise#55590
This commit is the counterpart of odoo/odoo#156241 where we rework the logic of computing the visible buttons and those put in a dropdown, in the button box. There's an override in studio to bypass the invisible filter when we have toggled the "Show Invisible" option, so this override needed to be adapted. The fun part is that this was actually not working, because the viewEditorModel wasn't made reactive, so toggling the option didn't produce a re-rendering. Now it does. Task 3778382 Forwar
Original PR description
This commit is the counterpart of odoo/odoo#156241 where we rework the logic of computing the visible buttons and those put in a dropdown, in the button box. There's an override in studio to bypass the invisible filter when we have toggled the "Show Invisible" option, so this override needed to be adapted. The fun part is that this was actually not working, because the viewEditorModel wasn't made reactive, so toggling the option didn't produce a re-rendering. Now it does. Task 3778382 Forward-Port-Of: odoo/enterprise#58565
When a user attempts to restore an article with a parent in the trash, a validation error occurs. This is due to the article item getting detached from its parent, violating an SQL constraint that mandates every article item to have a parent. The existing error message lacks clarity regarding the issue and its resolution. This commit aims to enhance the error message for this specific scenario. Steps to reproduce the error: 1. Open Knowledge 2. Create an article 3. Insert an embedded view
Original PR description
When a user attempts to restore an article with a parent in the trash, a validation error occurs. This is due to the article item getting detached from its parent, violating an SQL constraint that…
When a user attempts to restore an article with a parent in the trash, a validation error occurs. This is due to the article item getting detached from its parent, violating an SQL constraint that mandates every article item to have a parent. The existing error message lacks clarity regarding the issue and its resolution. This commit aims to enhance the error message for this specific scenario. Steps to reproduce the error: 1. Open Knowledge 2. Create an article 3. Insert an embedded view of article items with /kanban or /list 4. Create an article item (-> The "New" button from the embedded view) 5. Delete the parent article using the "more options" panel 6. Click on the "Open the Trash" button 7. From the list view, click on the article item you created at step 4 8. Click on the "Restore" button from the banner => The user receives a validation error indicating that the article item should have a parent. This error occurs because the parent article is in the trash, and the article item cannot be detached from its parent. TO BE: The user should receive an error message indicating that the article item cannot be restored and that the user needs to restore the parent article first in order to restore the article item. Forward-Port-Of: odoo/enterprise#55442
The aim of this commit is handling correctly the VAT number in the Partner VAT Listing. Before, to remove the BE in the vat, we removed the 2 first characters of the vat, it causes an issue when the VAT number doesn't start with BE. This fix is using the `_vat_to_bce` function (from the same module) which convert (if necessary) the VAT into the BCE number. no task id Forward-Port-Of: odoo/enterprise#58597 Forward-Port-Of: odoo/enterprise#58563
Original PR description
The aim of this commit is handling correctly the VAT number in the Partner VAT Listing. Before, to remove the BE in the vat, we removed the 2 first characters of the vat, it causes an issue when the VAT number doesn't start with BE. This fix is using the `_vat_to_bce` function (from the same module) which convert (if necessary) the VAT into the BCE number. no task id Forward-Port-Of: odoo/enterprise#58597 Forward-Port-Of: odoo/enterprise#58563
This PR fixes the name of a method in the list of async functions of the `timerHelpdeskService` service. Forward-Port-Of: odoo/enterprise#58583
Original PR description
This PR fixes the name of a method in the list of async functions of the `timerHelpdeskService` service. Forward-Port-Of: odoo/enterprise#58583
The goal is to be able to see cash basis values grouped by analytic. We use the amounts of the analytic lines, with a proportion corresponding to the cash basis amount divided by the real amount. task-3047794 Forward-Port-Of: odoo/enterprise#58408 Forward-Port-Of: odoo/enterprise#33384
Original PR description
The goal is to be able to see cash basis values grouped by analytic. We use the amounts of the analytic lines, with a proportion corresponding to the cash basis amount divided by the real amount. task-3047794 Forward-Port-Of: odoo/enterprise#58408 Forward-Port-Of: odoo/enterprise#33384