Friday, December 15, 2023
59 changes · master
Security fixes and vulnerability patches
This change lets users and administrators see active login sessions by device details such as fingerprint, IP address, and recent activity. Suspicious or unwanted sessions can be blocked by deleting the related session, helping reduce the risk of account misuse from lost, shared, or compromised devices.
Original PR description
Objective: ---------- A user must be able to see which of his/her sessions are active. Make it easy to block devices (individually or by group) and analyse current sessions. If a user notices unusual…
Objective: ---------- A user must be able to see which of his/her sessions are active. Make it easy to block devices (individually or by group) and analyse current sessions. If a user notices unusual operations concerning him/her on another device, he must be able to stop these operations by blocking the session used by this device. From a technical point of view, a user must be able to block a session linked to an identified device. General: -------- - A device is identified by a static part, the device's fingerprint. - A device is tracked dynamically via its IP address and the timestamp representing its last activity. - A fingerprint is always linked to one and only one session. - A session is linked to at least one device. If a device's fingerprint is modified (for example by a browser update), it will have a new device linked to the session. Consequently, fingerprint tracking does not automatically prevent session theft. If we find an existing fingerprint for a session, we update its dynamic tracking (IP address and last connection). If a device is suspicious (via its static signature and/or dynamic tracking), it is possible to block the session linked to this device. This has the effect of blocking all devices linked to this session, including the current device if it is part of one. The obligation to block the current device, because another device with malicious intent can spoof the fingerprint (and there's no way to differentiate them). Fingerprint: ------------ The purpose of a fingerprint is to identify a device. We use the information collected in the request headers. A `raw_fingerprint` is constructed which is a dictionary in JSON format which respects a specific order (to avoid having two different fingerprints for the same device because of the order of the elements). This `raw_fingerprint` will need to be parsed for easy reading. Note: fingerprint parsing cannot be 100% reliable, but general rules/patterns can be used to gather the relevant information and avoid errors. Example: "User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36" is a Linux OS with a Chrome browser even if "Mozilla" and "Safari" are two words in the header. Note supp: rules and patterns of the fingerprint parser can (must) be improved in the future. Blocking sessions: ------------------ Blocking a session by selecting a device must block the session directly. From an administrator's point of view, if we want to block a session, we expect the session file to be deleted directly from the filesystem. If the session file is no longer present on the filesystem, we can be sure that there is no longer any risk of session usurpation. Note: There are several ways of blocking the session, but this is the safest. Blocking a session based on DB field values does not cover scenarios in which we perform a backup, for example. Find the session file: ---------------------- To find a session file on the filesystem, we need to know the sid of the session (as this is its filename). We don't want to store the sid in the database. However, we can store a part of it with: - a large enough part to be certain of the uniqueness of the session; - a small enough part that we cannot brute force the end of the sid. Browsing the filesystem has a certain performance cost (and can therefore have defects if abused). The proposed solution is to change the granularity of the way we store the session on the filesystem. This means finding a compromise between sub-folders and files per sub-folder to browse for a session file. The sid will be Base64 encoded in order to increase the number of sub-folders and we will have two levels of sub-folders. Note: Encoding the sid in Base64 also extends its length. Update dynamic tracking of devices: ----------------------------------- Updating devices (including creation) take place at the same time as the session refresh in the filesystem. This is done when we are in the `/web` or `/my` route. Delete devices: --------------- We can delete a device at the same time as the linked session is deleted on the filesystem. Task:3627898
This change lets users see their active login sessions and block suspicious devices or sessions. It improves account protection by making it easier to stop unwanted activity from another device without waiting for the session to expire.
Original PR description
Objective: ---------- A user must be able to see which of his/her sessions are active. Make it easy to block devices (individually or by group) and analyse current sessions. If a user notices unusual…
Objective: ---------- A user must be able to see which of his/her sessions are active. Make it easy to block devices (individually or by group) and analyse current sessions. If a user notices unusual operations concerning him/her on another device, he must be able to stop these operations by blocking the session used by this device. From a technical point of view, a user must be able to block a session linked to an identified device. General: -------- - A device is identified by a static part, the device's fingerprint. - A device is tracked dynamically via its IP address and the timestamp representing its last activity. - A fingerprint is always linked to one and only one session. - A session is linked to at least one device. If a device's fingerprint is modified (for example by a browser update), it will have a new device linked to the session. Consequently, fingerprint tracking does not automatically prevent session theft. If we find an existing fingerprint for a session, we update its dynamic tracking (IP address and last connection). If a device is suspicious (via its static signature and/or dynamic tracking), it is possible to block the session linked to this device. This has the effect of blocking all devices linked to this session, including the current device if it is part of one. The obligation to block the current device, because another device with malicious intent can spoof our fingerprint (and there's no way to differentiate them). Fingerprint: ------------ The purpose of a fingerprint is to identify a device. We use the information collected in the request headers. A `raw_fingerprint` is constructed which is a dictionary in JSON format which respects a specific order (to avoid having two different fingerprints for the same device because of the order of the elements). This `raw_fingerprint` will need to be parsed for easy reading. Note: fingerprint parsing cannot be 100% reliable, but general rules/patterns can be used to gather the relevant information and avoid errors. Example: "User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36" is a Linux OS with a Chrome browser even if "Mozilla" and "Safari" are two words in the header. Note supp: rules and patterns of the fingerprint parser can (must) be improved in the future. Blocking sessions lazily: ------------------------- Blocking a session by selecting a device must not browse the filesystem to find the session file and delete it. Blocking a session must ensure that the next request linked to this session is blocked. An invalid session is detected if its access token (in the filesystem) is not the one calculated by the server (see `_compute_session_token` method). Note: The result of this calculation is cached (LRU) and it is therefore necessary to clear the cache when it needs to be recalculated. The result is that if, for a given session, the key used to calculate its HMAC is changed, the session will be automatically invalidated by the current session mechanism. We therefore need a boolean key (which is True by default) that detects whether at least one device has been blocked for the current session. If this is the case, the session must be invalidated. SID ---> KEY X + KEY device (`True` according to all devices linked to SID) ---> HMAC A SID ---> KEY X + KEY device (`False` according to all devices linked to SID) ---> HMAC B >< HMAC A ---> invalid session The boolean value is stocked in a field that tells whether the devices are active or not. It is therefore necessary to be able to find all the devices linked to a SID. Using the SID's sha256 directly makes it easy to link a device to an SID without any security problems. This ensures we have a perfect match in the device - SID relationship. Update dynamic tracking of devices: ----------------------------------- Device updates (including creation) take place at the same time as the session refresh in the filesystem. This is done when we are in the `/web` route. Delete devices: --------------- We can delete a device at the same time as a session is deleted on the filesystem. If a session no longer exists on the filesystem, it is impossible to usurp it, so devices linked to this session no longer need to be tracked. With the session's sha256, we can find all devices we need to delete. opw-3627898
Enhancements to existing features
French customer and company records now show localized registry labels, using SIRET/SIREN terminology where relevant. This makes French legal identifiers clearer on records, invoices, and company document layouts, reducing ambiguity for users handling French accounting documents.
Original PR description
Adds a way to have dynamic fields label based on the record country_id field. This will be used in l10n_fr to have the company_registry field named SIREN if the partner or company has its address in France. task id #2827661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes how Odoo calculates certain percentage-based taxes used in Brazilian accounting, especially when taxes are included in the displayed price. Businesses using these tax rules should see more accurate invoice and order totals, reducing accounting errors and manual corrections.
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
Features or functions removed from Odoo
This change removes old compatibility code from the web interface that was only needed for legacy behavior. It helps keep the codebase simpler and easier to maintain, with minimal expected impact for business users.
Original PR description
This commit remove use less code compatibility for legacy code. 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
Miscellaneous changes
### Summary Currently, the 'Total amount of invoice in letters' setting doesn't do anything on GCC invoices. ### Steps to reproduce * install `l10n_sa` * enable the Arabic language * in the settings, enable 'Total amount of invoice in letters' * create and print an invoice You should see that the amount in words in not displayed. Note: Currently, currency labels are not translatable. Since this isn't something that can be changed in stable version, it was decided (after discus
Original PR description
### Summary Currently, the 'Total amount of invoice in letters' setting doesn't do anything on GCC invoices. ### Steps to reproduce * install `l10n_sa` * enable the Arabic language * in the settings, enable 'Total amount of invoice in letters' * create and print an invoice You should see that the amount in words in not displayed. Note: Currently, currency labels are not translatable. Since this isn't something that can be changed in stable version, it was decided (after discussing it with JCO) to not include them in the Arabic amount in words. opw-3501112 opw-3485691 Forward-Port-Of: odoo/odoo#143578
This update removes an unnecessary database step during system initialization. It slightly streamlines internal startup/setup work without changing how users interact with Odoo.
Original PR description
The SQL query removed in this revision is no longer useful since the revision: https://github.com/odoo/odoo/commit/92be431236bd93054c5134cb0d4daf8124918e39#diff-3350ff6a7375591a483754ef9f4718e5fadb298b4c605ee016154ec8bef1e074L57
This update improves how Odoo chooses new accounting codes so they stay consistent with local chart of accounts rules and avoid odd or overly long codes. It also lets EU OSS tax reporting use dedicated existing accounts, such as Germany's OSS accounts, instead of creating unnecessary duplicates.
Original PR description
### Context While doing the balancing of the Balance Sheets, I found that: 1. some OSS accounts were being created with non-sensical account codes (e.g. in Lithuania, the OSS account is created with…
### Context
While doing the balancing of the Balance Sheets, I found that:
1. some OSS accounts were being created with non-sensical account codes (e.g. in Lithuania, the OSS account is created with code 4402 whereas the basic VAT Payable account has code 4492),
2. some CoAs already have a dedicated account for OSS (e.g. Germany should use account 1767 for OSS), but we create a new one.
### Problem 1: non-sensical account codes
At heart, this is due to the implementation of `_search_new_account_code`. What it should do, is start with the given `prefix`, expand it to `digits`, and increment it until an available code is found.
However, this is not what `_search_new_account_code` does at the moment: if `len(prefix) == digits`, it truncates the last digit of `prefix`, then appends 1, 2, 3, ... until an available code is found.
This behaviour is unwanted for two reasons:
- Firstly, if `prefix` ends with a different digit than `0` or `1`, we want to only try codes higher than `prefix`.
- Secondly, the resulting code may exceed the expected number of digits passed to it. This was ruled by TSB as something that should be avoided, due to constraints on the length of codes in some countries (e.g. limited to 8 in Germany).
We therefore change the behaviour of `_search_new_account_code` to the following:
1. _search_new_account_code now takes an argument `start_code`, which is a code to start incrementing from, instead of `prefix` and `digits`.
2. We check whether `start_code` is available; if not, we increment it until an available code is found. The incrementation works by regexing an integer at the end of the `start_code` string, and incrementing it without increasing the length of the code.
3. If, due to non-numeric characters in the code, the incrementation fails, or if no codes are available, we fallback to `'{start_code}.copy'`, `'{start_code}.copy2'`, etc.
Because `_search_new_account_code` is used to create new account codes when loading CoA templates, this change in behaviour (in particular, ensuring that the generated code has the specified number of digits) requires us as well to fix too-low values of the `code_digits` property on CoA templates.
I also note that while the implementation of `AcccountAccount.copy()` does not currently use `_search_new_account_code`, we could consider using it at some point.
### Problem 2: CoAs that already provide an OSS account
We need a way to specify an existing account from the CoA if there is one dedicated for OSS. For this, I've just added the CoA accounts directly in the `l10n_eu_oss` module, as I didn't think providing a prefix in each localization's template was needed. However, if that's considered better, I'm open to the change.
Enterprise PR: https://github.com/odoo/enterprise/pull/48066
taskids: 3521121, 3523224Discuss sidebar categories can now be managed through mail records instead of a fixed registry. This makes it easier to introduce or adjust categories dynamically, including for live chat, while aligning the implementation with the rest of Discuss.
Original PR description
Before this PR, a registry was used to list the categories shown in the discuss sidebar. This can be done easily with mail records instead. Doing so will allow to add new categories dynamically. Moreover, this is more consistent with the discuss code base. part of task-3640730 enterprise: https://github.com/odoo/enterprise/pull/52873
WhatsApp conversation categories in Discuss can now be managed through mail records instead of a fixed registry. This makes it easier to add new sidebar categories over time and keeps the feature aligned with the rest of Discuss.
Original PR description
Before this PR, a registry was used to list the categories shown in the discuss sidebar. This can be done easily with mail records instead. Doing so will allow to add new categories dynamically. Moreover, this is more consistent with the discuss code base. part of task-3640730 enterprise: https://github.com/odoo/odoo/pull/146451
Austrian financial reports now use account codes instead of optional account tags, reducing the risk of missing or inaccurate figures when tags are absent. The balance sheet also calculates profit and loss automatically, improving consistency without relying on specific account setup.
Original PR description
Replace the tags_id used in domains in the financial reports by the account ids. Tags ids are not required and could be missing on accounts, using account ids helps to have financial reports staying as correct as possible. Also change the balance sheet so that it automatically calculate the p&l balance instead of relying on specific accounts for it. Task id #2612900
The update limits certain Mexico-specific invoice fields so they are only saved for invoices created by Mexican companies. This keeps invoice records cleaner and avoids storing irrelevant localization data for companies outside Mexico.
Original PR description
Change two fields on account moves to only store values for invoices created with an MX company. Task id # 2715634
Pinterest shares now use the image of the product variant selected by the shopper, such as the black desk instead of the default white desk. This makes shared product links more accurate and improves the customer experience when promoting products on social media.
Original PR description
Steps to reproduce the issue fixed by this commit: - Go on /shop - Click on the Customizable Desk product - Click on the Black variant - Share the product on Pinterest => The image shared is the white desk instead of the black one. This commit updates the image shared to the one of the variant. Unfortunatly, for other social networks, we can't use the variant image because they don't take an image/media parameter in their sharer url. They simply crawl the page and take the image in the meta tag and our JS code can't change this meta tag dynamically. The server cannot know which variant is selected because it's in the fragments part of the url. task-3485494
This fix stops Odoo from saving the open or folded state of live chat windows that are temporary or about to be closed. It prevents errors when visitors fold a new chat before sending a message and avoids unnecessary server updates during chat closure.
Original PR description
Since [1], the fold state of the live chat is stored on the server. However, this save is also done for temporary live chats (that are not saved on the server). As a consequence, an error occurs when a user folds a chat window before posting any message. Steps to reproduce the issue: - Open a live chat - Send a message - Close the live chat - Open another live chat - Fold the chat window - An error occurs Another undesirable save is triggered when the chat window opens to show the feedback panel: the live chat is about to be discarded so saving the state is not required. Steps to reproduce the issue: - Open a live chat - Send a message - Fold the chat window - Click on close - The chat window opens and the "open" state is saved on the server. This PR fixes both issues. [1]: https://github.com/odoo/odoo/pull/145905
This fix ensures certain Brazilian taxes included in the price are calculated from the correct total amount. It prevents incorrect tax values in accounting, reconciliation, and localized point-of-sale or e-invoicing flows where division-style taxes apply.
Original PR description
The current tax engine doesn't work with division taxes because the tax amounts must be computed on the price included amount but can't be on the price excluded one. Unfortunately, the current engine is finding first the price excluded amount before computing "really" the tax amounts. It means, 20% division price included on 100 should be computed as: 100 * 0.2 = 20 However, when trying to compute the tax amount on 100 - 20 = 80, we are not able to retrieve the original tax amount of 20. opw: 3443703
Accounting localization tests were updated to match the corrected way new account codes are generated when accounts are copied. This keeps automated checks reliable across country-specific reports and expense scenarios without changing business workflows.
Original PR description
Since we have fixed the behaviour of _search_new_account_codes, which is now used by account.copy(), we also need to adjust the account codes expected by tests that use account.copy() to generate a new account. Community PR: https://github.com/odoo/odoo/pull/136707 taskid:3521121
Currently, if you switch to a right-to-left language and open the POS, the numpad will look like this: 3 2 1 6 5 4 9 8 7 The numpad should stay the same even in RTL languages: 1 2 3 4 5 6 7 8 9 opw-3623228 Forward-Port-Of: odoo/odoo#146181 Forward-Port-Of: odoo/odoo#145886
Original PR description
Currently, if you switch to a right-to-left language and open the POS, the numpad will look like this: 3 2 1 6 5 4 9 8 7 The numpad should stay the same even in RTL languages: 1 2 3 4 5 6 7 8 9 opw-3623228 Forward-Port-Of: odoo/odoo#146181 Forward-Port-Of: odoo/odoo#145886
To reproduce ============ - Create a meeting activity from any document (for example CRM opportunity) with a calendar. - It will create a meeting in the calendar. - Now, mark as done the activity created and it will delete the meeting from the calendar too. revert of https://github.com/odoo/odoo/pull/144526 opw-3626773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146288
Original PR description
To reproduce ============ - Create a meeting activity from any document (for example CRM opportunity) with a calendar. - It will create a meeting in the calendar. - Now, mark as done the activity created and it will delete the meeting from the calendar too. revert of https://github.com/odoo/odoo/pull/144526 opw-3626773 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146288
When a page is reloaded with the chat bot, it sometimes restarts from the beginning. This commit ensures the chatbot starts where it left after a page reload. Forward-Port-Of: odoo/odoo#146175
Original PR description
When a page is reloaded with the chat bot, it sometimes restarts from the beginning. This commit ensures the chatbot starts where it left after a page reload. Forward-Port-Of: odoo/odoo#146175
Before this commit, the default update_path even if the field was readonly, it weas returned. So, if you try to create an automated action on the stock.move.line model and try to add an action, the button return a traceback because the field is readonly. After this commit, the method that get the default update_path will also check if the field is not readonly. Bugfix Task-Id: 3624328 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior
Original PR description
Before this commit, the default update_path even if the field was readonly, it weas returned. So, if you try to create an automated action on the stock.move.line model and try to add an action, the button return a traceback because the field is readonly. After this commit, the method that get the default update_path will also check if the field is not readonly. Bugfix Task-Id: 3624328 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#146166
__Current behavior before commit:__ `_compute_meeting` computes the meetings linked to the children of the partners in `self`. To do so, it first retrieves all children partners of `self`, then it loops through all of them to apply the meetings to the parents. This way of doing is inefficient because it is useless to iterate over the children that don't have any meetings. This can be particularly annoying if there is a partner that is a big company with 100k+ children partners. If this co
Original PR description
__Current behavior before commit:__ `_compute_meeting` computes the meetings linked to the children of the partners in `self`. To do so, it first retrieves all children partners of `self`, then it…
__Current behavior before commit:__ `_compute_meeting` computes the meetings linked to the children of the partners in `self`. To do so, it first retrieves all children partners of `self`, then it loops through all of them to apply the meetings to the parents. This way of doing is inefficient because it is useless to iterate over the children that don't have any meetings. This can be particularly annoying if there is a partner that is a big company with 100k+ children partners. If this company apperas in the res.partner kanban view, it will load for several minutes even when there is no partner with a meeting. __Description of the fix:__ Optimize `_compute_meeting` by looping through the partners that have a meetings instead of all children partners. __Benchmark:__ | len(all_partners) | w/o fix | with fix | | ----------------- | ------- | -------- | | 1k | 111 ms | 19 ms | | 150k | > 3 min | 1.82 s | opw-3511371 Forward-Port-Of: odoo/odoo#145545 Forward-Port-Of: odoo/odoo#137279
Steps to reproduce: - Install Accounting and l10n_sa_edi - Create a retention tax: (e.g. "Retention Tax 10%") * Amount: [a negative amount] (e.g. -10.00%) * Is Retention: [checked] (in "Advanced Options" tab) - Create an invoice with the following invoice line: * Product: [any] * Price: 1000 * Taxes: "Sales Tax 15%" and "Retention Tax 10%" - Confirm the invoice - Print the invoice => On the invoice, there is a "VAT Amount" field that should show the amount coming from the
Original PR description
Steps to reproduce: - Install Accounting and l10n_sa_edi - Create a retention tax: (e.g. "Retention Tax 10%") * Amount: [a negative amount] (e.g. -10.00%) * Is Retention: [checked] (in "Advanced…
Steps to reproduce: - Install Accounting and l10n_sa_edi - Create a retention tax: (e.g. "Retention Tax 10%") * Amount: [a negative amount] (e.g. -10.00%) * Is Retention: [checked] (in "Advanced Options" tab) - Create an invoice with the following invoice line: * Product: [any] * Price: 1000 * Taxes: "Sales Tax 15%" and "Retention Tax 10%" - Confirm the invoice - Print the invoice => On the invoice, there is a "VAT Amount" field that should show the amount coming from the taxes that are not Retention taxes as it is done in the EDI invoice (XML). However, the Retention tax is subtracted. In our example: - Tax amount for "Sales Tax 15%" is 150.00 - Tax amount for "Retention Tax 10%" is -100.00 => The "VAT Amount" field of the invoice line is 50.00. It should be 150.00 instead. Solution: Compute the "VAT Amount" field as it is done in the EDI invoice. opw-3568831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145039
In this pr we remove the blank choice in the self-ordering mode select. It's unnecessary and throws a validation error on saving settings. Task 3599144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142351
Original PR description
In this pr we remove the blank choice in the self-ordering mode select. It's unnecessary and throws a validation error on saving settings. Task 3599144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142351
Purpose: - Changed the default value of 'Show In Preference' (is_public) field from true to false for preventing the automatic publishing of mailing lists. Task-3594678 Forward-Port-Of: odoo/odoo#144699
Original PR description
Purpose: - Changed the default value of 'Show In Preference' (is_public) field from true to false for preventing the automatic publishing of mailing lists. Task-3594678 Forward-Port-Of: odoo/odoo#144699
Step to reproduce: - Go to Website Editor - Add a block like Text-Image - Change the Font Color for the title to a "Gradient" - Add an icon in the title -> The icon is not displayed on iphone Note that it was probably working with commit [1] but not anymore with commit [2]. [1]: https://github.com/odoo/odoo/commit/187acb938f70a2130d25fa76079221339c742f1e [2]: https://github.com/odoo/odoo/commit/372eeebb47b93890d567185879981e817cdc1326 opw-3614325 | Before | after | | - | - | |
Original PR description
Step to reproduce: - Go to Website Editor - Add a block like Text-Image - Change the Font Color for the title to a "Gradient" - Add an icon in the title -> The icon is not displayed on iphone Note that it was probably working with commit [1] but not anymore with commit [2]. [1]: https://github.com/odoo/odoo/commit/187acb938f70a2130d25fa76079221339c742f1e [2]: https://github.com/odoo/odoo/commit/372eeebb47b93890d567185879981e817cdc1326 opw-3614325 | Before | after | | - | - | |  |  | Forward-Port-Of: odoo/odoo#146117
Before this commit and since commit [1], it was possible to clone a page in the page list view. It shouldn't be the case, cloning a page lead to bad result: a page with the same URL which is not shown in the page list view because pages are filtered by URL to remove duplicates. Cloning a page has always had to be done through the page properties > "clone page" button. Doing it this way will ask the user for a new page name (and so a new url). The page will then correctly be listed. [1]: h
Original PR description
Before this commit and since commit [1], it was possible to clone a page in the page list view. It shouldn't be the case, cloning a page lead to bad result: a page with the same URL which is not shown in the page list view because pages are filtered by URL to remove duplicates. Cloning a page has always had to be done through the page properties > "clone page" button. Doing it this way will ask the user for a new page name (and so a new url). The page will then correctly be listed. [1]: https://github.com/odoo/odoo/commit/3192051806e0da1276604a31ad818f8768105362 opw-3591738 Forward-Port-Of: odoo/odoo#146173
[Commit 1] made sure the history worked when resizing elements by calling `odooEditor.automaticStepUnactive()`, but applied its counterpart `automaticStepActive()` only at the very end of the action, leaving some `return` statements on the way that could break the flow. This commit calls `automaticStepActive` just before leaving the listener and moves `automaticStepUnactive` just before the first DOM modification. It's both more logical and avoids returns pitfalls. Note: `automaticSte
Original PR description
[Commit 1] made sure the history worked when resizing elements by calling `odooEditor.automaticStepUnactive()`, but applied its counterpart `automaticStepActive()` only at the very end of the action, leaving some `return` statements on the way that could break the flow. This commit calls `automaticStepActive` just before leaving the listener and moves `automaticStepUnactive` just before the first DOM modification. It's both more logical and avoids returns pitfalls. Note: `automaticStepActive()` makes sure modifications made on the DOM through the browser's developer tools are tracked and can be reversed with the undo button. Not reactivating it in time means some flows could be broken (until another method reactivates it). [Commit 1]: https://github.com/odoo/odoo/commit/423f4bd2a6cc47e69699d2437eaa5acda94bb98d Related to task-3576046 Forward-Port-Of: odoo/odoo#146249 Forward-Port-Of: odoo/odoo#145623
Before this commit the clean_assetbundle could unlink invalid attachment, mostly when generating a no website assetbundle with a different version than a website one, the website assetbundle will be deleted. ``` Generating a new asset bundle attachment /web/assets/439-b4c80c3/1/web.assets_frontend.min.css (id:439) Generating a new asset bundle attachment /web/assets/440-3723971/web.assets_frontend.min.css (id:440) Deleting attachments [439] (matching /web/assets/%-%/web.assets_frontend.m
Original PR description
Before this commit the clean_assetbundle could unlink invalid attachment, mostly when generating a no website assetbundle with a different version than a website one, the website assetbundle will be…
Before this commit the clean_assetbundle could unlink invalid attachment, mostly when generating a no website assetbundle with a different version than a website one, the website assetbundle will be deleted. ``` Generating a new asset bundle attachment /web/assets/439-b4c80c3/1/web.assets_frontend.min.css (id:439) Generating a new asset bundle attachment /web/assets/440-3723971/web.assets_frontend.min.css (id:440) Deleting attachments [439] (matching /web/assets/%-%/web.assets_frontend.min.css) because it was replaced with /web/assets/%-3723971/%%% ``` The issue is that `%-%/` will match `439-b4c80c3/1/` and not only `439-b4c80c3/` Note that it looks like this issue existed for a while but was invisible because before 16.4 clean_attachment was invalidating the ormcache, hiding the fact that a still valid asset was deleted and regenerated. The proposed fix replaces the domain with `%-_______/`. The unique is always 7 character long. Note that this change was already made in 17.0 when removing the id from the asset url so this doesn't need to be completely forward-ported. A self.clean_attachments(extension) is also added when copying an assets because this was cleaned by side effect before. (to check) opw-3558552 Forward-Port-Of: odoo/odoo#145452 Forward-Port-Of: odoo/odoo#144515
Problem --------- In most cases, default deferred accounts and journal need to be set up for localizations. This is normally done in the enterprise report module for that localization. However, in some cases, the localization does not have special report formats. In such situation, a localization report module that sets up very few default values for the data company is defined. This is way overkill. Objective --------- Allow the community company template to have 'unknown fields' de
Original PR description
Problem --------- In most cases, default deferred accounts and journal need to be set up for localizations. This is normally done in the enterprise report module for that localization. However, in…
Problem --------- In most cases, default deferred accounts and journal need to be set up for localizations. This is normally done in the enterprise report module for that localization. However, in some cases, the localization does not have special report formats. In such situation, a localization report module that sets up very few default values for the data company is defined. This is way overkill. Objective --------- Allow the community company template to have 'unknown fields' defined. Doing so, allows for the default deferred accounts and journal to be defined without entreprise module to exists. Currently, this raises an error. Solution --------- In the pre-processing of the chart template values, we skip all the keys in the company data that are not company fields. We add a context value which, when True, revert that behavior back to before this commit and checks that all fields in the company template are actual company fields (this will be used in the standalone test for l10n modules). We also update the standalone test for l10n modules so that: 1. it reports errors in all l10n modules at once. 2. it uses the context value described above and checks that all fields in the company chart template are correct company field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#138937
The issue: having 2 invoices with different customer, each customer has a different language, the 'Unaxed amount' string will get translated into the first language of the first invoice partner. The fix: including the customer language in the context opw-3569173 Forward-Port-Of: odoo/odoo#145420 Forward-Port-Of: odoo/odoo#143321
Original PR description
The issue: having 2 invoices with different customer, each customer has a different language, the 'Unaxed amount' string will get translated into the first language of the first invoice partner. The fix: including the customer language in the context opw-3569173 Forward-Port-Of: odoo/odoo#145420 Forward-Port-Of: odoo/odoo#143321
Before this commit, when many channels were pinned in Discuss, the messaging menu took a while to open and render all items. This happens because `fetchPreviews()` and `inbox.fetchNewMessages()` were inserting data for each thread and message. This meant computed and sorted fields were called with that many objects. This commit improves the performances by wrapping all of it in an update cycle transaction, so that computed and sorted fields are invoked only once at the end of the update cy
Original PR description
Before this commit, when many channels were pinned in Discuss, the messaging menu took a while to open and render all items. This happens because `fetchPreviews()` and `inbox.fetchNewMessages()` were inserting data for each thread and message. This meant computed and sorted fields were called with that many objects. This commit improves the performances by wrapping all of it in an update cycle transaction, so that computed and sorted fields are invoked only once at the end of the update cycle. With `contacts` installed, populate `medium`: - Before this commit: 1min. - With this commit: 2sec. (30x faster) Forward-Port-Of: odoo/odoo#145980
Steps to reproduce: - Install Accounting, Sales & Purchase - Go to "Settings / Users & Companies / Companies" - Create a branch company (e.g. Branch Company) for a company (e.g. YourCompany) - Switch to Branch Company - Go to Sales (or Purchase) - Create a SO (or PO) - Add a SO line (or PO line) and try to select a tax => Taxes from the parent company are not available in Sales and Purchase as they are in Accounting opw-3604981 opw-3636972 --- I confirm I have signed t
Original PR description
Steps to reproduce: - Install Accounting, Sales & Purchase - Go to "Settings / Users & Companies / Companies" - Create a branch company (e.g. Branch Company) for a company (e.g. YourCompany) - Switch to Branch Company - Go to Sales (or Purchase) - Create a SO (or PO) - Add a SO line (or PO line) and try to select a tax => Taxes from the parent company are not available in Sales and Purchase as they are in Accounting opw-3604981 opw-3636972 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146384 Forward-Port-Of: odoo/odoo#146325
Before this commit, attempting to do `self.env['calendar.event'].write({'partner_ids': [0, 1, 2]})` would give a traceback as the method that updates attendees only supports parsing commands, not ids. This is a problem as that method is called from 'write' and other methods with the assumption that partner_ids can only contain commands. This will not be the case when using a gantt view and grouping by partner_ids for example, and cannot be worked around. task-3452277 --- I confirm
Original PR description
Before this commit, attempting to do
`self.env['calendar.event'].write({'partner_ids': [0, 1, 2]})` would give a traceback as the method that updates attendees only supports parsing commands, not ids.
This is a problem as that method is called from 'write' and other methods with the assumption that partner_ids can only contain commands.
This will not be the case when using a gantt view and grouping by partner_ids for example, and cannot be worked around.
task-3452277
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#146161Current behavior: When a reward is applied on an order containing different product with different taxes, the rewarded is divided in multiple lines (one per tax) This cause issue when calling, the `_updateRewardLines` method. Because it will consider each line as a full reward, and therefore will apply the reward multiple times even though the reward is only applied once. Steps to reproduce: - Create a reward with a discount of 5$ in exchange of 100 points - The reward should give 1 point
Original PR description
Current behavior: When a reward is applied on an order containing different product with different taxes, the rewarded is divided in multiple lines (one per tax) This cause issue when calling, the `_updateRewardLines` method. Because it will consider each line as a full reward, and therefore will apply the reward multiple times even though the reward is only applied once. Steps to reproduce: - Create a reward with a discount of 5$ in exchange of 100 points - The reward should give 1 point per 1$ spent - Create a product with a price of 100$ and a tax of 10% - Create a product with a price of 100$ and no tax - Open the POS and add the 2 products to the order - Select a customer, and click the reward button - The reward will be applied 2 times (4 reward lines are created) opw-3583174 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145759 Forward-Port-Of: odoo/odoo#142738
When a line with a factor_percent of -100 is applied in the tax, it should be subtracted from the ImporteTotal. This way, we might think that the total of the invoice should do, but we need the amount before application of the withholdings. And in the case of DUA it should be the sum of base and tax. 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 guid
Original PR description
When a line with a factor_percent of -100 is applied in the tax, it should be subtracted from the ImporteTotal. This way, we might think that the total of the invoice should do, but we need the amount before application of the withholdings. And in the case of DUA it should be the sum of base and tax. 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#143204
[FIX] web_editor: make loadImageInfo() robust to protocol relative URLs Steps to reproduce: - Add a "Text-Image" on the website. - Replace the image by one of your own. - Save. - With the html editor, remove the `mimetype` attribute, the `data-original-src` attribute and change the `src` of the picture into the corresponding protocol-relative one. The `src` then looks like "//domain/web/image/...". - Save the modifications of the html editor. - Enter in edit mode. - Click on the ima
Original PR description
[FIX] web_editor: make loadImageInfo() robust to protocol relative URLs Steps to reproduce: - Add a "Text-Image" on the website. - Replace the image by one of your own. - Save. - With the html…
[FIX] web_editor: make loadImageInfo() robust to protocol relative URLs Steps to reproduce: - Add a "Text-Image" on the website. - Replace the image by one of your own. - Save. - With the html editor, remove the `mimetype` attribute, the `data-original-src` attribute and change the `src` of the picture into the corresponding protocol-relative one. The `src` then looks like "//domain/web/image/...". - Save the modifications of the html editor. - Enter in edit mode. - Click on the image. -> It is now impossible to change options such as `Filter`, `Width` and `Quality`. Because the `data-original-src` attribute was removed from the image, the system tries to add it back thanks to the `loadImageInfo()` logic. Because the `src` attribute of the image is now a protocol relative url, `new URL(src)` will raise an error and the logic will use this url as argument for the `/web_editor/get_image_info` route. Because the url given in argument of the rpc call is not the relative one, the system fails to find the original attachment. The `mimetype` attribute is therefore not added back on the image, leading to the impossibility to change some options. To solve the problem, this commit modifies a bit [this commit]. In order to be robust to absolute, relative and protocol relative URLs, an URL object is first created from the image src. The relative URL (`.pathname`) of the URL object is then used to retrieve the original attachment linked to the image. Let's synthesize the different `relativeSrc` obtained with different image src. In the following examples, "https://test.com/blog/travel-1" will be used as `img.ownerDocument.defaultView.location.href`. (the complete URL of the document in which the image is located). - `src` is an absolute URL (e.g. "https://test.com/web/image/697-d0f2aaf8/shoes.jpg"). In this case, `relativeSrc` = "/web/image/697-d0f2aaf8/shoes.jpg". - `src` is a relative URL that begins with a slash (e.g. "/web/image/697-d0f2aaf8/shoes.jpg"). This URL represents an absolute path starting from the root of the domain. In this case, `relativeSrc` = "/web/image/697-d0f2aaf8/shoes.jpg". - `src` is a relative URL that does not begin with a slash (e.g. "web/image/697-d0f2aaf8/shoes.jpg"). The interpretation of this URL depends on the current location. In this case, `relativeSrc` = "/blog/web/image/697-d0f2aaf8/shoes.jpg". - `src` is a protocol relative URL (e.g. "//test.com/web/image/697-d0f2aaf8/shoes.jpg"); there is only the protocol missing. In this case, `relativeSrc` = "/web/image/697-d0f2aaf8/shoes.jpg". This solution takes the advantage of the second argument of the `URL()` constructor which is used if the first parameter is a relative or protocol relative URL and which is ignored if the first parameter is an absolute URL. This commit does not only modify [this commit] to handle more types of URLs but also: - To avoid having to use `.split()`. Indeed, `.pathname` does not include query parameters. - To avoid having to consider an error raised by `new URL()` as a normal flow. Indeed, in [this commit], an error would be intercepted by the `catch` if `src` was a relative URL. This was a legitimate flow. The problem was that other unwanted types of src (for example protocol relative URL) were also raising errors but were silently ignored (as intercepted in the `catch`). [this commit]: https://github.com/odoo/odoo/commit/89c14783846288a2de53f6258a93440e02550b13 task-3623731 Forward-Port-Of: odoo/odoo#146238 Forward-Port-Of: odoo/odoo#144731
This commit add a new delay_type that will add to the date the nb_days then go the end of the month and finally add a new field called days_next_month. This field is a Char because we want the field to be of size 2. Also, we added a constraint that this field must be numeric and between 0 and 31. ex of use with Invoice date the 25/11/2023, if we have a payment term with 90 for the nb_days and 10 for the days_next_month: - +90 days = 23/02/2024 - End of month = 29/02/2024 - +10 days = 10
Original PR description
This commit add a new delay_type that will add to the date the nb_days then go the end of the month and finally add a new field called days_next_month. This field is a Char because we want the field to be of size 2. Also, we added a constraint that this field must be numeric and between 0 and 31. ex of use with Invoice date the 25/11/2023, if we have a payment term with 90 for the nb_days and 10 for the days_next_month: - +90 days = 23/02/2024 - End of month = 29/02/2024 - +10 days = 10/03/2024 task: 3609320 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143758
Before this commit and since PR [1], the default "checked" value set on checkboxes field on the form snippet were lost once the page is saved. This is because [1] changed the rendering engine of qweb templates from our own qweb js rendering code to owl templates rendering. By doing so, `t-att-checked="'checked'"` would toggle the "internal" checkbox checked value but would not add the checked attribute on the element. It's a deliberate choice made in owl. As the checked attributed does not
Original PR description
Before this commit and since PR [1], the default "checked" value set on checkboxes field on the form snippet were lost once the page is saved. This is because [1] changed the rendering engine of qweb…
Before this commit and since PR [1], the default "checked" value set on checkboxes field on the form snippet were lost once the page is saved. This is because [1] changed the rendering engine of qweb templates from our own qweb js rendering code to owl templates rendering. By doing so, `t-att-checked="'checked'"` would toggle the "internal" checkbox checked value but would not add the checked attribute on the element. It's a deliberate choice made in owl. As the checked attributed does not mean the same as the internal checked value, it makes sense. Indeed, the checked attribute is about the default value of the checkbox while the checked internal value is about the current checked state of the checkbox. In React, for instance, the same behavior can be seen. And if one wants to really set the checked attribute, they got to go with `defaultChecked`. Same apply with `value`. Maybe owl will implement the same `defaultXXX` behavior in the future as it's something that was already discussed on their side. [1]: https://github.com/odoo/odoo/pull/130467 Forward-Port-Of: odoo/odoo#146328
Since [this other commit], we add ZWS characters to the edges of links. Unfortunately, this breaks the label option of the link tools that has been introduced in [this commit]. Steps to reproduce the issue: - Go to website - Edit a page - Click on the contact us button in the header - Using the label option of the link tools, delete the final character => Nothing happens. The final character is not deleted as expected. [this other commit]: https://github.com/odoo/odoo/commit/ab40
Original PR description
Since [this other commit], we add ZWS characters to the edges of links. Unfortunately, this breaks the label option of the link tools that has been introduced in [this commit]. Steps to reproduce the issue: - Go to website - Edit a page - Click on the contact us button in the header - Using the label option of the link tools, delete the final character => Nothing happens. The final character is not deleted as expected. [this other commit]: https://github.com/odoo/odoo/commit/ab40f484d55e151e175ccf9d6b3ea3bf34c56b35 [this commit]: https://github.com/odoo/odoo/commit/75166dbcd4962f30624fe19829757acbf8e76022 Related to runbot-44779 Forward-Port-Of: odoo/odoo#146361 Forward-Port-Of: odoo/odoo#145770
To reproduce ============ - go on any record with list view (for example a Quotation) - Check many hidden fields in the list view to show them - The dialogue box for checking and unchecking hidden fields moves with the horizontal scrollbar, sometimes even going off screen. Problem ======= the position of the dropdown menu is computed using the position of the toggler butoon, so if this button moves the menu moves with it Solution ======== make the toggler button sticky so it's alwa
Original PR description
To reproduce ============ - go on any record with list view (for example a Quotation) - Check many hidden fields in the list view to show them - The dialogue box for checking and unchecking hidden fields moves with the horizontal scrollbar, sometimes even going off screen. Problem ======= the position of the dropdown menu is computed using the position of the toggler butoon, so if this button moves the menu moves with it Solution ======== make the toggler button sticky so it's always visible and the dropdown menu will keep same position. opw-3589726 Forward-Port-Of: odoo/odoo#145784 Forward-Port-Of: odoo/odoo#144368
This commit correctly aligns certain header elements when the CTA button has a larger vertical padding. Steps to reproduce the issue: - Install 'eCommerce' on your website. - In Website edit mode, click on the 'THEME' tab. - Adjust the vertical padding of buttons to 25px. - Click on the header in the page. - In the 'STYLE' tab, select the 'Menu - Sales 1' header. - Bug: The 'logo" and the 'menu items' are not aligned with the CTA button. - In the 'STYLE' tab, select the 'Menu - Sales
Original PR description
This commit correctly aligns certain header elements when the CTA button has a larger vertical padding. Steps to reproduce the issue: - Install 'eCommerce' on your website. - In Website edit mode,…
This commit correctly aligns certain header elements when the CTA button has a larger vertical padding. Steps to reproduce the issue: - Install 'eCommerce' on your website. - In Website edit mode, click on the 'THEME' tab. - Adjust the vertical padding of buttons to 25px. - Click on the header in the page. - In the 'STYLE' tab, select the 'Menu - Sales 1' header. - Bug: The 'logo" and the 'menu items' are not aligned with the CTA button. - In the 'STYLE' tab, select the 'Menu - Sales 2' header. - Bug: The 'menu items' are not aligned with the CTA button. - In the 'STYLE' tab, select the 'Menu - Sales 4' header. - Bug: Bug: The 'cart' button is not aligned with the CTA button. task-3478334 ------------- - **Menu - Sales 1** header _Before_  _After_  ------------- - **Menu - Sales 2** header _Before_  _After_  ------------- - **Menu - Sales 4** header _Before_  _After_  Forward-Port-Of: odoo/odoo#145230
Steps to reproduce [1]: - Go to website (blog post page) > Change the layout of the cover (Customize > 'Regular' Cover). - Click on the cover (in edit mode) > You can type anything inside and use the text tools (E.g. if you add an image from the toolbar, it will be added on all blog posts). Steps to reproduce [2]: - Go to website (`/calendar` page) > Unpublish an appointment page. - Go back to the `/calendar` page > Switch to edit mode > You still can edit the "unpublished" ta
Original PR description
Steps to reproduce [1]: - Go to website (blog post page) > Change the layout of the cover (Customize > 'Regular' Cover). - Click on the cover (in edit mode) > You can type anything inside and use the…
Steps to reproduce [1]: - Go to website (blog post page) > Change the layout of the cover (Customize > 'Regular' Cover). - Click on the cover (in edit mode) > You can type anything inside and use the text tools (E.g. if you add an image from the toolbar, it will be added on all blog posts). Steps to reproduce [2]: - Go to website (`/calendar` page) > Unpublish an appointment page. - Go back to the `/calendar` page > Switch to edit mode > You still can edit the "unpublished" tag on the items cover (add text, images,... using text tools). The editor uses some methods (`getContentEditableAreas()`, `getReadOnlyAreas()`,...) to check if an area should be marked as editable on load, there is already a cover selector used to define a record cover as an editable zone, but this selector is targeting the whole element, leading to the behaviour described in [1] & [2]. We actually just need to set the savable content (usually the record `name` and `subtitle` fields) as editable and not the whole element. The goal of this commit is to fix this behaviour by removing the cover along with its descendants from the initial editable zones (especially to prevent the scenario in [2], see: `$editableSavableZones`) and only setting the savable fields as editable areas. opw-3561659 Forward-Port-Of: odoo/odoo#146038 Forward-Port-Of: odoo/odoo#144391
Snailmail letters failed to fail in newer version of Odoo starting from saas-16.2. The cause is a report attachment was supplied at the creation of the letter, preventing the snailmail module to generate its own report with its custom CSS. Said CSS was also rewritten to be clearer and to fix the follow up report's broken snailmail layout. Forward-Port-Of: odoo/odoo#145368
Original PR description
Snailmail letters failed to fail in newer version of Odoo starting from saas-16.2. The cause is a report attachment was supplied at the creation of the letter, preventing the snailmail module to generate its own report with its custom CSS. Said CSS was also rewritten to be clearer and to fix the follow up report's broken snailmail layout. Forward-Port-Of: odoo/odoo#145368
Since PR odoo/odoo/pull/124068, the browser history back no longer works correctly when navigating from the home menu to applications. It requires two history backs instead of one. Why: Two pushStates are performed on the router, the first to add the menu_id and the second to apply the action associated with the menu. These two pushStates are not in the same setTimeout, which causes two changes to the url. So two entries in the browser history . Solution: We perform the two pushStates in
Original PR description
Since PR odoo/odoo/pull/124068, the browser history back no longer works correctly when navigating from the home menu to applications. It requires two history backs instead of one. Why: Two…
Since PR odoo/odoo/pull/124068, the browser history back no longer works correctly when navigating from the home menu to applications. It requires two history backs instead of one.
Why:
Two pushStates are performed on the router, the first to add the menu_id and the second to apply the action associated with the menu. These two pushStates are not in the same setTimeout, which causes two changes to the url. So two entries in the browser history .
Solution:
We perform the two pushStates in the same setTimeout. This causes only one url modification and therefore one entry in the browser history.
How to reproduce:
- Go to the home menu
- Click on the app A
- Return to the home menu using the toggle menu
- Click on the app B
- Perform a history back
- The home menu is displayed
- Perform a history back
Before this commit:
The home menu is still displayed
After this commit:
The app A is displayed.
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#146143
Forward-Port-Of: odoo/odoo#146095**steps to reproduce:** - configure your POS with anglosaxon accounting and "Update quantities in stock" at session closing and enable "Use QR code on ticket" - open the POS, sell a storable product and close the session - scan the QR code on the ticket to create an invoice - check the pickings on the session form view **before this commit:** - 2 pickings are created, one at session closing and one from the invoice **after this commit:** - if the session is closed, do not create a ne
Original PR description
**steps to reproduce:** - configure your POS with anglosaxon accounting and "Update quantities in stock" at session closing and enable "Use QR code on ticket" - open the POS, sell a storable product and close the session - scan the QR code on the ticket to create an invoice - check the pickings on the session form view **before this commit:** - 2 pickings are created, one at session closing and one from the invoice **after this commit:** - if the session is closed, do not create a new picking opw-3592418 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146077 Forward-Port-Of: odoo/odoo#145473
Since PR odoo/odoo/pull/124068, the browser history back no longer works correctly when navigating from the home menu to applications. It requires two history backs instead of one. Why: Two pushStates are performed on the router, the first to add the menu_id and the second to apply the action associated with the menu. These two pushStates are not in the same setTimeout, which causes two changes to the url. So two entries in the browser history . Solution: We perform the two pushStates in
Original PR description
Since PR odoo/odoo/pull/124068, the browser history back no longer works correctly when navigating from the home menu to applications. It requires two history backs instead of one. Why: Two…
Since PR odoo/odoo/pull/124068, the browser history back no longer works correctly when navigating from the home menu to applications. It requires two history backs instead of one.
Why:
Two pushStates are performed on the router, the first to add the menu_id and the second to apply the action associated with the menu. These two pushStates are not in the same setTimeout, which causes two changes to the url. So two entries in the browser history .
Solution:
We perform the two pushStates in the same setTimeout. This causes only one url modification and therefore one entry in the browser history.
How to reproduce:
- Go to the home menu
- Click on the app A
- Return to the home menu using the toggle menu
- Click on the app B
- Perform a history back
- The home menu is displayed
- Perform a history back
Before this commit:
The home menu is still displayed
After this commit:
The app A is displayed.
Forward-Port-Of: odoo/enterprise#52697
Forward-Port-Of: odoo/enterprise#526831. Add a falsy default value for capacity If asked_capacity is not set (coming back from further step) use a '-' option by default, not showing any time slots until a capacity is selected. This way, that number must be knowingly selected, preventing booking for 1 without noticing, as this was the default value, missing this choice. 2. Give title of questions more space Introduced in 4f68079b535c1ea54c42ae8dabae903f88d6e87f, all the questions have their labels inlined with the in
Original PR description
1. Add a falsy default value for capacity If asked_capacity is not set (coming back from further step) use a '-' option by default, not showing any time slots until a capacity is selected. This way,…
1. Add a falsy default value for capacity If asked_capacity is not set (coming back from further step) use a '-' option by default, not showing any time slots until a capacity is selected. This way, that number must be knowingly selected, preventing booking for 1 without noticing, as this was the default value, missing this choice. 2. Give title of questions more space Introduced in 4f68079b535c1ea54c42ae8dabae903f88d6e87f, all the questions have their labels inlined with the input areas. The same is true for the 'text' question, despite having the textarea displayed on next line. Therefore we have only a small width given to title, despite having the whole line available. Make it use the available space. Also, align the textarea with the rest of the form. For the custom questions, show answers on next line to give full line width to their title. 3. Add a spinner for time slots As the time slots can take a while to compute and update, we add a spinner to indicate that the slots are yet to be updated. When capacity is enabled, '-' option is considered as missing data, therefore it will not show the spinner as no slots should be displayed. Only show the spinner when a day is selected, too. 4. Adapt restaurant demo data Adapt slots of Table Booking appointment to match restaurant-like hours: bookable every 30 mins, open between wednesday and sunday included at night, and with a lunch service at noon on wednesday and on the weekend. Also update the duration of the appointment to 2 hours. Add a question on dietary preferences. Call the location to Bistr-Odoo and make it a company. Also, for other demo data types in the appointment module, set videoconference link to False. Task-3593599 Forward-Port-Of: odoo/enterprise#50729
Currently, if one tries to audit a cell that has no lines to audit two things can break: - auditaction.help is displayed even if it's undefined, resulting in `undefined` text being displayed - certain manual values traceback because fetchone returns None and we trying to access the contents of it This commit fixes it by: - extending external domain with record_ids only if we get some when fetching - only showing no content help if there is one While external domain for auditing could b
Original PR description
Currently, if one tries to audit a cell that has no lines to audit two things can break: - auditaction.help is displayed even if it's undefined, resulting in `undefined` text being displayed - certain manual values traceback because fetchone returns None and we trying to access the contents of it This commit fixes it by: - extending external domain with record_ids only if we get some when fetching - only showing no content help if there is one While external domain for auditing could be fixed back to 16.0, it doesn't seem to be necessary: we start allowing auditing cells with no lines only from saas-16.4 and we have the first report with various formats of external values in 17.0. Forward-Port-Of: odoo/enterprise#52826
**To reproduce:** - Create and confirm 81 MOs - Open the shop floor **Current behavior:** 80 MOs shown due to a limit on the amount fetched from the backend. **Expected behavior after this PR is merged:** 81 MOs shown as the limit is increased to a maximal amount. opw-3605494 Forward-Port-Of: odoo/enterprise#52820 Forward-Port-Of: odoo/enterprise#52777
Original PR description
**To reproduce:** - Create and confirm 81 MOs - Open the shop floor **Current behavior:** 80 MOs shown due to a limit on the amount fetched from the backend. **Expected behavior after this PR is merged:** 81 MOs shown as the limit is increased to a maximal amount. opw-3605494 Forward-Port-Of: odoo/enterprise#52820 Forward-Port-Of: odoo/enterprise#52777
The Balance Sheet was missing report lines specifically for Previous Year Earnings and Current Year Earnings. This commit creates two new report lines under Equity to represent them. In addition, the transfer accounts 88 and 89 that are for setting the Income / Expense accounts to zero at year end are now referenced in the Balance Sheet rather than in the Profit and Loss. They should not affect the Profit and Loss since they should normally only be used in the FY closing entry. Finally, ac
Original PR description
The Balance Sheet was missing report lines specifically for Previous Year Earnings and Current Year Earnings. This commit creates two new report lines under Equity to represent them. In addition, the transfer accounts 88 and 89 that are for setting the Income / Expense accounts to zero at year end are now referenced in the Balance Sheet rather than in the Profit and Loss. They should not affect the Profit and Loss since they should normally only be used in the FY closing entry. Finally, account 835 Tax Cost was not referenced in the Profit and Loss, so we added it. This ensures that the Balance Sheet is balanced, according to the test in https://github.com/odoo/enterprise/pull/36838. taskid: 3060790 Forward-Port-Of: odoo/enterprise#52749 Forward-Port-Of: odoo/enterprise#52157
Before this commit, when a payment link was used to partially pay a renewal subscription in order to confirm it, a token was set at the confirmation of the renewal. The consequence of this is that we receive a partial payment and then the remaining amount. We want to save the token only if the subscription is fully paid. After this commit, when confirming a renewal subscription, the token is only saved if the sum of partial payments equal the total amount of the subscription. This way the inv
Original PR description
Before this commit, when a payment link was used to partially pay a renewal subscription in order to confirm it, a token was set at the confirmation of the renewal. The consequence of this is that we receive a partial payment and then the remaining amount. We want to save the token only if the subscription is fully paid. After this commit, when confirming a renewal subscription, the token is only saved if the sum of partial payments equal the total amount of the subscription. This way the invoice cron won't charge the total amount on the token. Ticket-id: 3499685 Forward-Port-Of: odoo/enterprise#52728 Forward-Port-Of: odoo/enterprise#52554
Problem --------- In most cases, default deferred accounts and journal need to be set up for localizations. This is normally done in the enterprise report module for that localization. However, in some cases, the localization does not have special report formats. In such situation, a localization report module that sets up very few default values for the data company is defined. This is way overkill. Objective --------- Allow the community company template to have 'unknown fields' de
Original PR description
Problem --------- In most cases, default deferred accounts and journal need to be set up for localizations. This is normally done in the enterprise report module for that localization. However, in some cases, the localization does not have special report formats. In such situation, a localization report module that sets up very few default values for the data company is defined. This is way overkill. Objective --------- Allow the community company template to have 'unknown fields' defined. Doing so, allows for the default deferred accounts and journal to be defined without enterprise module to exists. Currently, this raises an error. Solution --------- Update the `post_init_hook` in `account_accountant` so that it reloads the values for deferred accounts/journal that are defined in the community company templates. Forward-Port-Of: odoo/enterprise#50305
xx = pk,pt,se Problem --------- In 15.1, the financial reports where upgraded to a new version where we can directly indent children line inside parents. Some reports are missing that upgrade. Objective --------- Those reports should be converted. Solution --------- Apply the new formatting of the report in the XML definition using the children_ids and line_ids tags. Remove the parent_id and financial_report_id that are now unnecessary. Target is 16.0 because a refactoring of acc
Original PR description
xx = pk,pt,se Problem --------- In 15.1, the financial reports where upgraded to a new version where we can directly indent children line inside parents. Some reports are missing that upgrade. Objective --------- Those reports should be converted. Solution --------- Apply the new formatting of the report in the XML definition using the children_ids and line_ids tags. Remove the parent_id and financial_report_id that are now unnecessary. Target is 16.0 because a refactoring of account reports occurred in 16.0. The only version that will miss the upgrade is saas-15.2. task-3508362 Forward-Port-Of: odoo/enterprise#52658 Forward-Port-Of: odoo/enterprise#52506
In PR #47198 some field entries were removed from some expression records in the XML. This leads to problem with upgrade since only "positive changes" (values that occur in the XML) are written to the DB. Values that are absent are not set to False or to their default. This was corrected in this commit. A somewhat special case are the 'domain_formula' fields; they create expressions. Setting their value to False explictly unlinks the associated expressions. Reproduce (leftover subformula
Original PR description
In PR #47198 some field entries were removed from some expression records in the XML. This leads to problem with upgrade since only "positive changes" (values that occur in the XML) are written to…
In PR #47198 some field entries were removed from some expression records in the XML.
This leads to problem with upgrade since only "positive changes" (values that occur in the XML) are written to the DB. Values that are absent are not set to False or to their default. This was corrected in this commit.
A somewhat special case are the 'domain_formula' fields; they create expressions. Setting their value to False explictly unlinks the associated expressions.
Reproduce (leftover subformula causing traceback in P&L)
1. Check out commit fc8a6c8344f95b20947188f341b16a648cdd1433 (last commit before PR #47198)
2. Start and install l10n_at_reports
4. Check out commit before this commit
5. Start with -u l10n_at_reports
6. AT profit & loss
7. Traceback
Reproduce (for domain_formula)
1. Check out commit fc8a6c8344f95b20947188f341b16a648cdd1433 (last commit before PR #47198)
2. Start and install l10n_at_reports
3. Check Accounting -> Configuration -> Accounting Reports
-> Bilanzdarstellung nach § 224 UGB (AT)
-> 4. sonstige Forderungen und Vermögensgegenstände
4. Check out commit before this commit
5. Start with -u l10n_at_reports
6. Check again: Accounting -> Configuration -> Accounting Reports
-> Bilanzdarstellung nach § 224 UGB (AT)
-> 4. sonstige Forderungen und Vermögensgegenstände
There are 2 expressions now but there should be just 1 (the one from step 3 should be gone now)
Forward-Port-Of: odoo/enterprise#52709Make the 'Allow partial' checkbox invisible if the wizard is opened with one and only one line. It doesn't make sense to have partials on a single line since for now the amount of the write-off is not editable/customizable (that will change in master). task-id: opw-3490136 Forward-Port-Of: odoo/enterprise#52774 Forward-Port-Of: odoo/enterprise#51815
Original PR description
Make the 'Allow partial' checkbox invisible if the wizard is opened with one and only one line. It doesn't make sense to have partials on a single line since for now the amount of the write-off is not editable/customizable (that will change in master). task-id: opw-3490136 Forward-Port-Of: odoo/enterprise#52774 Forward-Port-Of: odoo/enterprise#51815
When doing the fw-port of adding a 'Not Started' column [1] to version 17.0 [2], we added the possibility to audit that column as well. However in doing so, adding a new parameter `filter_not_started` to the `_get_domain` method, we forgot to adapt one method call to include that paramater, causing clicking the caret action in the report to fail. In order to fix the issue and simplify things, the parameters `filter_already_generated` and `filter_not_started` get a default value of `False`
Original PR description
When doing the fw-port of adding a 'Not Started' column [1] to version 17.0 [2], we added the possibility to audit that column as well. However in doing so, adding a new parameter `filter_not_started` to the `_get_domain` method, we forgot to adapt one method call to include that paramater, causing clicking the caret action in the report to fail. In order to fix the issue and simplify things, the parameters `filter_already_generated` and `filter_not_started` get a default value of `False` now, and the method calls are adapted accordingly. _Bug reported by RIGR_ [1] 563404395c96650b871e293509af77acc811a7ff [2] b3eaaa55b4550f1fefbd6dd472d9e8b8c4d21384 Forward-Port-Of: odoo/enterprise#52760
In the field service task when we create a new task through quick create view, the project_id field is there that shows the current project and through the project sharing, customer and worksheet template fields are not visible when the project is "field services". this PR ensures that when the field services project is there, customers and worksheet template fields are visible in the quick create view and hide the project_id field. task-3247213 Forward-Port-Of: odoo/enterprise#52539 Forw
Original PR description
In the field service task when we create a new task through quick create view, the project_id field is there that shows the current project and through the project sharing, customer and worksheet template fields are not visible when the project is "field services". this PR ensures that when the field services project is there, customers and worksheet template fields are visible in the quick create view and hide the project_id field. task-3247213 Forward-Port-Of: odoo/enterprise#52539 Forward-Port-Of: odoo/enterprise#39539
Currently if you group the gantt view on calendar events by partner_ids you get a traceback because we try calling a method that is not named properly. As the intended feature is not supported and we don't expect anybody to have been using the method nor is it used anywhere internally we remove both the python method that should have been called and its caller in js. It was a remnant of trying to make grouping by partner_ids the default Which ended up being scrapped except for this
Original PR description
Currently if you group the gantt view on calendar events by partner_ids you get a traceback because we try calling a method that is not named properly. As the intended feature is not supported and we don't expect anybody to have been using the method nor is it used anywhere internally we remove both the python method that should have been called and its caller in js. It was a remnant of trying to make grouping by partner_ids the default Which ended up being scrapped except for this part. Although it is being reestablished in 17.0 and up with this task task-3452277 Forward-Port-Of: odoo/enterprise#52702
Before this commit, a warning is raised at the end of `industry_fsm_tour` tour because it ignores the last step because it is auto action. This commit adds `run` attribute in the last to trigger click event to avoid considering the last step has `auto`. runbot-24582 Forward-Port-Of: odoo/enterprise#52655 Forward-Port-Of: odoo/enterprise#51610
Original PR description
Before this commit, a warning is raised at the end of `industry_fsm_tour` tour because it ignores the last step because it is auto action. This commit adds `run` attribute in the last to trigger click event to avoid considering the last step has `auto`. runbot-24582 Forward-Port-Of: odoo/enterprise#52655 Forward-Port-Of: odoo/enterprise#51610