Tuesday, November 28, 2023
14 changes · 17.0
Resolved issues and error corrections
Grouped reports now produce drill-down filters that better match what each user is allowed to see. This prevents totals for empty many-to-many fields from linking to incomplete or inconsistent record lists when some related records are hidden by access rights.
Original PR description
\* = test_read_group
Currently, a search with the following domain `[('m2m_field', '=', False)]` will return only the records for which the m2m field is actually empty and not take access rights into account. This means that, for a given user and depending on access rules, `record.m2m_field` can give an empty recordset while a search using the previous domain won't return this record.
This behavior is problematic when such a domain is returned by the read_group. Indeed, when using read_group to group on a m2m field, records for which this m2m field appears empty for the current user will be counted in the column 'False'. However, the domain associated to this column is not always valid, as this m2m field can appear empty for the current user but still have records in it that the current user does not have access to. Such records won't be returned by a search performed using the domain returned by the read_group for the False column.This fix prevents an error when users disable a discussion subscription. The system now keeps the needed display name available, so the action completes smoothly even after the related discussion record is removed.
Original PR description
Before this PR: When a user removes Discussion subtype, the thread is automatically deleted and also its relational field. Subsequently, a getter method responsible for retrieving the name to generate the title fetches it from the 'partner' _field, which is now undefined, leading to a traceback. Desired behaviour after this PR: Saving the 'name' in the state will enable the getter to retrieve the name even after the record is deleted. task-3590756
This fixes cases where changing quantities or splitting draft manufacturing orders could incorrectly advance related stock movements to confirmed. Keeping these movements in draft helps prevent premature workflow steps and ensures multi-step manufacturing processes create the expected pickings.
Original PR description
When changing the demand quantity on a draft picking line or on a production order, the related stock.move that should be in draft will be confirmed. This is because the write function incorrectly calls _recompute_state on draft moves. Also for mrp, using the split function on draft moves will mark the stock.moves of the new production order(s) as confirmed because that's the only state given by _get_backorder_move_vals. Due to that, multisteps mrp wouldn't correctly create pickings since it looks for draft moves. This is also fixed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a problem where links created in the website editor could be redirected incorrectly because the system did not properly recognize secure web addresses. Users can now add links starting with http:// or https:// and have them open as intended.
Original PR description
Description of the issue/feature this PR addresses: Fixes href variable used to construct the link. Resolves #104597 Current behavior before PR: href variable was looking to see if the link started with http:// or https://:// before redirecting to http:// Desired behavior after PR is merged: href variable will correctly verify if the link begins with http:// or https:// and redirect the request accordingly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Danish localization has been updated to align with the Danish government's standardized chart of accounts and the new Danish Bookkeeping Act. This refreshes account mappings and tax setup so Danish businesses can stay compliant in Odoo.
Original PR description
# In General The localization has been redefined as per the standardized chart of accounts from the Danish Government (Erhversstyrelsen):…
# In General The localization has been redefined as per the standardized chart of accounts from the Danish Government (Erhversstyrelsen): https://erhvervsstyrelsen.dk/sites/default/files/2023-02/2023-01-31-Standardkontoplan.xlsx This is unfortunately only defined in Danish so in order to keep features of Odoo where the various parts of the localization are defined in English, I have translated the various Danish text into English and provided as the source and then provided the Danish text as a translation in the CSV-files. Below is an overview of the individual areas with changes as well as some points of consideration in terms of the requirements from the government and how things work in Odoo This PR is a joint operation between us and Odoo S.A. as agreed with Olivier Maessen in order to be compliant with the new Danish Bookkeeping Act ## Chart of Accounts In general the CoA only required some minor adjustments The CoA was reviewed based on the above file using hte sheet named `II) Kontoplan`, where all entries with value in column `B` (`Overskrift`) have been ignored. In most existing Danish Accounting software, the chart of accounts is also what defines the formula for how to P&L report and balance sheet are rendered. This is different in Odoo, since the reports are defined spearately within `odoo/enterprise`. Some accounts have been removed, since the `code` conflicted with some of the above The below shows what accounts are used, but now under different numbers/names Before: ``` 5960 - Accounts receivable 5961 - Accounts receivable (PoS) ``` After: ``` 6190 - Trade and other receivables ``` Before: ``` 7180 - Creditor ``` After: ``` 7440 - Suppliers of goods and services ``` Before: ``` 7681 - Reverse chargeable business tax ``` After: ``` 7680 - Sales tax ``` The internal transfer account is currently set to the prefix of `683`, so this needs to find a new home. A good suggestion would be to have it be `6479` or `6489`, but since we define a prefix and not a specific account, it is hard to lock it to a specific number and there is no gap in the numbering sequence within bank + cash. ## Taxes For taxes there are 69 tax codes that must be possible to handle. While some of the are straight forward, others are more dynamically computed, for which changes in other parts of Odoo might be required first All taxes are defined in the previously linked file on the sheet named `III) Momskoder Bruttoliste`. The following rules have been applied to map the sheet to Odoo: - `Overskrift` -> `description@da_DK` (The english translation is put in ) - `Momskode betegnelse` -> `name` - `Salg/køb` -> `type_tax_use` - `Momskode` -> `id` (Prefixed with `tax_` and the lowercase value of this field) - `Momssats` -> `amount` (The `amount_type` field is set accourding the value here as well as the information from the column `Vejledning`) The column `price_include` is explicitly set to `False` or `True` so that a fallback/default is not used and causing issues in future versions of Odoo in case the default value of the field changes The column `active` is explicitly set to `False` or `True` so that a fallback/default is not used and causing issues in future versions of Odoo in case the default value of the field changes. Here the rule is that if the code is marked with `x` in the column `5. Særkoder` of the above Excel sheet, then the value will be `False`, as the code is then there, but should not be usable out of the box. Customers needing these codes can enable them in relevant companies on their Odoo instance. Codes not marked with `x` in the column `5. Særkoder` will have `True` by default, since they are expected to used by most companies. Upon processing the rules, we found the following tax codes where a challenge is found and that needs handling: `S-DK-25` handles within Denmark regardless of whether we sell products or services. This is fine in terms of taxes and tax reporting, since there are no rules that state a requirement to split these on the tax reporting for the government. It does however give a challenge when handling international sales, since `S-DK-25` has to be mapped to `S-EU-V-0` for products and mapped to `S-EU-Y-0` for services. Odoo has a field called `tax_scope`, which allows us to restrict the usage of taxes based on the product type, but it does not help with the above. To handle this, we create a variation of `S-DK-25` for products and services and then have it use the same account and tax grids. The above also applies for purchases in relation to `K-DK-Fradrag`, where we have done the same variation for `K-EU-V-Fradrag` for products and `K-EU-Y-Fradrag` for services. `S-DK-Brugtmoms` is a special code, as noted by the column `5. Særkoder`. The computation of the tax amount here is based on the following official explanation (translated to English): ``` This code is used for the sale of goods that can be covered by the rules for calculating VAT on used goods and where VAT must therefore be settled on the difference between the selling price and the purchase price. ``` The above means that if purchase a used Meeting table for DKK 1000 and sell it for DKK 2000 a week later, then the taxes are calculated based on what I have earned on this sale. Compute the difference between my purchase and my sale: ``` 2000 - 1000 = 1000 ``` Compute the tax based on the above difference ``` 1000 * 0.25 = 250 ``` When using Odoo inventory management, the above is quite simple when running manual inventory valuation and with standard price. If we however use automated valuation with FIFO, then we need to track each item and these do not always use lot/serial numbers. A way is needed to handle this code in Odoo `S-DK-Marginmoms` is quite similar to `S-DK-Brugtmoms` and has the following official explanation (translated to English): ``` This code is used by travel agencies etc. that have to settle VAT on the profit margin. ``` `S-DK-brugtbil` is also a bit special, as it computes similar to `S-DK-Brugtmoms`. Here is the official explanation (translated to English): ``` This code is used for the sale of used cars, where the seller can make a deduction from the calculated sales tax, on the basis of a calculation based on the purchase price of the used vehicle. ``` `S-Lokalmoms` is quite strange and needs to be handled, but should not go in the tax report. I have set the tax rate to 0, but realistically it must be dynanmic and it is needed to find a way for handling this in Odoo. Here is the official explanation (translated to English): ``` This code is used for sales made in or to customers in other countries where sales are carried out with local VAT. ``` There is also some challenges around `OSS` or One-Stop-Shop taxes in Europe, since special codes are given. I have not defined these as Odoo already has a method of mapping the various taxes from the localization of each country. There are however some requirements for the reporting, which might need to be handled by Odoo. If required we can add the codes, just to ensure that they are there. It is however quite a challenge to get usable responses from the Danish government on how these are supposed to be handled On the purchase side there are also a series of quite special codes, which we do not often see used, but the government does not list these as special codes, so we need a way to handle these in Odoo. `K-DK-SkønsmæssigFradrag` is a special code that needs to reported the same as `K-DK-Fradrag`, but the percentage to be deducted is variable. So the tax rate is still 25 %, but how much of the 25 % can be deducted on our VAT statement is dynamic, based on the following official explanation (translated to English): ``` This code is used for the purchase of goods or services that are used both in connection with the activities subject to VAT and for purposes beyond the company's control and where the right to deduction must be calculated based on an estimate of the actual use. This can, for example, be the acquisition and use of mobile phones, internet access at employees' private addresses and the like. ``` The following taxes are not required to go in the tax report, but it should be possible to find them later for audit: - S-DK-U - S-DK-MF - S-LokalMoms - S-EU-MF - S-%EU-MF - K-DK-IngenFradrag - K-DK-Brugtmoms - K-DK-Marginmoms - K-DK-brugtbil - K-DK-leasingbiler mm - K-EU-Momsfritaget A written guide must be provided for how to find these journal entries or they must somehow be tagged. This PR is a new iteration of #141989 with a few of the previously requested changes from @FlorianGilbert and @RicGR98 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Spanish localization now marks the DUA negative adjustment tax line so it is excluded from Libros exports. This prevents an incorrect -100% line from appearing in tax reporting exports and helps keep Spanish tax submissions accurate.
Original PR description
add l10n_es_type 'ignore' on Subtract Base (DUA) -100% tax so that it can be ignored when creating Libros export enterprise-PR: https://github.com/odoo/enterprise/pull/51366 task-id: 3604971
This update fixes the Twitter social media posting interface by hiding character limit messages after a post is sent and adding proper spacing between icons and text in the posts section. These improvements make the interface cleaner and more polished for users managing their social media accounts.
Original PR description
**Before this PR:** -Message character limits are visible after posting a message on Twitter. -There is no space between globe icon and text in the posts by accounts section. **After this PR:** -Message character limits will be hidden after posting a message on Twitter. -Space will be added between text and globe icon in the posts by accounts section. **Task**-3459739
This fix prevents the spreadsheet application from crashing when a user undoes changes that remove a datasource while the datasource panel is still open. The system now automatically closes the panel when the underlying datasource no longer exists, providing a smoother user experience.
Original PR description
How to reproduce: -Insert a datasource from a standard pivot view - open the corresponding sidepanel (top menu > Data > datasource in question) - undo 2-3 times so that the datasource is no longer in the sheet -> crash Task: 3551443 Forward-Port-Of: odoo/enterprise#49822 Forward-Port-Of: odoo/enterprise#48871
This fix prevents users from merging accounting records in the data cleaning tool, which was causing invoice data to become corrupted. The system now blocks account merges and partner merges when they're linked to locked accounting entries, protecting financial data integrity. Users can still clean up duplicate accounts using safer alternatives like multi-edit and archiving.
Original PR description
Steps to reproduce: - Enable the merge on account.account in data cleaning APP (in debug) - Create an invoice with a receivable account = A - Define a lock date after the invoice date - Go to chart of accounts - Select your receivable = A et receivable = B - Action = Merge accounts where B is the MASTER Issue: Upon revisiting the customer invoice: Notice that the journal items have been updated. Solution: We simply prevent ~~the use of a nuclear weapon~~ the merge of `account.account` as there other possibilities less dangerous such as multi-edit + archiving We also prevent the merge of `res.partner` if this one is used in hashed entries OC: https://github.com/odoo/odoo/pull/134634 opw-3389157 Forward-Port-Of: odoo/enterprise#48761 Forward-Port-Of: odoo/enterprise#47053
The mobile app was crashing when users pressed the back button or used the back gesture on iOS and Android devices. This fix removes outdated code that was causing the crash, allowing the back button to work properly again in the mobile apps.
Original PR description
During the removal of jQuery BBQ library [1], an `Event.getState()` call was unfortunately left. This resulted in a crash when using the device's back button/gesture, which triggers a 'hashchange' event, but only in the mobile apps (iOS and Android). This commit properly converts the related event handling to use the native window.location API. Steps to reproduce: - Open the backend using the mobile app - Go to an app - press the back button/execute the back gesture => error: e.getState is not a function opw-3602245 [1]: odoo/odoo@507c36883675a45a15485ce5c73aa4557ba23639
This update fixes an issue in the Spanish tax reporting export where group taxes (taxes containing multiple child taxes) were not being properly handled, causing inaccurate tax records in exported reports. The fix ensures all child taxes within a group are correctly registered and also improves handling of taxes marked as 'ignore' to exclude them from the export.
Original PR description
When looping over the tax in report line's tax_ids, sometimes the tax we receive is a group tax, which consist of 2 children tax inside it. They all have different id, and that causes the sheet_line_vals dictionary that depend on the id to be inaccurate. This commit register all of the children inside the tax group to the sheet_line_vals, by applying a `flatten_taxes_hierarchy` on the tax_ids This commit also adds an improvement where tax with l10n_es_type of 'ignore' are now ignored (for example: DUA's 'Subtract Base' line), and DUA line should have a type of 'F5' instead in `exp_line_vals` community-PR: https://github.com/odoo/odoo/pull/143314 task-id: 3604971
This fix corrects how the Master Production Schedule (MPS) calculates component demand when products have variants. Previously, when forecasting demand for different product variants with variant-specific components, the system was incorrectly doubling the demand for components in the second variant. Now each variant's components are properly tracked independently, ensuring accurate demand forecasts for manufacturing planning.
Original PR description
MPS does not fully consider product variants.
Steps to reproduce:
- create component 1
- create component 2
- create finished product P, attribute 'version', values 'V1' & 'V2'
- create bill of material for P with lines:
- component 1 applying on variant 'V1'
- component 2 applying on variant 'V2'
- add P - V1 and its bom in MPS
- add P - V2 and its bom in MPS
- set forecasted demand of P - V1 to 10
: indirect demand forecast of component 1 goes to 10
: ok
- set forecasted demand of P - V2 to 10
: indirect demand forecast of component 2 goes to 20
: ! should be 10 !
task: 3556620
Forward-Port-Of: odoo/enterprise#51394Fixed an issue where clicking to review an appointment after creating your first resource-based appointment type would incorrectly create a new appointment instead of opening the existing one. This ensures users can properly review their newly created appointments during the onboarding process.
Original PR description
**Before this PR** Clicking to review an appointment after creating your first resource-based appointment type with onboarding panel still creates a new one. **After this PR** It opens the existing appointment. Task-3503869 Forward-Port-Of: odoo/enterprise#48091
This update fixes a timing issue in the website rental testing process where rental start and end dates could differ when tests run near midnight. The fix ensures both dates are set to the same day, allowing the test to run reliably at any time. This resolves a recurring build failure that was affecting the rental sales feature.
Original PR description
Before this commit, default dates were used for renting. Launching this test just before midnight, start date and end dates are different, although the remaining of the test relies on the fact that hours are defined for the same day. This commit makes sure the renting start date is the same as the end date. Fixes build error 28629