Thursday, October 3, 2024
8 changes · saas-17.4
Resolved issues and error corrections
The attendance kiosk now refreshes the displayed date automatically instead of keeping the date from when the screen was first opened. This prevents employees from seeing an outdated date if the kiosk remains open overnight.
Original PR description
Problem: The current date in the kiosk view remains static, as `now` is initialized when the component is rendered and does not update. The date should dynamically refresh by calling `DateTime.now()` at regular intervals. Steps to reproduce: - Open the attendance kiosk view. - Wait until the next day. - The displayed date does not update automatically. opw-4199136 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
# Global context: TSB, LZZ, THBE and me (BIB) had a very long meeting to find out what would be the better the solution to allow a UK company to use the OSS tax system with Belgium as its entry point. The UK company has a wharehouse in Belgium and thus needs to report anything coming out of that wharehouse to the on the Belgian VAT report and the "Belgian" OSS tax report. It also needs to invoice any Belgian with the Belgian taxes and VAT (and thus can't use OSS for that one). Some of
Original PR description
# Global context: TSB, LZZ, THBE and me (BIB) had a very long meeting to find out what would be the better the solution to allow a UK company to use the OSS tax system with Belgium as its entry…
# Global context: TSB, LZZ, THBE and me (BIB) had a very long meeting to find out what would be the better the solution to allow a UK company to use the OSS tax system with Belgium as its entry point. The UK company has a wharehouse in Belgium and thus needs to report anything coming out of that wharehouse to the on the Belgian VAT report and the "Belgian" OSS tax report. It also needs to invoice any Belgian with the Belgian taxes and VAT (and thus can't use OSS for that one). Some of their product might be purely Belgian and thus only have a Belgian tax set on them. We thus need to support both the mapping from the motherland UK and from Belgium. The following are required: - Creating the Belgian VAT taxes. - Creating the OSS taxes as they would be for a Belgian company. - Create the fiscal position mapping from Belgian tax to EU taxes. - Create the fiscal position mapping from UK to EU taxes. The main goal of the task is to: - be able to instantiate OSS on a specific branch: we go from the current one up and we instantiate OSS to the first one with a TAX ID. - we should be able to use the classic OSS tag as usually. - be able to report those numbers in the OSS tax report. ## [IMP] l10n_eu_oss: OSS on first branch with a TAX ID The aim of this commit is to allow to instanciate OSS on the first branch having a tax id instead of always instanciating OSS on the root company. ### Context: The end goal is to allow to instanciate OSS for a company outside EU and let it use sub branch to manage the tax mapping. ### Previous to this commit: OSS taxes gets installed automatically on all companies when loading a chart template or installing the OSS modules. OSS taxes and fiscal position are always setup on the root company. ### After this commit: OSS taxes never gets installed automatically when loading a chart template or installing the OSS module. OSS taxes and fiscal position are setup on the first sub branch having a TAX ID. task: no task ## [IMP] l10n_eu_oss: OSS on EU branch ### The aim of this commit is to: allow non EU countries to have an EU branch with an EU VAT number that can have both the taxes for that specific country and the OSS taxes mapped from that country to the other EU countries. For that branch to be able to see the OSS tax report, we have to be able to set the fiscal_country_id as an EU one. It also needs to be able to instantiate the EU tax from that country. To allow that, we need a foreign VAT fiscal position. In order to do that, we had to remove the constraint that prevent to have both a foreign vat fpos and the fiscal_country_id to be set on the same country and same vat number. task: None ## [IMP] l10n_eu_oss: allow to map allow available taxes + add UK tax ma… …pping ### The aim of this commit is to: - add the mapping from UK to other EU taxes for OSS. - make the mapping between all available tax that wouldn't have been created by the OSS feature ### Previous to this commit: - UK taxes couldn't be mapped automatically - taxes from the parent companies aren't mapped automatically ### After this commit: - UK taxes are mapped automatically - taxes from the parent companies are mapped automatically task: None ## [FIX] l10n_eu_oss: avoid between oss taxes together The aim of this commit is to avoid oss taxes to be mapped one to another. ### Context: During the refactoring of the chart_template in 5125748 , changing the module name for the search was forgotten. ### Previous to this commit: When you refresh the taxes several time, some oss taxes will be mapped to some other in some fiscal position. ### After this commit: OSS taxes mapped together shouldn't happen anymore. Enterprise PR: https://github.com/odoo/enterprise/pull/71006 task: no-task Forward-Port-Of: odoo/odoo#182023 Forward-Port-Of: odoo/odoo#181954
Some project tours rely on the milestones feature being enabled. While this is the case when demo data are installed, it's not when they aren't, and the tours fail. To solve this issue, and prevent future ones from being created, this PR enables the feature before each tour. Task-4132639 Forward-Port-Of: odoo/odoo#178168
Original PR description
Some project tours rely on the milestones feature being enabled. While this is the case when demo data are installed, it's not when they aren't, and the tours fail. To solve this issue, and prevent future ones from being created, this PR enables the feature before each tour. Task-4132639 Forward-Port-Of: odoo/odoo#178168
Close https://github.com/odoo/odoo/issues/181546 * Wrong dict comprehension format, should be {key: value for ...} instead of {(key, value) for ....} 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#182223 Forward-Port-Of: odoo/odoo#181956
Original PR description
Close https://github.com/odoo/odoo/issues/181546
* Wrong dict comprehension format, should be {key: value for ...} instead of {(key, value) for ....}
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#182223
Forward-Port-Of: odoo/odoo#181956Before this commit, two inheritance of hr.employee.base were done inside the hr_holidays module. This commit merges both inheritance in the hr_employee_base.py file Forward-Port-Of: odoo/odoo#181261 Forward-Port-Of: odoo/odoo#181129
Original PR description
Before this commit, two inheritance of hr.employee.base were done inside the hr_holidays module. This commit merges both inheritance in the hr_employee_base.py file Forward-Port-Of: odoo/odoo#181261 Forward-Port-Of: odoo/odoo#181129
Description of the issue this commit addresses: Branches companies are not allowed to export to XML the OSS reports while this is a use case that should be allowed for specific scenarios. --- Desired behavior after this commit is merged: The XML export button is usable by any branch company. --- Community PR: https://github.com/odoo/odoo/pull/181954 task: no-task Forward-Port-Of: odoo/enterprise#71011 Forward-Port-Of: odoo/enterprise#71006
Original PR description
Description of the issue this commit addresses: Branches companies are not allowed to export to XML the OSS reports while this is a use case that should be allowed for specific scenarios. --- Desired behavior after this commit is merged: The XML export button is usable by any branch company. --- Community PR: https://github.com/odoo/odoo/pull/181954 task: no-task Forward-Port-Of: odoo/enterprise#71011 Forward-Port-Of: odoo/enterprise#71006
For all 17.0 databases of a specific partner (strangely it couldn't be reproduced on runbot), the fsm catalog view was used to select product on sale order lines in mobile view. This commit ensures that this custom view will only be used for the specific action using it and won't appear in other places. opw-4196351 Forward-Port-Of: odoo/enterprise#71297
Original PR description
For all 17.0 databases of a specific partner (strangely it couldn't be reproduced on runbot), the fsm catalog view was used to select product on sale order lines in mobile view. This commit ensures that this custom view will only be used for the specific action using it and won't appear in other places. opw-4196351 Forward-Port-Of: odoo/enterprise#71297
Before this commit, the div was addded for additional condition for button visibility which causing button asymtry and cropping button. after this commit, moved visibility condition in invisible attribute of button. Forward-Port-Of: odoo/enterprise#70551
Original PR description
Before this commit, the div was addded for additional condition for button visibility which causing button asymtry and cropping button. after this commit, moved visibility condition in invisible attribute of button. Forward-Port-Of: odoo/enterprise#70551