Wednesday, August 9, 2023
61 changes · master
New functionality added to Odoo
Users can now record and send short voice messages directly in Discuss chats and channels. This makes conversations faster and more expressive by adding microphone recording, audio attachments, waveform display, and playback support across supported browsers.
Original PR description
With this commit, users can send voice messages in channels and chat. There's a new button in composer to record audio from the microphone, up to 1 minute clip duration. This adds a voice attachment with its dedicated voice player that shows waveforms and allows playback. To ensure compatibility in all supported browsers, we choose to encode voice recording with `audio/mp3` thanks to lib `lamejs`. Task-3240168
Enhancements to existing features
Odoo now refreshes the relevant business data more reliably after certain on-screen actions are completed. This helps users see up-to-date information without needing extra manual reloads, reducing confusion and improving workflow continuity.
Resolved issues and error corrections
This fixes an issue where Kanban cards could keep showing old field values after a user changed them through an embedded widget. Business users will see more accurate, up-to-date information in Kanban views without needing to refresh or reopen the page.
Original PR description
Before this commit, calls to record[fieldname][value/raw_value] in the arch of a kanban view did not take into account updates on the Record Datapoint. So if any data in the Record changed, the [raw_value/value] was not modified.
In a custom KanbanRecord, you should never use the record containing the value and raw_value. We will therefore replace this call by using the datapoint record directly.
How to reproduce:
- Have a kanban view with a record.my_field.value and a widget allowing
you to modify the value of my_field.
- Click on the widget
Before this commit:
The value of my_field does not change
After this commit:
The value of my_field has been updated.
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-prCode cleanup and technical improvements
This update standardizes how Odoo manages incoming email aliases across several apps, reducing unused aliases and preventing duplicate or invalid alias issues. It also prepares the platform for future support of company-specific alias domains, which should improve reliability in multi-company setups.
Original PR description
Miscellaneous changes
Since #119325, html2canvas is not used for the toInline process anymore. Loading the script was still done in the web editor and mass mailing, which is not needed anymore. task-3446888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#130381 Forward-Port-Of: odoo/odoo#130211
Original PR description
Since #119325, html2canvas is not used for the toInline process anymore. Loading the script was still done in the web editor and mass mailing, which is not needed anymore. task-3446888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#130381 Forward-Port-Of: odoo/odoo#130211
Odoo now has a more targeted way to recognize guest users when they access mail, discussion, public page, and live chat features. This helps make guest access more consistent while avoiding unnecessary processing on unrelated requests.
Original PR description
This PR adds the `add_guest_to_context` decorator in order to provide a generic way to extract the guest from a request. It will be used to unified guest extraction from cookie/param based on its provenance (external livechat/public page). This is better than the `pre_dispatch` method since it can be applied to specific routes instead of adding this logic to every request. part of task-3332628
Website editor drag-and-drop rules are now defined directly on the relevant building blocks, helping prevent users from placing form fields or tables of contents in invalid locations. This makes page editing more reliable and reduces the chance of broken layouts or unsupported content structures.
Original PR description
Since [1] form fields cannot be moved outside of their form and since [2] table of contents cannot be nested within another table of content. Those were implemented with specific references to website classes within web_editor. This commit introduces declarative mechanisms for both situations: - `data-drop-lock-within`: prevents dropping outside the closest parent that matches the specified selector. - `data-drop-exclude-ancestor`: disallows dropping within a parent that matches the specified selector. [1]: https://github.com/odoo/odoo/commit/638d0e875dcb05191fe833d2f889235891dfb46a [2]: https://github.com/odoo/odoo/commit/55339cd6a7b7916184893c0fe27b5483683a047a task-3131384
This update reorganizes and strengthens the internal structure behind Odoo's mail services. It helps developers catch integration issues earlier and makes the mail module easier to maintain, with minimal direct impact on day-to-day users.
This update improves internal test support for scenarios where visitors or guests interact with messaging, live chat, calendar, and related website features. It helps Odoo validate future guest-based live chat and messaging behavior more reliably before it reaches users.
Original PR description
*: bus, calendar, im_livechat, web, website_livechat. This PR adds the possibility to set the current user during tests as well as the mail guest. This will be used to test mail guest page and livechat once the visitors will be treated as guests. part of task-3332628 enterprise: https://github.com/odoo/enterprise/pull/45331
When a forum question is deleted, users are now taken back to the forum home page instead of staying on the deleted question page. This avoids a confusing dead-end experience and makes navigation clearer after deletion.
Original PR description
before this commit, on deleting a question from forum is redirecting to the same question page with deleted tag. after this commit, user will be redirected to forum home page after deleting a question --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo users can now see more details about their IAP services and available credits directly from Odoo. They can also update warning settings, access their IAP accounts more easily, and buy credits from the account form.
Original PR description
Description of the issue/feature this PR addresses: Refactoring some IAP functionalities Current behavior before PR: - Very minimal view of IAP accounts Desired behavior after PR is merged: - Information about services available to view from odoo - Can edit some iap services fields from odoo - Change the redirect route of view services to view my IAP accounts --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The forum post form now only shows closing-related fields when a post is actually closed. It also limits answer-specific fields to child posts, making the form clearer and reducing confusion for users managing forum content.
Original PR description
before this commit, in the forum post form view, the closing related fields, is visible even if the post is not closed and question field should not be shown in the parent post. after this commit, closing fields will be shown only once post is closed and parent_id and is_correct field will be shown only in child post(answer) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update supports the broader rollout of voice messages in Discuss chats and channels by ensuring related document workflows are covered in testing. It helps maintain reliability for users sharing and managing documents alongside chat conversations.
Original PR description
Adding voiceMessageService to document's tests. This PR is associated with [PR #117036](https://github.com/odoo/odoo/pull/117036) Task-3240168
Customer records can now store default Mexican e-invoicing values for payment way and Uso. These defaults flow into sales orders and invoices, reducing manual edits and saving time for repeat or subscription customers.
Original PR description
Before it is added 'Payment way' had to be updated manually in invoice. What does it do - 'Payment way' now updatable in sale_order and the set value is used when creating an invoice. - 'Payment way' and 'Uso' are now setable on the customer sheet; the values are used as default when creating a sale order and/or invoice. How does it work Use compute function to set the values, values are recomputed everytime the costumer is modified on the sale order or invoice. The compute functions read the partner_id relevant field values to check if they are set. task-3388110
The Documents app test coverage now includes scenarios for guest and dynamically created users. This helps ensure shared document workflows remain reliable for users who are not standard internal employees.
Original PR description
part of task-3332628 community: https://github.com/odoo/odoo/pull/130811
Draft records in Mail now show a follower count of 0 instead of a loading spinner before they are saved. This avoids a confusing wait state and makes the record status clearer for users.
Original PR description
Before this commit, the follower loading spinner was shown for draft records until it was saved. This is incorrect, follower count should instead be 0. This commit fixes this issue.
Point of Sale now clearly highlights invalid money amounts in cash in/out and session closing popups. This helps cashiers spot entry mistakes immediately and reduces the chance of incorrect cash operations.
Original PR description
Since the use of Bootstrap, the money inputs using the useValidateCashInput hook are no longer correctly displayed when the user input is invalid. Steps to reproduce: - Open a session in a shop - Open the "Cash In/Out" menu with the top right dropdown menu - Enter an invalid amount, like "invalid" for example The input is not displayed with red borders. This commit fixes the display of invalid inputs in the Cash In/Out and Closing Session popups, using the Bootstrap is-invalid CSS class. task-id: 3444048
Cancelled point of sale orders are now ignored when closing a POS session, preventing incorrect inventory movements and accounting differences. This helps shops and restaurants close sessions cleanly after deleting saved orders, while still retaining cancelled payment records for reference.
Original PR description
The POS orders can currently be saved in the database, then removed which in reality puts them in the cancelled state. Those cancelled orders are processed when their session is closed, which results…
The POS orders can currently be saved in the database, then removed which in reality puts them in the cancelled state. Those cancelled orders are processed when their session is closed, which results in unbalanced accounting lines and inventory pickings still created. Steps to reproduce: With a shop: - Set a trusted POS for the shop to use - Open a session for that shop - Create an order with 1 product - Click on the "Save" button of the trusted POS feature (in the product screen, above the numpad) - Open the orders with the top right dropdown menu - Click on the trash to delete the previously created and saved order - Close the session With a restaurant: - Open a session - Create an order with 1 product - Click on the "Back" button (to save the order in the database) - Open the orders with the top right dropdown menu - Click on the trash to delete the previously created and saved order - Close the session In both cases, the "Force Close Session" error popup appears. After closing the session with the "Close Session & Post Entries" backend button, the inventory picking is created and validated, accounting Product Sales and Tax lines are created, and there is a "difference at closing POS session". The fix consists of not processing cancelled orders when closing POS sessions. The payments of cancelled orders are still saved in the database, but not taken into account in the sessions closing process. task-id: 3452353
This fixes a Point of Sale display issue where users could still access the top navigation bar while a temporary screen, such as the partner list, was open. The temporary screen now behaves as intended, keeping users focused on completing the required action before returning to the main flow.
Original PR description
With the introduction of Bootstrap in the PoS, the navbar was still accessible when showing a tempScreen as the PartnerListScreen. This is not intended as the tempScreen act "like a big popup" where the user must do the action on the tempScreen before doing anything else. The problem here is that the Bootstrap integretion forgot to add the correct style to the div "block-top-header" which is done in this PR (background-color, width, height and position). For example, the top of the PartnerListScreen looked like this before  and now looks like this  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The forum validation queue filter now shows the intended icon instead of an incorrect stray character. This makes the moderation filter menu look consistent and easier for administrators to understand.
Original PR description
before this commit, in the forum validation queue filter, along with the text filter instead of icon some hard coded value(圾) is shown as text. * create a user with very minimum XP * create a post from new user login * from admin login, click validation queue in the forum * click on filter in the validation queue after this commit, the text will be replaced with fa-font icon, so that all filters will look similar. Before:  After:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Belgian payroll now correctly includes up to 30 unpaid sick days when calculating 13th month payments. This helps ensure employees receive the correct year-end compensation and reduces payroll correction work.
The subscription report now calculates monthly recurring revenue from each subscription line instead of relying on the overall sales order value. This makes reported revenue more accurate when reviewing subscription performance and line-level details.
Original PR description
MRR on subscription report was computed for lines based on the SO MRR, it's now computed based on the line similar to how it's computed in python `_compute_recurring_monthly`. task-id : 3446444
The appointment page now only shows the publish button to users who have permission to publish. This prevents crashes for users without the necessary access rights and creates a smoother experience.
Original PR description
Earlier, publish button was visible for all user type but caused crashes for the user who don't have the access to publish it. This commit addresses the issue. Now, only users with the appropriate access rights will see the button, preventing crashes. Task-3339257
The Knowledge app now shows the property helper only when no properties remain. This prevents confusing helper prompts from appearing while users are simply deleting individual properties.
Original PR description
**Before this PR**: Property helper was appear when deleting any property Because this issue was introduced in this commit https://github.com/odoo/enterprise/commit/127f512b1a72957eb23c41103ecab44e1fdce0e7 **After this PR**: Property helper will come only when there is no property **Task**-3450016
Kanban cards now refresh field values correctly after a user changes data through an action or widget. This prevents outdated information from remaining visible on cards, improving confidence in day-to-day workflows such as document and social post management.
Original PR description
Before this commit, calls to record[fieldname][value/raw_value] in the arch of a kanban view did not take into account updates on the Record Datapoint. So if any data in the Record changed, the [raw_value/value] was not modified.
In a custom KanbanRecord, you should never use the record containing the value and raw_value. We will therefore replace this call by using the datapoint record directly.
How to reproduce:
- Have a kanban view with a record.my_field.value and a widget allowing
you to modify the value of my_field.
- Click on the widget
Before this commit:
The value of my_field does not change
After this commit:
The value of my_field has been updated.RATIONALE We plan to move from a single alias-domain configuration to a multi company enabled support for alias domains and aliases. First step to prepare this change is to cleanup alias usage…
RATIONALE
We plan to move from a single alias-domain configuration to a multi company
enabled support for alias domains and aliases. First step to prepare this
change is to cleanup alias usage through various Odoo addons.
ALIAS USAGE CLEANUP
Cleanup alias usage and definition. Prepare code to ease future changes and
improvements. Notably
* add a 'alias_email' computed field on the mixin allowing to have the
complete alias email when set, and False in case it is inactive or linked
to an inactive alias domain;
* remove unnecessary alias_id field definition when just the help differs
from the standard definition coming from the 'mail.alias.mixin';
* use fields coming from 'inherits' instead of using alias_id and its sub-
fields; notably use 'alias_display_name' and 'alias_email' fields;
* remove useless custom code and management;
* improve alias parameters support code in configuration parameters;
ALIAS MIXIN WITH OPTIONAL ALIAS_ID
Some models would like to use the 'mail.alias.mixin' but it creates an alias
for each record in the parent model. This leads to a lot of unused aliases
if only a subset of those records really use aliases i.e. a lot of aliases
with 'alias_name' being 'False'.
In this commit we introduce a new mixin 'mail.alias.mixin.optional' that
behaves like the old 'mail.alias.mixin' but without having the 'alias_id'
field required i.e. without the "inherits". When creating a record without
giving an 'alias_name' no alias is created.
In this PR we use it notably to remove custom code in account journal model
and make it more standard. Using it in more models will be done later, but
it is a candidate to cleanup unused aliases related to discuss channel model.
ALIAS NAME SANITIZE
Currently there is a constraint on alias name as we allow only a subset of
valid latin characters in it aka `[a-zA-Z0-9!#$%&'*+\-/=?^_`{|}~]`. There
is also an automatic sanitize of alias name at create / write that replaces
any non-word characters by an hyphen. This sanitize is stricter than the
constraint and it is not really coherent.
In this commit we make the sanitize inlined with the constraint, allowing
more characters to go through the 'mail.alias.mixin' cleaning pass notably.
Enforce that void alias names are forced to False to avoid any constraint
issue. Sanitize method is now independent from the check method, to avoid
calling multiple times the sanitization as it is often used for other checks.
MISC
Lint / reorder code, prepare future changes. Add tests, notably for alias
name sanitize and management.
Provide various fixes, see sub commits for more details.
LINKS
After odoo/odoo#130768 and odoo/enterprise#45204 this is another preparation
for multi-company aliases (see odoo/odoo#76734 and odoo/enterprise#20983).
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)This update standardizes how email aliases are defined and displayed across several Odoo apps, reducing duplicated setup and making future changes easier. It keeps existing journal-specific behavior while preparing the platform for future multi-company alias support.
Original PR description
Cleanup alias usage and definition. Prepare code to ease future changes and improvements. Notably * add a 'alias_email' computed field on the mixin allowing to have the complete alias email when set,…
Cleanup alias usage and definition. Prepare code to ease future changes and
improvements. Notably
* add a 'alias_email' computed field on the mixin allowing to have the
complete alias email when set, and False in case it is inactive or linked
to an inactive alias domain;
* remove unnecessary alias_id field definition when just the help differs
from the standard definition coming from the 'mail.alias.mixin';
* use fields coming from 'inherits' instead of using alias_id and its sub-
fields; notably use 'alias_display_name' and 'alias_email' fields;
* remove useless custom code and management;
* improve alias parameters support code in configuration parameters;
Alias usage is now more standard on 'account.journal' model. Main specific
features of journal are still present: automatic alias name generation,
support of non-ascii characters, ... See community PR for more details.
LINKS
After odoo/odoo#130768 and odoo/enterprise#45204 this is another preparation
for multi-company aliases (see odoo/odoo#76734 and odoo/enterprise#20983).
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)Improve layout of left panel, for extra resources. (the screen was a bit bloated, not clear distinction with real content and extra resources) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131079
Original PR description
Improve layout of left panel, for extra resources. (the screen was a bit bloated, not clear distinction with real content and extra resources) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131079
Steps to reproduce: - Install `website_appointment` module - Activate a second language on main website - Activate debug mode - Go to Website -> Configuration -> Online Appointments - Share multiple appointment and copy the link - Open the link in a new tab - Switch to second language - Open editor and click on `Translate` button Issue: Traceback is raised. Cause: When sharing multiple appointment and opening the shared link, we are redirected on the
Original PR description
Steps to reproduce: - Install `website_appointment` module - Activate a second language on main website - Activate debug mode - Go to Website -> Configuration -> Online Appointments - Share multiple…
Steps to reproduce: - Install `website_appointment` module - Activate a second language on main website - Activate debug mode - Go to Website -> Configuration -> Online Appointments - Share multiple appointment and copy the link - Open the link in a new tab - Switch to second language - Open editor and click on `Translate` button Issue: Traceback is raised. Cause: When sharing multiple appointment and opening the shared link, we are redirected on the page to select the right appointment and we have the key `filter_appointment_type_ids` (with the IDs of the appointments) with the value already encoded. e.g: `[1, 3]` => `%5B1%2C+3%5D`. When translating a page by redirecting to the same URL (but encoded) with param `edit_translations` set to 1, the URL is re-encoded and therefore the value of the key `filter_appointment_type_ids` is double 'encoded' and broken/not possible to parse. e.g: `%5B1%2C+3%5D` => `%255B1%252C%2B3%255D`. Solution: Don't re-encode the updated URL; `goToWebsite` is expecting a non encoded path and is in charge of the re-encoding it. opw-3409757 Forward-Port-Of: odoo/odoo#130175
Steps to reproduce: ------------------- - go to Recruitment app and click on a job position; - for an application without recruiter, click on the "Assign" button on the kanban box. Issue: ------ A traceback occurs. Cause: ------ To find available user_ids, we use the `"[..., ('company_ids', 'in', company_id)]"` domain. But `company_id` is not in the context. Solution: --------- Add `company_id` in the context by adding it to the view. opw-3450558 Forward-Port-Of: odoo/odo
Original PR description
Steps to reproduce:
-------------------
- go to Recruitment app and click on a job position;
- for an application without recruiter, click on the "Assign" button on the kanban box.
Issue:
------
A traceback occurs.
Cause:
------
To find available user_ids,
we use the `"[..., ('company_ids', 'in', company_id)]"` domain.
But `company_id` is not in the context.
Solution:
---------
Add `company_id` in the context by adding it to the view.
opw-3450558
Forward-Port-Of: odoo/odoo#131024
Forward-Port-Of: odoo/odoo#130887The 'onsite' payment provider shouldn't be shown to the user if the cart/order only contains services (or if there are no onsite carriers). The logic was there but the filtering didn't correctly update the values. opw-3437107 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131083
Original PR description
The 'onsite' payment provider shouldn't be shown to the user if the cart/order only contains services (or if there are no onsite carriers). The logic was there but the filtering didn't correctly update the values. opw-3437107 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131083
To reproduce the issue, follow these steps: 1. Install the Timesheet and Project. 2. From the settings menu, create a new company. 3. Create a project using the newly created company(e.g. New Company) and add a task to it. 4. Open the Timesheet application and create a new timesheet. 5. In the timesheet, select the project created in step 3, and observe that the dropdown for tasks does not display any task. Cause for this issue: - The timesheet application has a domain set for the t
Original PR description
To reproduce the issue, follow these steps: 1. Install the Timesheet and Project. 2. From the settings menu, create a new company. 3. Create a project using the newly created company(e.g. New…
To reproduce the issue, follow these steps: 1. Install the Timesheet and Project. 2. From the settings menu, create a new company. 3. Create a project using the newly created company(e.g. New Company) and add a task to it. 4. Open the Timesheet application and create a new timesheet. 5. In the timesheet, select the project created in step 3, and observe that the dropdown for tasks does not display any task. Cause for this issue: - The timesheet application has a domain set for the task field where the company associated with the task_id should be the same as the company selected in the current environment. - However, when a new project is created with a 'New Company', the tasks associated with it also have the 'New Company' assigned to them. On the other hand, the current environment has a default company called 'Your Company' associated with it. - Therefore, due to this domain setting, the task field does not display any tasks since there are no tasks associated with the 'Your Company' in the current environment. Fix: - Since the cause of the issue is related to the company domain set in the task field, we can solve it by removing it from the domain. task-3323027 Forward-Port-Of: odoo/odoo#130910 Forward-Port-Of: odoo/odoo#122631
Similar to what was done [here](https://github.com/odoo/odoo/commit/5d0111d079601c07c62717575cb22ead15c585d0) when the credit limit feature was introduced, a `sudo()` is also necessary in `_load_records_create()`. This method is called when importing contacts from a CSV file. So the access to the commercial fields is done when syncing fields from the commercial entity to its contact and should not block the import. Fixes #126567 --- I confirm I have signed the CLA and read the PR guid
Original PR description
Similar to what was done [here](https://github.com/odoo/odoo/commit/5d0111d079601c07c62717575cb22ead15c585d0) when the credit limit feature was introduced, a `sudo()` is also necessary in `_load_records_create()`. This method is called when importing contacts from a CSV file. So the access to the commercial fields is done when syncing fields from the commercial entity to its contact and should not block the import. Fixes #126567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#129587
Reproduction: 1. Install Note, create a new note 2. Start the Inspector, edit the placeholder <p> element in the description 3. Replace the element as `<p style="color: rgb(32, 31, 30); font-family : "Segoe UI", "Segoe UI Web (West European)", " Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helveti ca Neue", sans-serif; font-size: 15px;">dsfhislahflidsahisa</p>` 4. The saving icon appears, click it but it will always be there, e.g. always dirt
Original PR description
Reproduction: 1. Install Note, create a new note 2. Start the Inspector, edit the placeholder <p> element in the description 3. Replace the element as `<p style="color: rgb(32, 31, 30); font-family : "Segoe UI", "Segoe UI Web (West European)", " Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, "Helveti ca Neue", sans-serif; font-size: 15px;">dsfhislahflidsahisa</p>` 4. The saving icon appears, click it but it will always be there, e.g. always dirty Fix: instead of comparing the raw value of the prop value and editing value, we parse them and compare after the parsing opw-3341605 task-3434080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#129173
Steps to reproduce this bug: 1- On a Bank type journal, set true the "Use electronic and deferred checks" field 2- Do a new vendor payment with Bank journal and Manual payment method 3- Corresponding journal entry shows "Check False delivered"   ![dev-31773-3](https://github.com/odoo/odoo/assets
Original PR description
Steps to reproduce this bug: 1- On a Bank type journal, set true the "Use electronic and deferred checks" field 2- Do a new vendor payment with Bank journal and Manual payment method 3- Corresponding journal entry shows "Check False delivered"    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#129283
Incorporate Alejandro Mellado (alejandromellado) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131135
Original PR description
Incorporate Alejandro Mellado (alejandromellado) as Vauxoo's contributor. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131135
**Description of the issue/feature this PR addresses:** `_get_starred_counter` method is obsolete now. So, there is no meaning in keeping it anymore. It's usecase has been removed by this PR https://github.com/odoo/odoo/pull/83777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131039
Original PR description
**Description of the issue/feature this PR addresses:** `_get_starred_counter` method is obsolete now. So, there is no meaning in keeping it anymore. It's usecase has been removed by this PR https://github.com/odoo/odoo/pull/83777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131039
Steps to reproduce: - Go to Contacts and open any contact (e.g. Contact X) - Check its configured Account Receivable (e.g. 121000 Account Receivable) - Configure that account and set a default Sales tax on it (e.g. Tax 15%) - Create an invoice with Contact X as customer - Add an invoice line for any amount (e.g. $100) and any tax - Swith to "Journal Items" tab and display "Taxes" column A line (with 121000 Account Receivable) has been created automatically to balance the invoice line. Th
Original PR description
Steps to reproduce: - Go to Contacts and open any contact (e.g. Contact X) - Check its configured Account Receivable (e.g. 121000 Account Receivable) - Configure that account and set a default Sales…
Steps to reproduce: - Go to Contacts and open any contact (e.g. Contact X) - Check its configured Account Receivable (e.g. 121000 Account Receivable) - Configure that account and set a default Sales tax on it (e.g. Tax 15%) - Create an invoice with Contact X as customer - Add an invoice line for any amount (e.g. $100) and any tax - Swith to "Journal Items" tab and display "Taxes" column A line (with 121000 Account Receivable) has been created automatically to balance the invoice line. This line has a tax (i.e. Tax 15%): the default one configured on the account. There should not be a tax for a receivable account. Another issue is that the tax is set on the aml but not tax line has been created. - Go back to "Invoice Lines" tab - Remove the tax on the invoice line - Save In "Journal Items" tab, the tax line has been created from the aml with the receivable account. - Go back to "Invoice Lines" tab - Add a tax on the invoice line again - Save - Remove the tax on the invoice line - Save In "Journal Items" tab, there are now 2 tax lines from the aml with the receivable account. By repeating the previous steps, new tax lines can be created infinitely. Solution: To prevent the issue, the default taxes shouldn't be populated on the aml when the account is a receivable (or payable) one and when the move type is an "invoice" type one. As "display_type" field of "account.move.line" is set to "payment_term" when the account is a receivable or a payable one and when "is_invoice" is True on the move, no tax will be set in "_compute_tax_ids" computed method when "display_type" is "payment_term". opw-3345953 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131089 Forward-Port-Of: odoo/odoo#130677
Make 'Invoice app' text bold. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131069
Original PR description
Make 'Invoice app' text bold. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131069
Since 16.4, the number of file made pylint reach the default memory limit from time to time. This commit will remove the limit for this test as it was done for chrome. The next step would be to split the test per set of module or maybe analyze the memory consumption of some custom check. Forward-Port-Of: odoo/odoo#131240
Original PR description
Since 16.4, the number of file made pylint reach the default memory limit from time to time. This commit will remove the limit for this test as it was done for chrome. The next step would be to split the test per set of module or maybe analyze the memory consumption of some custom check. Forward-Port-Of: odoo/odoo#131240
Description of the issue/feature this PR addresses: Having a customization that adds a field name called `employee_id` with a different datatype a character field in this case will raise the following exception when Installing attendance module or during Upgrade process. ``` Traceback (most recent call last): File "/home/ahmed/odoo/odoo/addons/base/models/ir_http.py", line 237, in _dispatch result = request.dispatch() File "/home/ahmed/odoo/odoo/http.py", line 698, in dispatch resu
Original PR description
Description of the issue/feature this PR addresses: Having a customization that adds a field name called `employee_id` with a different datatype a character field in this case will raise the…
Description of the issue/feature this PR addresses:
Having a customization that adds a field name called `employee_id` with a different datatype a character field in this case will raise the following exception when Installing attendance module or during Upgrade process.
```
Traceback (most recent call last):
File "/home/ahmed/odoo/odoo/addons/base/models/ir_http.py", line 237, in _dispatch
result = request.dispatch()
File "/home/ahmed/odoo/odoo/http.py", line 698, in dispatch
result = self._call_function(**self.params)
File "/home/ahmed/odoo/odoo/http.py", line 368, in _call_function
return checked_call(self.db, *args, **kwargs)
File "/home/ahmed/odoo/odoo/service/model.py", line 94, in wrapper
return f(dbname, *args, **kwargs)
File "/home/ahmed/odoo/odoo/http.py", line 357, in checked_call
result = self.endpoint(*a, **kw)
File "/home/ahmed/odoo/odoo/http.py", line 921, in __call__
return self.method(*args, **kw)
File "/home/ahmed/odoo/odoo/http.py", line 546, in response_wrap
response = f(*args, **kw)
File "/home/ahmed/odoo/addons/web/controllers/main.py", line 1328, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/home/ahmed/odoo/addons/web/controllers/main.py", line 1316, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/home/ahmed/odoo/odoo/api.py", line 464, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/home/ahmed/odoo/odoo/api.py", line 451, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "<decorator-gen-74>", line 2, in button_immediate_install
File "/home/ahmed/odoo/odoo/addons/base/models/ir_module.py", line 74, in check_and_log
return method(self, *args, **kwargs)
File "/home/ahmed/odoo/odoo/addons/base/models/ir_module.py", line 486, in button_immediate_install
return self._button_immediate_function(type(self).button_install)
File "/home/ahmed/odoo/odoo/addons/base/models/ir_module.py", line 603, in _button_immediate_function
registry = modules.registry.Registry.new(self._cr.dbname, update_module=True)
File "/home/ahmed/odoo/odoo/modules/registry.py", line 87, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/ahmed/odoo/odoo/modules/loading.py", line 474, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/home/ahmed/odoo/odoo/modules/loading.py", line 363, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/ahmed/odoo/odoo/modules/loading.py", line 199, in load_module_graph
registry.init_models(cr, model_names, {'module': package.name}, new_install)
File "/home/ahmed/odoo/odoo/modules/registry.py", line 429, in init_models
model.init()
File "/home/ahmed/odoo/addons/hr_attendance/report/hr_attendance_report.py", line 63, in init
self.env.cr.execute("""
File "<decorator-gen-3>", line 2, in execute
File "/home/ahmed/odoo/odoo/sql_db.py", line 90, in check
return f(self, *args, **kwargs)
File "/home/ahmed/odoo/odoo/sql_db.py", line 311, in execute
res = self._obj.execute(query, params)
Exception
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/ahmed/odoo/odoo/http.py", line 654, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/home/ahmed/odoo/odoo/http.py", line 301, in _handle_exception
raise exception.with_traceback(None) from new_cause
psycopg2.errors.UndefinedFunction: operator does not exist: integer = character varying
LINE 22: ...INNER JOIN hr_employee as employee ON employee.id = employee...
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
```
So explicitly specifying the table name to avoid this issue.
Current behavior before PR:
An Exception is raised during Module installation/upgrade or Upgrading to V15
Desired behavior after PR is merged:
No Confilcts and exceptions raised.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#130974When a customer requests an invoice in the `point_of_sale`, use the same flow as in `account`: the "Send & Print" button. It generates the pdf, the EDI attachments (Factur-X, Peppol Bis 3, etc) and send it to the customers/governement. Indeed, in some countries, it is required to sign the invoice to the government upon validation (e.g. CFDI in Mexico). Forward-Port-Of: odoo/odoo#130931
Original PR description
When a customer requests an invoice in the `point_of_sale`, use the same flow as in `account`: the "Send & Print" button. It generates the pdf, the EDI attachments (Factur-X, Peppol Bis 3, etc) and send it to the customers/governement. Indeed, in some countries, it is required to sign the invoice to the government upon validation (e.g. CFDI in Mexico). Forward-Port-Of: odoo/odoo#130931
When the payment method was detached from the customer, trying to pay with the linked payment token would end up with a crash because Stripe failed to send us the payment intent, as it could not create it. In that case, a logger error occurs on the server which creates noise in the sentry. Error: ``` The creation of the payment intent failed. Stripe gave us the following info about the problem: 'Your card has insufficient funds.' ``` The error occurs from `_stripe_create_payment_int
Original PR description
When the payment method was detached from the customer, trying to pay with the linked payment token would end up with a crash because Stripe failed to send us the payment intent, as it could not…
When the payment method was detached from the customer, trying to pay with the linked payment token would end up with a crash because Stripe failed to send us the payment intent, as it could not create it. In that case, a logger error occurs on the server which creates noise in the sentry. Error: ``` The creation of the payment intent failed. Stripe gave us the following info about the problem: 'Your card has insufficient funds.' ``` The error occurs from `_stripe_create_payment_intent` method https://github.com/odoo/odoo/blob/783998e9a8e92a6225e27f2d77615862c0924bc6/addons/payment_stripe/models/payment_transaction.py#L251-L254 The logger is updated to use the 'warning' level instead of the 'error' level. This change reflects a less severe logging level for cases where the creation of payment intent fails. sentry-4363481906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131113 Forward-Port-Of: odoo/odoo#130802
Prerequisites --> 1) Login with a user with just Inventory/User access rights 2) Product A with purchase policy set to `on ordered quantities` 3) Product category of A set to `AVCO` costing method Steps --> 1) Create+confirm a PO with product A and create and confirm vendor bill 2) Switch to Inventory/User user 3) Try to validate picking 4) Access right error This occurs due to the fact that `Inventory/User` does not have access to `stock.valuation.layer` or `account.move.line
Original PR description
Prerequisites --> 1) Login with a user with just Inventory/User access rights 2) Product A with purchase policy set to `on ordered quantities` 3) Product category of A set to `AVCO` costing method Steps --> 1) Create+confirm a PO with product A and create and confirm vendor bill 2) Switch to Inventory/User user 3) Try to validate picking 4) Access right error This occurs due to the fact that `Inventory/User` does not have access to `stock.valuation.layer` or `account.move.line`. Solution --> Add sudo to the lines where accesses to SVL and invoice lines are made. opw-3357028 Forward-Port-Of: odoo/odoo#129184
PURPOSE ======= Starting from 16.0 we introduced some reports to log skills history, skills evolution. It means that the skill model is linked to another model, preventing us to delete it. Usually, we use the message "link to x, archive it instead", but archiving a skill will only be possible from v17 (new task) So, we need to be able to delete a skill on v16 TaskID: 3456843 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior
Original PR description
PURPOSE ======= Starting from 16.0 we introduced some reports to log skills history, skills evolution. It means that the skill model is linked to another model, preventing us to delete it. Usually, we use the message "link to x, archive it instead", but archiving a skill will only be possible from v17 (new task) So, we need to be able to delete a skill on v16 TaskID: 3456843 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#131158
Usecase to reproduce: - Set operation time base on last workorder - Create 2 MO - On first MO, set 15min as duration - On second MO, set 10min as duration - Validate both MO at the same time - The duraction expected on the operation could be now 10 or 15min It happens because the search in the compute is only base on date. And when both MO are validated at the same time, it's not enough Forward-Port-Of: odoo/odoo#131169
Original PR description
Usecase to reproduce: - Set operation time base on last workorder - Create 2 MO - On first MO, set 15min as duration - On second MO, set 10min as duration - Validate both MO at the same time - The duraction expected on the operation could be now 10 or 15min It happens because the search in the compute is only base on date. And when both MO are validated at the same time, it's not enough Forward-Port-Of: odoo/odoo#131169
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#131066
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#131066
While moving the snippet position, `d-none` gets added which should not. With this PR removes the `cleanForSave` method which applies the `d-none` class. task-3107451 Forward-Port-Of: odoo/odoo#130963 Forward-Port-Of: odoo/odoo#108790
Original PR description
While moving the snippet position, `d-none` gets added which should not. With this PR removes the `cleanForSave` method which applies the `d-none` class. task-3107451 Forward-Port-Of: odoo/odoo#130963 Forward-Port-Of: odoo/odoo#108790
\*: website Some specific media items are meant to be editable even though located in non-editable environments. The typical case in 15.0 is the website "Team" snippet: it is made of multiple bootstrap rows, each containing a column with an image and a column with texts. The columns with the image are only meant to hold that image, it was therefore marked as non editable to prevent users adding text in there by mistake... but the image is still meant to be editable. See [1], later fixed
Original PR description
\*: website Some specific media items are meant to be editable even though located in non-editable environments. The typical case in 15.0 is the website "Team" snippet: it is made of multiple…
\*: website Some specific media items are meant to be editable even though located in non-editable environments. The typical case in 15.0 is the website "Team" snippet: it is made of multiple bootstrap rows, each containing a column with an image and a column with texts. The columns with the image are only meant to hold that image, it was therefore marked as non editable to prevent users adding text in there by mistake... but the image is still meant to be editable. See [1], later fixed by [2]. The problem now is that the system that [2] had to use is quite messy: the column is marked non editable thanks to the `o_not_editable` class but the inner images were to be declared editable via some custom JS method overrides (`_getContentEditableAreas`). The debate about if we should keep a class-based system and/or a method-override system will be left to master. This commit although comes with an uniformisation about this, introducing a new class to declare "an editable media despite its non editable environment". This is not a counter-part of the class `o_not_editable`: we do not want the media to be marked with the `contenteditable` attribute. Indeed, this is actually required since [2] was not enough to solve the problem. See those steps: - Add a company snippet in your page - Change one of the images by an icon - (Save / Reenter edit mode) - Try to change the icon again / edit its options => You can't. Indeed [2] relied on the media being an image to re-enable edition on it... but even if it did not, it would not have been enough. Indeed, icons are forced to being `contenteditable="false"` by the new editor library (since 15.0 then), last update on that at [3]. We thus needed a different way to differentiate editable media, hence the introduction of the new `o_editable_media` class. Note: this system is not perfect, but so is not the whole system about determining what is editable or not at the moment. In this case, it may exist cases of a media marked with the class to be editable but end up in an environment which is not editable by force (xpath somewhere etc) ... and ends up being editable anyway. Most cases work though and at worse it will be about a non editable image being editable but not possible to save in very rare cases. As advertised, the whole system about what is editable or not should be improved. [1]: https://github.com/odoo/odoo/commit/30db617bc8ff7727f40d7ef58c6578e84a13f284 [2]: https://github.com/odoo/odoo/commit/61270ee8bffb6e85f8ff0d19c7a3889fdce2f486 [3]: https://github.com/odoo/odoo/commit/7646429e894f28f398b7b212e893822c06c7b03d task-3226172 Forward-Port-Of: odoo/odoo#130782 Forward-Port-Of: odoo/odoo#118138
Make the footnotes the same width as the report. Show the footnote of a line in a tooltip. Task-id 3438422 Forward-Port-Of: odoo/enterprise#45376
Original PR description
Make the footnotes the same width as the report. Show the footnote of a line in a tooltip. Task-id 3438422 Forward-Port-Of: odoo/enterprise#45376
With an MX company setup Create an invoice Send for validation Create a new bank statement for the invoice without partner Match the statement with the invoice Send the payment for validation Error: Traceback will appear This is caused by the missing partner_id in bank statement move opw-3291289 Forward-Port-Of: odoo/enterprise#44966 Forward-Port-Of: odoo/enterprise#43701
Original PR description
With an MX company setup Create an invoice Send for validation Create a new bank statement for the invoice without partner Match the statement with the invoice Send the payment for validation Error: Traceback will appear This is caused by the missing partner_id in bank statement move opw-3291289 Forward-Port-Of: odoo/enterprise#44966 Forward-Port-Of: odoo/enterprise#43701
When resetting the sort lines to the default order, there was a flickering. This was due to the fact that the previous 'lines_order' was not properly erase from the data, so it was briefly applied before being recalculated. To see the flickering you need to do a full 'sorting cycle' which means that you have to sort 'asc', 'desc' and 'default' and then sort once more. Forward-Port-Of: odoo/enterprise#45416
Original PR description
When resetting the sort lines to the default order, there was a flickering. This was due to the fact that the previous 'lines_order' was not properly erase from the data, so it was briefly applied before being recalculated. To see the flickering you need to do a full 'sorting cycle' which means that you have to sort 'asc', 'desc' and 'default' and then sort once more. Forward-Port-Of: odoo/enterprise#45416
Prevents the text of a button to go on multiple lines. Forward-Port-Of: odoo/enterprise#45049
Original PR description
Prevents the text of a button to go on multiple lines. Forward-Port-Of: odoo/enterprise#45049
Improve the styling of the edit popover. Forward-Port-Of: odoo/enterprise#45018
Original PR description
Improve the styling of the edit popover. Forward-Port-Of: odoo/enterprise#45018
Before this PR, when installing the module. A Traceback could happen if you already have a journal with a code SAL. This PR remove from the demo data the adding of the journal and is replaced by a post init hook to check if the journal is present, if not then add it. In addition, we use the journal for hr_payroll_structure so in the post init hook, we had the journal for the structure that needed it. task-id: 3271099 Forward-Port-Of: odoo/enterprise#45353 Forward-Port-Of: odoo/enterprise#408
Original PR description
Before this PR, when installing the module. A Traceback could happen if you already have a journal with a code SAL. This PR remove from the demo data the adding of the journal and is replaced by a post init hook to check if the journal is present, if not then add it. In addition, we use the journal for hr_payroll_structure so in the post init hook, we had the journal for the structure that needed it. task-id: 3271099 Forward-Port-Of: odoo/enterprise#45353 Forward-Port-Of: odoo/enterprise#40874
__Current behavior before commit:__ When the filter "shift_planned" does not exist (like on odoo.com), the page crashes when a filter is removed from the search bar. The page also crashes when pressing the "Auto Plan" button. __Description of the fix:__ Check if `this._getHighlightPlannedSearchItems()` is not null before retrieving its attributes. __To reproduce:__ On runbot, first remove the "shift_planned" filter in "planning.slot.search" view at line 18. On odoo.com, just go to th
Original PR description
__Current behavior before commit:__ When the filter "shift_planned" does not exist (like on odoo.com), the page crashes when a filter is removed from the search bar. The page also crashes when pressing the "Auto Plan" button. __Description of the fix:__ Check if `this._getHighlightPlannedSearchItems()` is not null before retrieving its attributes. __To reproduce:__ On runbot, first remove the "shift_planned" filter in "planning.slot.search" view at line 18. On odoo.com, just go to the Planning app and remove the default filter. opw-3441371 Forward-Port-Of: odoo/enterprise#45371 Forward-Port-Of: odoo/enterprise#45272
Steps to reproduce: - choose the FTA currency rate - run manually Issue: The rates will be the ones of tomorrow which is not really an issue per se (as we will use the one before for Today's transactions) but can be counterintuitive for the use. Solution: We are fetching the rate of Yesterday. If we are on Monday the 07th of August 2023, the one of Yesterday will be the one released on Friday the 4th of August (valid for following Saturday, Sunday and Monday). It is more intuitive f
Original PR description
Steps to reproduce: - choose the FTA currency rate - run manually Issue: The rates will be the ones of tomorrow which is not really an issue per se (as we will use the one before for Today's transactions) but can be counterintuitive for the use. Solution: We are fetching the rate of Yesterday. If we are on Monday the 07th of August 2023, the one of Yesterday will be the one released on Friday the 4th of August (valid for following Saturday, Sunday and Monday). It is more intuitive for the user to have the "Last Update Date" rate valid for Today's update. Note: FTA rate released on Monday 7th will ba valid for Tuesday 8th and "If no exchange rates were entered for the specified date (weekend, public holidays), the rates entered for the last working day before the specified date will be shown." https://www.rates.bazg.admin.ch/home opw-3379010 Forward-Port-Of: odoo/enterprise#45391 Forward-Port-Of: odoo/enterprise#45364
Issue: ====== When you open a calendar in rental product website , you will see that that day names doesn't correspond to the correct dates. Steps to reproduce the error: ============================= - Install rental, website and ecommerce - Go to rental/products and select one and go to website - Open the calendar and you will see that the dates are shifted by 1 from the day names Origin of the problem : ======================= In this commit https://github.com/odoo/enterprise/co
Original PR description
Issue: ====== When you open a calendar in rental product website , you will see that that day names doesn't correspond to the correct dates. Steps to reproduce the error:…
Issue: ====== When you open a calendar in rental product website , you will see that that day names doesn't correspond to the correct dates. Steps to reproduce the error: ============================= - Install rental, website and ecommerce - Go to rental/products and select one and go to website - Open the calendar and you will see that the dates are shifted by 1 from the day names Origin of the problem : ======================= In this commit https://github.com/odoo/enterprise/commit/ce425b6c808253e77d96977cb62f12c6fedfaa92 the workdays origin was changed from moment to luxon , but luxon considers monday as first day (https://moment.github.io/luxon/docs/class/src/datetime.js~DateTime.html#instance-get-weekdayc first line) .The daterangepicker is heavily dependant on moment and considers that sunday is the first Day, and that's why we see the shift , the real date for example is Sunday but it will be displayed as Monday. Solution: ========= I reverted the changes corrosponding to daysOfWeek and fristDay in that commit. opw-3359579 Forward-Port-Of: odoo/enterprise#45237
Rendering error. t-foreach have duplicate keys. Steps to reproduce the error : 1-install accounting 2-go to accounting/reporting/general ledger 3-select cash 2 and vendor bills 4-try to deselect Cash 2 The reason of this problem is that we create 2 tax_declaration_lines with the same id"tax_decl_head_1" here https://github.com/odoo/enterprise/blob/1b0db69de8f3e2df746a09f2ceb303c8b0f8602c/account_reports/models/account_general_ledger.py#L111-L125 and we assign each item of the for e
Original PR description
Rendering error. t-foreach have duplicate keys. Steps to reproduce the error : 1-install accounting 2-go to accounting/reporting/general ledger 3-select cash 2 and vendor bills 4-try to deselect Cash 2 The reason of this problem is that we create 2 tax_declaration_lines with the same id"tax_decl_head_1" here https://github.com/odoo/enterprise/blob/1b0db69de8f3e2df746a09f2ceb303c8b0f8602c/account_reports/models/account_general_ledger.py#L111-L125 and we assign each item of the for each a key here : https://github.com/odoo/enterprise/blob/1b0db69de8f3e2df746a09f2ceb303c8b0f8602c/account_reports/static/src/components/account_report/account_report.xml#L67 and this is where the error is being raised : https://github.com/odoo/odoo/blob/1039c80a8ff5e219e9c2679505015288c8d8dd35/addons/web/static/lib/owl/owl.js#L4347-L4352 opw-3391482 opw-3441455 opw-3420670 Forward-Port-Of: odoo/enterprise#43609
=== ISSUE === If you navigate to the Helpdesk module dashboard, there is a banner with statistics and state of tickets. Some of these are primary buttons made to access your tickets faster. These `btn-primary` include a `<h2>` tag to make it fill all the available space but this structure also means you need to set a `text-white` to the title to make it white as the other elements inside the button, but doing so, it is not handled when you hover the button etc. === AFTER === We fix
Original PR description
=== ISSUE === If you navigate to the Helpdesk module dashboard, there is a banner with statistics and state of tickets. Some of these are primary buttons made to access your tickets faster. These `btn-primary` include a `<h2>` tag to make it fill all the available space but this structure also means you need to set a `text-white` to the title to make it white as the other elements inside the button, but doing so, it is not handled when you hover the button etc. === AFTER === We fix the structure of the `btn-primary` element to make it easier to control and handle the color of the `<h2>` tag which we turned into a `<span>` element with the same styling as before. task-3455273 part of task-3326263 Forward-Port-Of: odoo/enterprise#45286
Issue: ====== transaction of this months always appears on clicking on other months amount in P&L report for other months when we have this month filter on and comparaison on. Steps to reproduce the error: ============================= - Go to accounting/reporting/Profit and Loss - Select filter as this month - select comparaison and add 3 in 'Number of periods' of 'Pervious period' - Click on amount for some previous month and it will shows transaction for this month Solution: ===
Original PR description
Issue: ====== transaction of this months always appears on clicking on other months amount in P&L report for other months when we have this month filter on and comparaison on. Steps to reproduce the error: ============================= - Go to accounting/reporting/Profit and Loss - Select filter as this month - select comparaison and add 3 in 'Number of periods' of 'Pervious period' - Click on amount for some previous month and it will shows transaction for this month Solution: ========= The value of the key 'column_group_key' was wrong on the call from the js side , it should be the value on the cell and not the value of the first column of the line. opw-3440776 opw-3423204 Forward-Port-Of: odoo/enterprise#45334
The journal should be required for custom providers only if it's sepa, not for cod/transfer. opw-3438006 Forward-Port-Of: odoo/enterprise#45343
Original PR description
The journal should be required for custom providers only if it's sepa, not for cod/transfer. opw-3438006 Forward-Port-Of: odoo/enterprise#45343