Daily updates from Odoo
Tuesday, December 10, 2024
62 changes · 18.0
Security fixes and vulnerability patches
This update limits visibility of UAE payroll annual leave fields so they are only available to the appropriate user group. It helps prevent sensitive employee leave information from being exposed more broadly than intended.
Original PR description
Giving l10n_ae_annual_leave_days_taken and l10n_ae_annual_leave_days_total a group value, as it is not supposed to be public. [link to build errors](https://runbot.odoo.com/web#id=97976&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form)
New functionality added to Odoo
Discuss now offers a dedicated video call button that starts a call with the camera enabled, reducing extra steps for users who want face-to-face conversations. Incoming call invitations also clearly indicate when a video call is being requested and let participants join with their camera on.
Original PR description
Add a new button to make a video call, which is equivalent to making a call and enabling camera. Invitation screen shows this is an incoming video call, people can join with camera on with the video camera button. Task-4354198  <img width="191" alt="Screenshot 2024-12-05 at 17 28 18" src="https://github.com/user-attachments/assets/54c91f47-9862-423d-a123-2eb67a58c84a"> <img width="717" alt="Screenshot 2024-12-05 at 17 28 42" src="https://github.com/user-attachments/assets/5d78b9ed-7b49-430d-8b6b-5cd0859ff4bd">
Spanish accounting users can now export the Libro Diario, a chronological journal of accounting entries, directly to Excel. This makes it easier for companies to review, share, and provide the legally expected transaction record in the required structure.
Original PR description
Objective --------- Libro Diario is just a big name for "Journal" in Spanish, but it's also a precise report that is expected to reflect a chronological report of all Accounting Entries in a…
Objective --------- Libro Diario is just a big name for "Journal" in Spanish, but it's also a precise report that is expected to reflect a chronological report of all Accounting Entries in a Database. It's expected to be published and available to show all the transactions recorded by a Company. It's basically an export of the General Ledger with all the accounting entries, not grouped by Account but by Accounting Entries, sorted by date, and to show a full sequence. The Libro Diario should posess the following columns and each row should contain an account move line: - "Entry": ascending numbering for each move, starting at 1. - "Line": numbering of the move line inside the move, starting at 1. - "Date": accounting date of the move; as mentionned, moves should be sorted by dates - "Account code" - "Account name" - "Description": label of the move line - "Document": account move name - "Debit" - "Credit" Solution --------- 1. Add a custom General Ledge Handler that adds the option to export the Libro Diarios 2. Since `_get_line` returns the AMLs grouped by accounts, it is easier to fetch the query that gets all the AMLs data (`_get_query_amls`) and then postprocess the amls data to generate the matrix of data passed to the XLSX builder. Doing so forces us to manually initialize the currency table. task-4294391
Enhancements to existing features
Project portal link sections can now be configured to open specific links in a new browser tab instead of always replacing the current page. This gives businesses more flexibility when linking to related resources such as documents while keeping users' project context available.
Original PR description
- 18.0
Before this commit, the portal link opens in the current tab. After this commit, we can open the link in a new tab also, by only passing one key 'target' in task_link_section list.
e.g.values['task_link_section'].append({
'access_url': url,
'title': _('Documents'),
'target': '_blank'
})
task-4194318
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSales commission reporting now handles quarterly payment grouping more accurately and makes forecasts easier to review for future periods. Sales managers can better track expected commission performance by salesperson, even when no achievements have been recorded yet.
Original PR description
taskid: 4376927
Document access checks have been optimized to avoid overly complex database queries. This should make permission-related actions in Documents significantly faster, improving responsiveness for users working with document access rights.
Original PR description
## Description Most read `ir.rule` on documents are based around the searchable field `user_permission`. Both `documents.document` and `documents.access` rely on it, and its' implementation creates a…
## Description Most read `ir.rule` on documents are based around the searchable field `user_permission`. Both `documents.document` and `documents.access` rely on it, and its' implementation creates a recursive application of the ir.rule, as `documents.document` calls `_search_user_permission`, which reads on `documents.access`, whos `ir.rule` rely on `document_id.user_permission`, re-applying the same domain from `_search_user_permission`. This recursive-like behaviour creates excessively large queries with a lot of subquery, exploding the costs of it above the `jit_above_cost` threshold (500k by default), leading to slow execution, due to the JIT optimizer, which normally should be reserved for long analytical queries. ## Patch Adding `auto_join=True` on `documents.access.document_id` will transform some of the subqueries in joins, and is done in `sudo` context, avoiding re-application of the `ir.rule` while resolving itself. The simplification of the query leads to lower query cost that is bellow the `jit_above_cost` threshold, removing the slow optimisation step, leading to faster execution, as it was the main bottleneck. ## Benchmark On a db with a moderately sized `documents_document` table: | Timings | Before | After | Speed up | |-------------------------------|--------|-------|----------| | `action_update_access_rights` | 7s | 550ms | 12.7x | ## Reference task-4381572
Resolved issues and error corrections
Timesheets now avoid selecting projects that cannot be used for timesheet entries as the default, reducing confusion and incorrect entry setup. The change also adds supporting model data to make future timesheet testing easier and more reliable.
Original PR description
This commit's purpose is to add some data model in order to ease the writing of hoot tests. These data are introduced due to a necessity in the enterprise part of the pr. https://github.com/odoo/enterprise/pull/74264 task 4268687
Customers and staff can now download invoices for point-of-sale orders paid online. The fix ensures the invoice can be accessed even when only its reference is available, reducing failed invoice downloads after online payment.
Original PR description
Before this commit, it wasn't possible to download the invoice of an order paid with online payment. This was because the account move of the order was not loaded, even though it could have its ID, which is sufficient. opw-4357927 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Quotations created from repair orders now keep the correct product quantities when opened in Point of Sale. This prevents items added during a repair from appearing with a zero quantity, helping staff process the quotation accurately.
Original PR description
When opening a quotation created from a repair order in the PoS the quantity of the products would always be 0. Steps to reproduce: ------------------- * Create a repair order for whatever product * Add some product to the list with the "Add" option * Start and End the reparation * Create a quotation for the repair order * Open the quotation in the PoS > Observation: The quantity of the product in the pos is 0 Why the fix: ------------ If the sale order line has no `valued_move_ids` it means that it's linked to a repair. In this case we take the product_uom_qty into account for the pos order line quantity. opw-4261097
This update fixes an automated purchase product matrix walkthrough by removing outdated jQuery usage. It helps keep internal testing reliable so future purchase product matrix changes can be validated with fewer false failures.
Original PR description
In this commit we fix tour by removing the usage of jQuery. 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 fix ensures users can still find and select records in dropdown fields even when a model has no configured display name search. It avoids unintentionally narrowing results while keeping the existing warning for administrators or developers.
Original PR description
We already display a warning message, but we need to explicitely not restrict the search. The `name_search` method is called when trying to populate many2one fields and we want to be able to select items even when name searching is not defined. task-3484032 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The replenishment list no longer applies the "to replenish" filter automatically, avoiding repeated calculations that could slow down the page. Users can still apply or save this filter manually when they need to focus on products that require ordering.
Original PR description
The filter to replenish use the `qty_to_order` field. However when adding a filter multiple function are called. `web_search_read`, `search_panel_select_range, `search_panel_select_multi_range`…
The filter to replenish use the `qty_to_order` field. However when adding a filter multiple function are called. `web_search_read`, `search_panel_select_range, `search_panel_select_multi_range`
However they all use the search domain and in the default search there is the `to replenish` filter with [('qty_to_order', '>', 0)] And each time they trigger while it's not needed to recompute them.
We think about storing the qty_to_order_computed but it's not optimal to store a value that needs to be updated everyday, just to cache it.
Instead we will remove the default filter. It's a good trade off since it's only needed when people create their orderpoints automatic themself. In general, it's not needed since the automatic rr are deleted and created on missing quantity. For people that create the automatic rr they can still use the filter and move it default but it could continue the performance issue
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-prClosing the tour recorder now clears its active state, so it no longer appears to keep recording when users return later. This prevents confusion and makes the tour recording tool behave more predictably.
Original PR description
When closing the tour recorder, the state should be clear. Because if not, when leaving and coming back later, the tour recorder would be still recording. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers could hit an error when opening invoices linked from project tasks in the portal, especially when a sales order had multiple invoices. This fix correctly handles the updated invoice data format so portal users can access their invoices without a crash.
Original PR description
Currently a traceback occurs when the user opens an invoices from the tasks in the portal. To reproduce this issue: 1) Install sale, timesheet 2) Open a sale order having a project or create a…
Currently a traceback occurs when the user opens an invoices from the tasks in the portal. To reproduce this issue: 1) Install sale, timesheet 2) Open a sale order having a project or create a confirmed SO with product type as service 3) Create multiple invoices for that SO 4) Now open the related tasks of that SO having invoices from the portal 5) Click on `invoices` from side panel Error:- ``` AttributeError: 'list' object has no attribute 'ids' ``` This error is occurring from the below line https://github.com/odoo/odoo/blob/88c0f9d953d077510961243080dcab2cc1920c27/addons/sale_timesheet/controllers/portal.py#L43-L50 Clearly, we get invoices as a list of dict in values from the below line. https://github.com/odoo/odoo/blob/88c0f9d953d077510961243080dcab2cc1920c27/addons/account/controllers/portal.py#L126-L133 Initially, we get the recordsets of invoices in `values['invoices']`. But because of the recent changes from the below commit, we get a list of recordset values, from which we can access the value of invoice ID. https://github.com/odoo/odoo/pull/174812/files#diff-3b907221102acd53c211a3a6b50b00543dcbbc865d50ef4451bea465f7300cbaR107-R112 We can resolve this issue by looping in invoices and access the invoice id. similarly like this https://github.com/odoo/odoo/blob/48629b94dac45dad0766fbaeef0f71934a5adcc4/addons/account/controllers/portal.py#L90 sentry-6117277208
This fixes applicant creation from job platform emails so recruiters no longer see generic email subjects used as candidate names. Applications from sources like Indeed will keep the actual sender name, making candidate lists easier to read and manage.
Original PR description
Emails sent by some job platforms (e.g. Indeed) result in applicants with a display name like: [Action required] New application for Developer, San Francisco, CA This makes it hard for recruiters to…
Emails sent by some job platforms (e.g. Indeed) result in applicants with a display name like: [Action required] New application for Developer, San Francisco, CA This makes it hard for recruiters to efficiently use the recruitment app. These emails don't use `hr.job.platform`, because the platform (e.g. Indeed) sends out the email under an application-specific `From: `, e.g. `"Joren Van Onder" <jov2ueneo87n_g88@indeedemail.com>` So the `hr.job.platform` mechanism isn't needed. Before this commit, when an application like this was received, the name on the hr.applicant (computed field based on candidate_id) would become the email subject name. This is the default behavior of `mail.thread`: it fills `_rec_name` with the subject if not set [1]. To fix it, always force partner_name in `hr.applicant`s `message_new()` (this already was being done if an `hr.job.platform` matched). [1] https://github.com/odoo/odoo/blob/f4990442904a23a387f21822b91d096f5eb987fc/addons/mail/models/mail_thread.py#L1412-L1422 opw-4383191
This update prevents Korean localization accounting report codes from overlapping with codes used elsewhere in Odoo. It helps avoid test failures and reduces the risk of reporting setup conflicts for Korean accounting features.
Original PR description
Some code used in accounting report lines are also used in other reports outside of the KR localization. As of now, unlike what the constrains hint, codes are not expected to be unique per report but instead unique entirely which was not the case. The Unallocated Earnings lines had the same code as the standard ones which ended up causing some tests to fail. To fix this, we are adding a prefix to all codes. The constrains was also temporarily changed to ensure that the new codes are at least unique in the KR module and do not clash with account_reports. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes an automated stock picking batch test more precise by clearly identifying when actions happen inside pop-up windows. It helps prevent false test failures and improves confidence in future updates to batch transfer workflows.
Original PR description
In the test_stock_picking_batch_sm_to_sml_synchronization tour, it is imperative to be exhaustive about whether we are in a modal or not. The trigger targets an element that is not in a modal when it should be. In this commit, we stipulate each modal for each trigger. This not only makes the tour more understandable but also avoids any ambiguity. runbot-error-id~109487 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
Worldline payment references are now kept intact when transaction IDs are processed. This prevents payout reconciliation errors and avoids possible reference collisions caused by accidentally shortened payment IDs.
Original PR description
Fixup of #185951 When removing the trailing _0 in transaction IDs from the API response, any trailing 0 in the PAYID gets truncated as well, due to the use of `rstrip()`. A series of consecutive transactions are then saved with the following provider_reference values: 8390248265 8390248266 8390248267 8390248268 8390248269 839024827 8390248271 which leads to mismatching reconciliations of payouts for the truncated ones, and may cause collisions of PAYIDs with older transactions.
The Update DGI Status button is now hidden when a Uruguayan electronic invoice has already been accepted or rejected by DGI. This prevents users from trying to refresh a status that can no longer change, reducing confusion on completed documents.
Original PR description
This PR hides the “Update DGI Status” button on the account.move form view when the CFE Status is either “CFE Accepted by DGI” or “CFE Rejected by DGI”. This change is necessary because both “Accepted” and “Rejected” are final states that cannot transition to another status. Once a CFE reaches either of these states, there is no status update possible, making the button irrelevant in these scenarios. Task Adhoc side: 43467 Task Latam side: 1295
Fixes issues that could cause the timesheet timer header to appear empty or fail when starting, stopping, or discarding timers in list views. This improves reliability for users tracking time, including when entries are grouped or no timesheetable projects exist.
Original PR description
Currently, the timesheet header is not working correctly in the list view. There are a bunch of issue that this commit aims to fix: An empty header is displayed when the start button is pressed, and…
Currently, the timesheet header is not working correctly in the list view. There are a bunch of issue that this commit aims to fix: An empty header is displayed when the start button is pressed, and trying to either stop it or discard it will triggers an error The grouped by function triggers a similar issue as the one above when trying to start & stop the timer When there are no timesheetable project inside the database, an error is triggered too when starting the timer. Source of the issues : - when trying to start a timer in the list view, the function 'cleartimesheetname' is triggered. The problem is that function triggers an update on the listview. This update then triggers a second execution of the 'onWillUpdateProps' of the timesheet_timer_hook class. This second execution is not expected in the flow and set the value of the timesheet of the header to 'false'. - when the view is grouped, the record are not loaded inside the the folded section. This means that when we search for the record inside the 'popRecord' function of the timesheet_timer_hook class, we find nothing. In this use case though, the record is supposed to be found and set. - when there are no timesheetable project, the method 'popRecord' will set the timesheet of the header back to 'undefined'. Solution : - Removed the 'cleartimesheetname' method, as it is no longer usefull. A check up in the write/create of the model will prevent the required field 'description' from being null. The 'enterEditMode' has also been restricted to the kanban view, since doing this in the list view was also triggering an extra call to 'onWillupdateprops' - Checked the view to get a dynamicRecordList we can use to correctly set the data. More information inside the comment in the code. - added a condition inside the 'popRecord' method so that in no longer set the timesheet to undefined when we dont need it to task - 4268687 affected version 18.0-master
This change corrects a recent condition that caused errors when exporting Spain's Mod 347 report. It ensures the report can still generate the required export file when period comparison is needed, reducing disruption for accounting users.
Original PR description
The condition previously added leads to an error when exporting mod 347 in l10n_es as generating the export file for this report always requires period comparison. Previous pr: https://github.com/odoo/enterprise/commit/045fd08c11d5f1407e971da52ea29654ac28aa93#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecR659
This update fixes several issues affecting accounting reports, payroll editing, POS tax matching, appraisals, preparation displays, and Studio visibility rules. It also improves WhatsApp voice message handling so received audio can be played directly in discussions, reducing errors and improving day-to-day usability.
Original PR description
Avoid calling registry with a fix mode name to allow model ihnritance for new model
Example:
```
Class SaleOrderMutation(models.Model):
_name="sale.order.mutation"
_inherit = ["sale.order.line"]
```Italian point of sale receipts now handle rounding adjustments correctly when sending data to fiscal printers. This prevents printer crashes when totals are rounded up or down, helping checkout operations continue smoothly.
Original PR description
When managing rounding adjustments at the point of sale (either excess or defect), Odoo modifies the amount to be paid accordingly. This requires sending an XML tag `printRecSubtotalAdjustment` to the fiscal printer, which is populated differently based on whether the adjustment increases or decreases the total. Without this tag the printer goes wrong and crashes. The issue is resolved by ensuring the adjustment value is properly quoted in the XML. Proper XML formatting prevents the crash. Example: ``` Product price: 1.23 Rounding: 0.02 Total: 1.25 ``` or ``` Product price: 1.23 Rounding: -0.03 Total: 1.20 ``` --- CLA signed here: https://github.com/odoo/odoo/pull/186833
This update prevents quantity adjustment buttons from appearing on full package lines in the Barcode app, avoiding errors when users move entire packages. It also ensures barcode-specific forms are only used in the right context, reducing unexpected errors in inventory workflows.
Original PR description
**[FIX] stock_barcode: move entire package button** > Before this commit, the buttons to add quantity on a barcode line were also displayed for package lines. It shouldn't be the case and it doesn't work (traceback when clicked.) This commit fixes that. **[FIX] stock_barcode_*: views priority** > *: stock_barcode_mrp, stock_barcode_picking_batch > > This commit adds missing priority on primary `stock.move.line` form inherited views: > - `stock_barcode_mrp.stock_move_line_product_selector` > - `stock_barcode_picking_batch.stock_move_line_product_selector_inherit` > > Without this field, those views will have the default priority and will sometime be displayed instead of the default move line form view (`stock.view_move_line_form`) which causes a traceback because those views were explicitly created for the Barcode app and use specific widget which is no usable in other contexts. task-4329041
This fix prevents Spanish invoice records from being incorrectly marked as manually modified when their invoice type is adjusted during creation. It helps keep invoice status information accurate and avoids unnecessary follow-up or confusion for accounting teams.
Original PR description
this fix adds skip_is_manually_modified context to the moves in spanish localization create method, so that is_manually_modified field is not unnecessarily changed to true when changing the invoice type. [link to runbot build errors](https://runbot.odoo.com/web#id=99362&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form)
Korean accounting report line codes were updated to avoid overlaps with other reports. This prevents related report tests from failing and helps ensure the Korean localization remains reliable.
Original PR description
Some code used in accounting report lines are also used in other reports outside of the KR localization. As of now, unlike what the constrains hint, codes are not expected to be unique per report but instead unique entirely which was not the case. The Unallocated Earnings lines had the same code as the standard ones which ended up causing some tests to fail. To fix this, we are adding a prefix to all codes. The constrains was also temporarily changed to ensure that the new codes are at least unique in the KR module and do not clash with account_reports.
This fixes an error that could stop customers from opening invoices linked to helpdesk tickets in the portal. Users can now access those invoices normally, improving the support portal experience and reducing support interruptions.
Original PR description
A traceback occurs when the user opens an invoice from the tickets in the portal. Error:- ``` AttributeError: 'list' object has no attribute 'ids' ``` This error is occurring from the below line https://github.com/odoo/enterprise/blob/a2cfc7c223dfe915a1965d08c2e1f91cfeabe2f6/helpdesk_account/controllers/portal.py#L40-L47 Initially, we get the recordsets of invoices in `values['invoices']`. But because of the recent changes from the below commit, we get the list of recordset values, from which we can access the value of invoice ID. https://github.com/odoo/odoo/pull/174812/files#diff-3b907221102acd53c211a3a6b50b00543dcbbc865d50ef4451bea465f7300cbaR107-R112 Community PR:- https://github.com/odoo/odoo/pull/190062 sentry-6117277208
**Issue:** Some terms don't appear in Spanish in DIAN invoice PDF files.  **Expected:** These terms should be translated in Spanish. **Steps to reproduce:** - Activate Accounting app in a Colombian database; - Configure the DIAN credentials, client, journal and product (https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html?highlight=dian); - Create a cust
Original PR description
**Issue:** Some terms don't appear in Spanish in DIAN invoice PDF files.  **Expected:** These terms should be…
**Issue:** Some terms don't appear in Spanish in DIAN invoice PDF files.  **Expected:** These terms should be translated in Spanish. **Steps to reproduce:** - Activate Accounting app in a Colombian database; - Configure the DIAN credentials, client, journal and product (https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html?highlight=dian); - Create a customer invoice; - Send and print with (only) DIAN checkbox checked; - Open the PDF for the invoice. **Cause:** No translations (or erroneous ones) have been found for these keys. **Fix:** Add Spanish translations for these terms. <img width="642" alt="Capture d’écran 2024-12-09 à 11 52 44" src="https://github.com/user-attachments/assets/77f548f4-f87e-4823-9fdc-5b54d0db2a1f"> **Testing:** Testing needs actual credentials and complete configuration (including setting the client's language to LATAM Spanish)  opw-4343184
Project kanban cards now show the budget progress symbol again. This helps users quickly see budget status directly from the project overview without opening each project.
Original PR description
Because of a missing field, the budget symbol to indicate the progress of the budget of a project was not displaying on its kanban card. This commit adds the missing field. Task-4353196
Barcode scanning now avoids accidentally loading every product when handling GS1 barcodes. This prevents slowdowns and reduces the risk of incorrect or delayed warehouse scanning results.
Original PR description
In the `get_specific_barcode_data_batch` method, we convert the search domain if we use GS1 nomenclature.
In some point, we have this code:
```python
converted_barcodes_domain = expression.OR([
converted_barcodes_domain,
[(barcode_field, 'ilike', barcode)]
])
```
The issue with that is `converted_barcodes_domain` is first an empty list, so the call to `expression.OR` results into `[(1, '=', 1)]]` domain. That means when we will search products with this domain, we will get every products.
This fix ensures `converted_barcodes_domain` is not empty before to call `OR`, otherwise we simply assign the converted domain to the variable without the use of `OR`.Portal users can now see the Document link on a shared project task when a related document has been shared with them. This makes shared task documents easier to access and avoids confusion when no other task links are present.
Original PR description
- 18.0 ### Steps to reproduce: - Install document and project. - Create a portal user. - Create the project and the task. - Upload the document in the task. - Share the document with the portal user. - Share the project with read access to the portal user. - Login with the portal user. - Open the shared project and created task. ### Issue: 'Document' is missing from the left sidebar, even after sharing with portal user ### Cause: 'Document' is in the link section of the sidebar. It will be visible when any task link is shared, eg, invoice, sale order, and helpdesk ticket. So, when there is only a document shared it doesn't display. ### Solution: Display the 'Document' when the document is shared with the portal user. task-4194318
Deleting a project now also archives its related document folder when no remaining projects use that folder. This keeps Documents cleaner by preventing unused project folders from lingering after their projects are removed.
Original PR description
Purpose ======= When deleting a project, its documents are archived but not the documents folder. Fixing that by archiving the folder if every projects it is related to has been deleted. Specification ============= As a folder is created for every new project, it seems logical to archive the folder if the project is deleted. This prevents having "flying" folders, i.e. empty project folders not being linked to any project. Technical: - As the same folder can be linked to multiple projects, only archiving the folder if every projects it is related to has been deleted. - Using sudo(False) because documents access rules can be slow. Task-4262380
Documentation and clarification updates
The pull request updates Vauxoo's corporate contributor agreement record to include Eduardo Martinez (emtz10) as an authorized contributor. This supports proper legal tracking for contributions and has no direct impact on Odoo features or users.
Original PR description
Incorporate Eduardo Martinez (emtz10) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at http://www.odoo.com/submit-pr
Miscellaneous changes
**Steps to reproduce:** - Make a POS order - Process to payment - Check receipt **Issue:** The company name is not displayed on the receipt as it was in previous versions. opw-4349203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190174
Original PR description
**Steps to reproduce:** - Make a POS order - Process to payment - Check receipt **Issue:** The company name is not displayed on the receipt as it was in previous versions. opw-4349203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190174
Improved the authentication logging process for romanian E-Factura token generation, for better debugging in case an error happened in between the process. From now, all potential errors in the auth process are catched and saved in the `ir.logging` object, which can be accessed by going to debug mode and going to the `Settings > Technical > Logging` menu. The saved errors are also updated to contain more information than before. In master, the `l10n_ro_edi_oauth_error` object will be delet
Original PR description
Improved the authentication logging process for romanian E-Factura token generation, for better debugging in case an error happened in between the process. From now, all potential errors in the auth process are catched and saved in the `ir.logging` object, which can be accessed by going to debug mode and going to the `Settings > Technical > Logging` menu. The saved errors are also updated to contain more information than before. In master, the `l10n_ro_edi_oauth_error` object will be deleted along with the views. All errors regarding romanian authentication from now on should be viewed in the Logging menu. opw-4187186 Forward-Port-Of: odoo/odoo#190104 Forward-Port-Of: odoo/odoo#187708
Versions -------- - 16.0+ Steps ----- 1. Run `test_reload_template_translations` without demo data. Issue ----- > AssertionError: sale_order_template_id was not found in the view Cause ----- The `sale_order_template_id` field requires the user to have the `sale_management.group_sale_order_template` group, which they don't have by default without demo data. Solution -------- Add the group to the current user before running the test. --- Runbot: https://runbot.odoo.com/
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Run `test_reload_template_translations` without demo data. Issue ----- > AssertionError: sale_order_template_id was not found in the view Cause ----- The `sale_order_template_id` field requires the user to have the `sale_management.group_sale_order_template` group, which they don't have by default without demo data. Solution -------- Add the group to the current user before running the test. --- Runbot: https://runbot.odoo.com/web#id=109475&view_type=form&model=runbot.build.error&menu_id=405&cids=1 opw-4260006 Forward-Port-Of: odoo/odoo#190031
The tax report (KMD report) and annex to the tax report (KMD INF report) for Estonia needed to be reworked to correct errors and fix rounding issues. In this commit, the 'balance_from_tags' label is added to the tax report, allowing a better audit of the report lines. Furthermore, the tax tags are edited to differentiate between tax and base tax lines. These changes are necessary to improve auditing of the tax report lines. task-3997203 --- I confirm I have signed the CLA and read t
Original PR description
The tax report (KMD report) and annex to the tax report (KMD INF report) for Estonia needed to be reworked to correct errors and fix rounding issues. In this commit, the 'balance_from_tags' label is added to the tax report, allowing a better audit of the report lines. Furthermore, the tax tags are edited to differentiate between tax and base tax lines. These changes are necessary to improve auditing of the tax report lines. task-3997203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189923 Forward-Port-Of: odoo/odoo#180856
Basic user can close a PoS session that they did not open if the user logged on the DB is the same as the one linked to the cashier Steps to reproduce: ------------------- * Setup Mitchell Admin as advanced right user on PoS * Setup Marc Demo as basic right user on PoS * Open PoS as Mitchell Admin and login as cashier Marc Demo > Observation: You are not able to close the session * Log out of the Db and log back in as Marc Demo * Open the same PoS > Observation: You are able to close
Original PR description
Basic user can close a PoS session that they did not open if the user logged on the DB is the same as the one linked to the cashier Steps to reproduce: ------------------- * Setup Mitchell Admin as advanced right user on PoS * Setup Marc Demo as basic right user on PoS * Open PoS as Mitchell Admin and login as cashier Marc Demo > Observation: You are not able to close the session * Log out of the Db and log back in as Marc Demo * Open the same PoS > Observation: You are able to close the session Why the fix: ------------ To check if a user was able to close the session we were checking if the user logged in the Db was the same as the one in the cashier. But we need to check who opened the PoS not the current logged in user. opw-4215083 Forward-Port-Of: odoo/odoo#188815 Forward-Port-Of: odoo/odoo#188121
**Description of the issue/feature this PR addresses:** To quote [the Odoo documentation](https://www.odoo.com/documentation/16.0/applications/websites/website/configuration/recaptcha.html?highlight=recaptcha): > All pages using the Form, Newsletter Block, Newsletter Popup snippets, and the eCommerce Extra Step During Checkout form are now protected by reCAPTCHA. However, it's still possible for a bot to register itself to free events, as it doesn't have to go through the checkout p
Original PR description
**Description of the issue/feature this PR addresses:**
To quote [the Odoo documentation](https://www.odoo.com/documentation/16.0/applications/websites/website/configuration/recaptcha.html?highlight=recaptcha):
> All pages using the Form, Newsletter Block, Newsletter Popup snippets, and the eCommerce Extra Step During Checkout form are now protected by reCAPTCHA.
However, it's still possible for a bot to register itself to free events, as it doesn't have to go through the checkout process.. and cause quite a mess.
This commits adds a recaptcha to the new registrations form.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#189766
Forward-Port-Of: odoo/odoo#186991The computation of available category was wrong when the current time was exactly midnight. This was causing runbot error on some test that was exactly executed at midnight. runbot error: 104523, 66109, 107831... Forward-Port-Of: odoo/odoo#190060 Forward-Port-Of: odoo/odoo#189842
Original PR description
The computation of available category was wrong when the current time was exactly midnight. This was causing runbot error on some test that was exactly executed at midnight. runbot error: 104523, 66109, 107831... Forward-Port-Of: odoo/odoo#190060 Forward-Port-Of: odoo/odoo#189842
Reproduce --- - install crm - enable leads - create lead with: email, phone, contact name - send email (that creates contact) - BUG: phone not filled in the contact note: email is only needed to send email thus create partner note2: bug doens't happen without contact name opw-4225694 Forward-Port-Of: odoo/odoo#187284
Original PR description
Reproduce --- - install crm - enable leads - create lead with: email, phone, contact name - send email (that creates contact) - BUG: phone not filled in the contact note: email is only needed to send email thus create partner note2: bug doens't happen without contact name opw-4225694 Forward-Port-Of: odoo/odoo#187284
Currently when multiple discounts are applied with loyalty rewards, the proportion applied to each line is not computed and lead to incoherant values for the next discount applied. Steps to reproduce: ------------------- * Create a promotion program rewarding 20% on the order for a minimum of 5 products * Create a promotion program rewarding 20% on a product category C1 for a minimum of 1 product * Create 2 products of 1$, one of them with the catgory C1 * Open shop session * Add 5 prod
Original PR description
Currently when multiple discounts are applied with loyalty rewards, the proportion applied to each line is not computed and lead to incoherant values for the next discount applied. Steps to…
Currently when multiple discounts are applied with loyalty rewards, the proportion applied to each line is not computed and lead to incoherant values for the next discount applied.
Steps to reproduce:
-------------------
* Create a promotion program rewarding 20% on the order for a minimum of 5 products
* Create a promotion program rewarding 20% on a product category C1 for a minimum of 1 product
* Create 2 products of 1$, one of them with the catgory C1
* Open shop session
* Add 5 products (not C1)
* Add 1 product (with C1)
> Observation: -1.2$ in discount for the 6 products and +0.08$ for the
products in category C1
Why the fix:
------------
After this fix https://github.com/odoo/odoo/commit/85047eca7c0f28e3b174ba166c0d7a1d9965b6b8 all discounts were taken into account when added to `linesToDiscount`.
Since it was now counted we had remove this part to not count the discount twice:
```python
if (lineReward.discount_mode === 'percent') {
const discount = lineReward.discount / 100;
for (const line of discountedLines) {
if (line.reward_id) {
continue;
}
if (lineReward.discount_applicability === 'cheapest') {
remainingAmountPerLine[line.cid] *= (1 - (discount / line.get_quantity()))
} else {
remainingAmountPerLine[line.cid] *= (1 - discount);
}
}
}
```
However when they were added to `linesToDiscount` the whole discount was taken into account, and not just the portion that applies on the order line.
We revert part of the previous fix but we modify the added part to only apply on rewards that have fixed amounts.
opw-4284817
Forward-Port-Of: odoo/odoo#189630
Forward-Port-Of: odoo/odoo#186775Steps to reproduce: - Enable 'Reception Report' in Inventory Configuration - Make an outgoing shipment for a storable product - Make an incoming shipment for that same product - Open the allocation report - Reload the page Issue: The context is lost when reloading the page, meaning that we lose the the `default_picking_ids`/`default_production_ids` in the context, making it unable to open the report. To avoid this, we add the key and values to the router (and thus the URL) so it can
Original PR description
Steps to reproduce: - Enable 'Reception Report' in Inventory Configuration - Make an outgoing shipment for a storable product - Make an incoming shipment for that same product - Open the allocation report - Reload the page Issue: The context is lost when reloading the page, meaning that we lose the the `default_picking_ids`/`default_production_ids` in the context, making it unable to open the report. To avoid this, we add the key and values to the router (and thus the URL) so it can be properly picked up when reloading the report. opw-4321072 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189783 Forward-Port-Of: odoo/odoo#189560
In some business case when the invoice is done before the receipt, the `stock.valuation.layer` currency rate will be taken on the bill rather than the current date. To reproduce the issue: (Need account_accountant) 1. Create a product category PC - Costing method: FIFO - Inventory valuation: Automated 2. Create a product P - Type: Storable - Category: PC 3. On 10/11/2024, confirm a PO with 1 x P at Є10 4. On 11/11/2024, bill it with currency rate of 1.06 at $10.6 4. On 1
Original PR description
In some business case when the invoice is done before the receipt, the `stock.valuation.layer` currency rate will be taken on the bill rather than the current date. To reproduce the issue: (Need account_accountant) 1. Create a product category PC - Costing method: FIFO - Inventory valuation: Automated 2. Create a product P - Type: Storable - Category: PC 3. On 10/11/2024, confirm a PO with 1 x P at Є10 4. On 11/11/2024, bill it with currency rate of 1.06 at $10.6 4. On 12/11/2024, receive P with currency rate of 1.07 at $10.7 Errors: The price SVL is different from the bill Solution: Use currency rate at bill date rather than the current date when invoice before receipt --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189658 Forward-Port-Of: odoo/odoo#187015
Current behaviour: --- When setting mail templates in the communication tab of an event, you initially only see event templates, unless you click on "Search more ..." which allows you to set non-event templates. Expected behaviour: --- Only seeing/and being able to set event templates Steps to reproduce: --- 1. Install event_sale 2. Go to Events, pick an event 3. In the communication tab, remove all templates 4. By clicking on "Search more ..." add a sale template 5. Set as Imm
Original PR description
Current behaviour: --- When setting mail templates in the communication tab of an event, you initially only see event templates, unless you click on "Search more ..." which allows you to set…
Current behaviour: --- When setting mail templates in the communication tab of an event, you initially only see event templates, unless you click on "Search more ..." which allows you to set non-event templates. Expected behaviour: --- Only seeing/and being able to set event templates Steps to reproduce: --- 1. Install event_sale 2. Go to Events, pick an event 3. In the communication tab, remove all templates 4. By clicking on "Search more ..." add a sale template 5. Set as Immediately and After each registration 6. Click on the smart button "Attendees" 7. Create a new attendee with an email then save 8. You may need to create multiple attendees 9. Failed to render inline_template template Cause of the issue: --- When selecting a sale template, the render model is `sale.order` So when passing the registration id to get rendered, it tries to read this id on a `sale.order`, causing an error if a `sale.order` with this id doesn't exist. Caused by: https://github.com/odoo/odoo/commit/6abd149259e9caf815fe1804f1322f623f8fcb50 `_name_search` was overriden, but the "Search more ..." option doesn't used `_name_search` but `web_search_read` Fix: --- Overrode `_search` as well opw-4106237 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189359 Forward-Port-Of: odoo/odoo#180705
The file viewer tries to show the document from the url obtained from the defaultSource function in file_model.js. This function builds the url using urlRoute. Before the fix, the urlRoute is the url from the attachment. This causes the PDF viewer to fail because it has a same-origin policy. This fix avoids to use the url to the one from the attachment's url directly so that the viewer can show the document correctly with the computed urlRoute. The attachment url does not need to be use
Original PR description
The file viewer tries to show the document from the url obtained from the defaultSource function in file_model.js. This function builds the url using urlRoute. Before the fix, the urlRoute is the url from the attachment. This causes the PDF viewer to fail because it has a same-origin policy. This fix avoids to use the url to the one from the attachment's url directly so that the viewer can show the document correctly with the computed urlRoute. The attachment url does not need to be used at all, as the odoo server will properly direct. Forward-Port-Of: odoo/odoo#189335 Forward-Port-Of: odoo/odoo#187970
Step to reproduce: - Set any non-admin user as the cron scheduler - The cron won't run as the permission required to create the ir.cron.progress are admin 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#190037
Original PR description
Step to reproduce: - Set any non-admin user as the cron scheduler - The cron won't run as the permission required to create the ir.cron.progress are admin 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#190037
**Problem**: In the Marketing module, when adding an image and attempting to center it, the centering action does not work because the action is not applying any style to the image. **Solution**: Use the same actions as those implemented in `web_editor` to apply the appropriate styles for centering the image: https://github.com/odoo/odoo/blob/175fdc14769e530424c3b0e364a4c3495aa499d3/addons/web_editor/views/snippets.xml#L600-L602 **Steps to reproduce**: 1. Go to *Email Marketing* and ope
Original PR description
**Problem**: In the Marketing module, when adding an image and attempting to center it, the centering action does not work because the action is not applying any style to the image. **Solution**: Use the same actions as those implemented in `web_editor` to apply the appropriate styles for centering the image: https://github.com/odoo/odoo/blob/175fdc14769e530424c3b0e364a4c3495aa499d3/addons/web_editor/views/snippets.xml#L600-L602 **Steps to reproduce**: 1. Go to *Email Marketing* and open any template. 2. Add an image and resize it. 3. Change the alignment of the image to center. 4. Observe that nothing happens and the image is not centered. opw-4348923 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189413
Steps to reproduce: - Install the Blog module and Studio app (enterprise). - Navigate to the website editor. - Go to Menu Configuration > Blogs. - Select a blog to edit. - Click on the Studio icon to customize the view. - Add the existing field "Blog posts" to the view. - Close Studio. - Restrict the blog to a specific website by selecting one. - A traceback occurs. Since [1], invisible fields now trigger "onchange" methods and "compute" methods while processing views. This exposes
Original PR description
Steps to reproduce: - Install the Blog module and Studio app (enterprise). - Navigate to the website editor. - Go to Menu Configuration > Blogs. - Select a blog to edit. - Click on the Studio icon to customize the view. - Add the existing field "Blog posts" to the view. - Close Studio. - Restrict the blog to a specific website by selecting one. - A traceback occurs. Since [1], invisible fields now trigger "onchange" methods and "compute" methods while processing views. This exposes a bug when attempting to slugify a website URL for a blog that hasn't been assigned an ID yet. [1]: https://github.com/odoo/odoo/commit/db63cb770365be1f81ba051fe6ca5a246dbc9036 opw-4365920 Forward-Port-Of: odoo/odoo#189539
Fixed an issue where the Incoterm was incorrectly displayed as the full object representation `account.incoterm(1,)` instead of its human-readable code. opw-4342104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190040
Original PR description
Fixed an issue where the Incoterm was incorrectly displayed as the full object representation `account.incoterm(1,)` instead of its human-readable code. opw-4342104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190040
This commit adds the missing neutralization necessary for the l10n_jo_edi module introduced in 18.0 in [1] and then backported to 17.0 in [2] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operato
Original PR description
This commit adds the missing neutralization necessary for the l10n_jo_edi module introduced in 18.0 in [1] and then backported to 17.0 in [2] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/odoo/pull/182983 [2] https://github.com/odoo/odoo/pull/176625 Forward-Port-Of: odoo/odoo#190069
A traceback error occurs when the user uninstalls the model used in the mail template referenced in the loyalty program. To reproduce this issue: 1) Install `sale`, `stock`, and enable `loyalty` from settings 2) Create a new loyalty record from `sale/product/discount & Loyalty` 3) Set program type as `loyalty cards` and add `mail template` from `communication` 4) Open the selected mail template and change the model to the `stock lot` 5) Now uninstall the stock module and open the
Original PR description
A traceback error occurs when the user uninstalls the model used in the mail template referenced in the loyalty program. To reproduce this issue: 1) Install `sale`, `stock`, and enable `loyalty` from…
A traceback error occurs when the user uninstalls the model used in the mail template referenced in the loyalty program. To reproduce this issue: 1) Install `sale`, `stock`, and enable `loyalty` from settings 2) Create a new loyalty record from `sale/product/discount & Loyalty` 3) Set program type as `loyalty cards` and add `mail template` from `communication` 4) Open the selected mail template and change the model to the `stock lot` 5) Now uninstall the stock module and open the above loyalty record 6) From the `Loyalty Cards` stat button create a record with a partner Error:- ``` KeyError: False ``` We used the `stock lot` in the mail template. However, when the user uninstalls the `stock` module, the value of `model_id` will be set to `False` in that mail template, which leads to the traceback mentioned above from the code below. https://github.com/odoo/odoo/blob/28815810d9835772aa2fbe72339360f0771634a9/addons/mail/models/mail_template.py#L574-L575 We can resolve this issue by applying `ondelete` equals to `cascade` on `model_id` and `template_id` of the `mail_template` and the `loyalty_mail` respectively. As the model is deleted, `mail template` and `loyalty mail` must also deleted Note:- We already solved a similar type issue from this PR https://github.com/odoo/odoo/pull/180307 sentry-6088927895 Forward-Port-Of: odoo/odoo#189864
This commit removes a typo in a UserError raised when the rendering of the template fails. Fixes #186447 Forward-Port-Of: odoo/odoo#190121 Forward-Port-Of: odoo/odoo#189589
Original PR description
This commit removes a typo in a UserError raised when the rendering of the template fails. Fixes #186447 Forward-Port-Of: odoo/odoo#190121 Forward-Port-Of: odoo/odoo#189589
**Problem**: When invoking a callback after a hotkey press (e.g., `Alt + B`), the following code: https://github.com/odoo/odoo/blob/bafa915f85fb8fc6ca2ae7d194a4593cb2463c2e/addons/web/static/src/core/hotkeys/hotkey_service.js#L286 fails to save the record. **Solution**: Instead of focusing directly on the `el` element, `blur` the `activeElement` to be sure that any changes are saved. **Steps to reproduce**: 1. Open any sale order. 2. Edit the *Terms and Conditions* field. 3. Press `
Original PR description
**Problem**: When invoking a callback after a hotkey press (e.g., `Alt + B`), the following code: https://github.com/odoo/odoo/blob/bafa915f85fb8fc6ca2ae7d194a4593cb2463c2e/addons/web/static/src/core/hotkeys/hotkey_service.js#L286 fails to save the record. **Solution**: Instead of focusing directly on the `el` element, `blur` the `activeElement` to be sure that any changes are saved. **Steps to reproduce**: 1. Open any sale order. 2. Edit the *Terms and Conditions* field. 3. Press `Alt + B` while the input is focused. 4. Observe that the changes are not saved. opw-4219357 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190059 Forward-Port-Of: odoo/odoo#185960
In some rare case, the following call:https://github.com/odoo/odoo/blob/2b15cdecfacdc777b5db1ee151012681c3760899/addons/account_peppol/models/res_partner.py#L89 fails. The call is try-catched but we didn't handle all possible requests exception, only the Connection Error. We therefore instead catch the more general RequestException that will catch all ConnectionError, Timeout, HTTPError, ... We also add a logging to help debugging. task-no Forward-Port-Of: odoo/odoo#190024
Original PR description
In some rare case, the following call:https://github.com/odoo/odoo/blob/2b15cdecfacdc777b5db1ee151012681c3760899/addons/account_peppol/models/res_partner.py#L89 fails. The call is try-catched but we didn't handle all possible requests exception, only the Connection Error. We therefore instead catch the more general RequestException that will catch all ConnectionError, Timeout, HTTPError, ... We also add a logging to help debugging. task-no Forward-Port-Of: odoo/odoo#190024
In this commit, we fix a undeterministic behavior about check the pathname of window in function assertPathName. In this function, we check the url of the window but the url can changes few ms after the DOM has been loaded. So the check can occurs after the DOM has been loaded. To avoid this behavior, we wait for the pathname instead of check it direclty. runbot-error-id~70316 Forward-Port-Of: odoo/odoo#189770
Original PR description
In this commit, we fix a undeterministic behavior about check the pathname of window in function assertPathName. In this function, we check the url of the window but the url can changes few ms after the DOM has been loaded. So the check can occurs after the DOM has been loaded. To avoid this behavior, we wait for the pathname instead of check it direclty. runbot-error-id~70316 Forward-Port-Of: odoo/odoo#189770
The tax report (KMD report) and annex to the tax report (KMD INF report) for Estonia needed to be reworked to correct errors and fix rounding issues. With this commit, the tax report: 1. Adds the balance_from_tags to allow auditing the report lines, since only aggregation was used before. 2. Fixes rounding issues by using the integer_rounding feature and adding rounding differences to the VAT closing entry. This commit also rewrites the KMD INF report. It creates one report composed of t
Original PR description
The tax report (KMD report) and annex to the tax report (KMD INF report) for Estonia needed to be reworked to correct errors and fix rounding issues. With this commit, the tax report: 1. Adds the…
The tax report (KMD report) and annex to the tax report (KMD INF report) for Estonia needed to be reworked to correct errors and fix rounding issues. With this commit, the tax report: 1. Adds the balance_from_tags to allow auditing the report lines, since only aggregation was used before. 2. Fixes rounding issues by using the integer_rounding feature and adding rounding differences to the VAT closing entry. This commit also rewrites the KMD INF report. It creates one report composed of two sections with different columns, using the custom engine to construct both parts. Part A contains information on invoices issued, grouped by move_id and id, to allow showing multiple lines per invoice when different tax rates or special tax types are in one invoice. It only includes invoices with taxable supply at 22%, 20%, 9% and 5%. It excludes invoices of partners whose Tax ID is / and foreigner partners who have a Tax ID not starting by EE. Part B contains information on invoices received, grouped by move_id. Each line showcases information about one invoice with taxable supply at 22%, 20%, 9% and 5%. It relies on a Tax ID starting with EE. The reports follow the guidelines available in https://www.emta.ee/en/business-client/taxes-and-payment/tax-returns-exchange-information/vat-return-forms-vd-and-vdp (forms valid from 01.01.2024 onwards). task-3997203 Forward-Port-Of: odoo/enterprise#75309 Forward-Port-Of: odoo/enterprise#70371
Current behaviour: --- When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field. Expected behaviour: --- Ability to duplicate a resource booking Steps to reproduce: --- 1. Go to Appointments 2. Select a resource appointments (ie. Tennis Court) 3. Click on new (To make a new resource booking) 4. Set a name, attendee, AND resource (ie. Court 1) 5. Go to list view, and open newly made booking 6. Click on the cog > Duplicate
Original PR description
Current behaviour: --- When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field. Expected behaviour: --- Ability to duplicate a resource…
Current behaviour: --- When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field. Expected behaviour: --- Ability to duplicate a resource booking Steps to reproduce: --- 1. Go to Appointments 2. Select a resource appointments (ie. Tennis Court) 3. Click on new (To make a new resource booking) 4. Set a name, attendee, AND resource (ie. Court 1) 5. Go to list view, and open newly made booking 6. Click on the cog > Duplicate 7. Validation Error Cause of the issue: --- Caused by: https://github.com/odoo/enterprise/commit/064e0da976edd7ef501e4fb33d4d579eaab85a3d When duplicating a calendar.event, at the field appointment_resource_ids, the relation table appointment_booking_line is used on the fields calendar_event_id and appointment_resource_id. However, the model appointment_booking_line has another required field capacity_reserved. So when inserting into the table: https://github.com/odoo/odoo/blob/b64a507697381fd7bb205f4a2b2217322d31811a/odoo/fields.py#L4945 Only the two specified columns/fields are set, but not the third required field capacity_reserved. Which causes a SQL error "violates not-null constraint" opw-4187159 Forward-Port-Of: odoo/enterprise#75014 Forward-Port-Of: odoo/enterprise#71489
**Issue:** - When creating an approval request with the type "Automated Sequence", the Approval Subject field is empty and readonly, making it impossible to save the record. **Steps To Reproduce:** - Create a new Approval Type, check the "Automated Sequence" box, and set a "code". - In dashboard Click on "New Request" - Set the category to the one you just created, and save. - Notice the Invalid Field error. **Solution:** - Set 'required' to 'not automated_sequence'. opw-4326974
Original PR description
**Issue:** - When creating an approval request with the type "Automated Sequence", the Approval Subject field is empty and readonly, making it impossible to save the record. **Steps To Reproduce:** - Create a new Approval Type, check the "Automated Sequence" box, and set a "code". - In dashboard Click on "New Request" - Set the category to the one you just created, and save. - Notice the Invalid Field error. **Solution:** - Set 'required' to 'not automated_sequence'. opw-4326974 Forward-Port-Of: odoo/enterprise#74793
First we replaced the 'send' activity by the 'pay' activity. Since the 'pay' activity was inadequate for the FIDU /my/databases view (it's only created when there is tax to pay), we brought the 'send' activity back. But in order to see the 'pay' activity, the 'send' activity had to be marked as done & nobody knows how to do that. And what if the user wants to pay before sending? (to avoid fines) So in this PR, we create the 'send' and 'pay' acitivities at the same time. Those who want to send
Original PR description
First we replaced the 'send' activity by the 'pay' activity. Since the 'pay' activity was inadequate for the FIDU /my/databases view (it's only created when there is tax to pay), we brought the 'send' activity back. But in order to see the 'pay' activity, the 'send' activity had to be marked as done & nobody knows how to do that. And what if the user wants to pay before sending? (to avoid fines) So in this PR, we create the 'send' and 'pay' acitivities at the same time. Those who want to send, send. And those who want to pay, pay. Task - TSB/BIB/CHKL/AYH discussion Forward-Port-Of: odoo/enterprise#74915
When the tour is running in single app locally, it is failing Forward-Port-Of: odoo/enterprise#75352 Forward-Port-Of: odoo/enterprise#74773
Original PR description
When the tour is running in single app locally, it is failing Forward-Port-Of: odoo/enterprise#75352 Forward-Port-Of: odoo/enterprise#74773
Current behaviour: --- When setting mail templates in the communication tab of an event, you initially only see event templates, unless you click on "Search more ..." which allows you to set non-event templates. Expected behaviour: --- Only seeing/and being able to set event templates Steps to reproduce: --- 1. Install event_sale 2. Go to Events, pick an event 3. In the communication tab, remove all templates 4. By clicking on "Search more ..." add a sale template 5. Set as Imm
Original PR description
Current behaviour: --- When setting mail templates in the communication tab of an event, you initially only see event templates, unless you click on "Search more ..." which allows you to set…
Current behaviour: --- When setting mail templates in the communication tab of an event, you initially only see event templates, unless you click on "Search more ..." which allows you to set non-event templates. Expected behaviour: --- Only seeing/and being able to set event templates Steps to reproduce: --- 1. Install event_sale 2. Go to Events, pick an event 3. In the communication tab, remove all templates 4. By clicking on "Search more ..." add a sale template 5. Set as Immediately and After each registration 6. Click on the smart button "Attendees" 7. Create a new attendee with an email then save 8. You may need to create multiple attendees 9. Failed to render inline_template template Cause of the issue: --- When selecting a sale template, the render model is `sale.order` So when passing the registration id to get rendered, it tries to read this id on a `sale.order`, causing an error if a `sale.order` with this id doesn't exist. Caused by: https://github.com/odoo/odoo/commit/6abd149259e9caf815fe1804f1322f623f8fcb50 `_name_search` was overriden, but the "Search more ..." option doesn't used `_name_search` but `web_search_read` Fix: --- Overrode `_search` instead opw-4106237 Forward-Port-Of: odoo/enterprise#75007 Forward-Port-Of: odoo/enterprise#73947