Search
Navigate
Branch
Thursday, October 3, 2024
27 changes
5 changes
Miscellaneous changes
Steps to reproduce: - Download payroll and Time off - Time Off > Configuration > Time off types - In Paid and unpaid type, set 'Take Time Off in' to Hours - Employees > Pick one > Time off - Click calendar day and create 2 leaves: -- Paid type, Custom hours from 8:00 to 9:00 -- Unpaid type, Custom hours from 9:00 o 10:00 - Time off > Management > Time off - Approve and validate both leaves - The employee needs to have a running contract so if needed -- Payroll > Contracts > Contra
Original PR description
Steps to reproduce: - Download payroll and Time off - Time Off > Configuration > Time off types - In Paid and unpaid type, set 'Take Time Off in' to Hours - Employees > Pick one > Time off - Click…
Steps to reproduce: - Download payroll and Time off - Time Off > Configuration > Time off types - In Paid and unpaid type, set 'Take Time Off in' to Hours - Employees > Pick one > Time off - Click calendar day and create 2 leaves: -- Paid type, Custom hours from 8:00 to 9:00 -- Unpaid type, Custom hours from 9:00 o 10:00 - Time off > Management > Time off - Approve and validate both leaves - The employee needs to have a running contract so if needed -- Payroll > Contracts > Contracts > New - Payroll > Regenerate work entries for your employee - Leaves are generated as a single block of type 'Generic time off' The leaves are merged. The Interval class sorts its entries' boundaries in such a way that it will see the start of an entry before the stop of the previous one if the start/stop time are the same. Its counterpart WorkIntervals does not merge overlapping entries. i.e with entries 8:00-9:00 and 9:00-10:00 Intervals will interpret as: 8:00 start, 9:00 start, 9:00 stop, 10:00 stop => Merged entries. And WorkIntervals as: 8:00 start, 9:00 stop, 9:00 start, 10:00 stop => No merged entries. This happens regardless of the content of the merged resources, in this case two different types of leaves which should not be treated the same by nature (Paid/Unpaid). When going though the leaves, we currently loop over the associated work intervals, this is part of the reason several leaves are processed as a single interval. The only reason we need the attendance interval is because some work entry types can take precedence over leaves (For instance a long term medical disability must supercede a public holiday). In the interest of avoiding a change in the return type of the method '_get_interval_leave_work_entry_type' we instead rebuild the intervals with the bounds of the leave and the work entry type of the attendance. opw-4193334 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182273
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#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#181956# 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#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
## Before this commit The Reseller field was visible on the sales order but not the invoice. Although the field existed on the invoice, it wasn't displayed. It needed to be made visible. ## After this commit The Reseller field is now visible on the invoice as well. > Task-4216234 Forward-Port-Of: odoo/odoo#182044
Original PR description
## Before this commit The Reseller field was visible on the sales order but not the invoice. Although the field existed on the invoice, it wasn't displayed. It needed to be made visible. ## After this commit The Reseller field is now visible on the invoice as well. > Task-4216234 Forward-Port-Of: odoo/odoo#182044
8 changes
Enhancements to existing features
This update ensures certain data checks run with the right access level, reducing the chance of validation issues caused by user permissions. It helps make appointment-related operations more consistent and reliable without changing the user experience.
Original PR description
odoo/odoo#180045
13 changes
New functionality added to Odoo
The point of sale UrbanPiper integration now supports Careem as a delivery provider. Businesses using Odoo POS can connect with Careem delivery workflows through UrbanPiper, expanding available delivery channel options; products without images also receive a default image when synced.
Original PR description
*: pos_urban_piper After this commit: ------------------------ - Set a default image when there is no image set for the product going to sync in UrbanPiper. - A new pos_urban_piper_careem module added to support Careem integration with Urbanpiper. task: 4190858
1 change
Enhancements to existing features
The Uruguayan electronic invoice system now includes the invoice reference field in the CompraID tag when sending invoices to Uruware. This enhancement ensures that large-volume invoice receptors can properly accept and process invoices, as some require this reference information to validate incoming documents.
Original PR description
Enhance the invoice functionality by including the reference field (ref) in the XML sent to Uruware using the <CompraID> tag, and ensure it's automatically included in the PDF generated by Uruware.
This info is optional, but it is required by some receptors in order to accept the invoice (big invoicing volume receptors)
LATAM task 1267 / ADHOC ticket 80811Resolved issues and error corrections
The timesheet timer display has been adjusted to use a single-line format for a cleaner and more consistent look. This makes the timer easier to read and better aligned with the rest of the timesheet interface.
Original PR description
Modified the timesheet timer display to use a single line format for consistency. This change ensures that the timer is now presented in a more streamlined manner. task-4146841
Miscellaneous changes
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
Steps to Reproduce: - Open Field Service app - Open any task - Click on the Project Field Issue: - You can select any project which should not be possible because we dont use non fsm projects. Reason: - Change in structure of form. - A new label is added before the project field which makes the current xpath being used to become obsolete. Fix: - Updated the xpath. Issue from https://github.com/odoo/odoo/pull/131015 task-4204896 Forward-Port-Of: odoo/enterprise#7085
Original PR description
Steps to Reproduce: - Open Field Service app - Open any task - Click on the Project Field Issue: - You can select any project which should not be possible because we dont use non fsm projects. Reason: - Change in structure of form. - A new label is added before the project field which makes the current xpath being used to become obsolete. Fix: - Updated the xpath. Issue from https://github.com/odoo/odoo/pull/131015 task-4204896 Forward-Port-Of: odoo/enterprise#70850
Before this commit, when the user copy shifts of the previous weeks and in that previous week he has an open shift, he will have a traceback will be raised because we check if the resource of the shift is flexible or not to be able to correctly compute the allocated hours of the splits generated with the split to split. The problem is an open shift has no resource so it is no needed to check if the resource is flexible. This commit checks if the shift is an open shift or not before check
Original PR description
Before this commit, when the user copy shifts of the previous weeks and in that previous week he has an open shift, he will have a traceback will be raised because we check if the resource of the shift is flexible or not to be able to correctly compute the allocated hours of the splits generated with the split to split. The problem is an open shift has no resource so it is no needed to check if the resource is flexible. This commit checks if the shift is an open shift or not before checking if the resource is flexible or not. This commit also fixes another when we try to copy previous an open shift planned during 2 days, the allocate hours is computed based on the company schedule instead of the real time span between the date end and date start as we do in the `_compute_allocated_hours` method. task-4207839 Forward-Port-Of: odoo/enterprise#70623
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
platform should have been platform_id task-4222927 Forward-Port-Of: odoo/enterprise#71175
Original PR description
platform should have been platform_id task-4222927 Forward-Port-Of: odoo/enterprise#71175
Forward-Port-Of: odoo/enterprise#70849 Forward-Port-Of: odoo/enterprise#70715
Original PR description
Forward-Port-Of: odoo/enterprise#70849 Forward-Port-Of: odoo/enterprise#70715
Resolved issues and error corrections
Users can once again switch to or preview a website even when its domain differs from the domain used to access the Odoo backend. This prevents unnecessary redirects to another domain and reduces the chance of users being asked to log in again.
Original PR description
When the URL domain you are currently using to access the Odoo backend is different from: - The website's one you are trying to switch to using the switcher - The website's one you are trying to preview => the user is redirected to that website's domain (and potentially have to re-login). This is buggy since [1] which really wanted to use the framework util for redirections, while it could not work in those cases as that util is explicitly preventing to switch to a different domain which is exactly what is trying to be done in those cases. [1]: https://github.com/odoo/odoo/commit/2cdc3a8c36233a9bdadea1957c9c5414c511b29e
Ending a Monster recruitment campaign no longer triggers an unexpected error. This helps recruiters complete campaign management actions reliably without interruption.
Original PR description
platform should have been platform_id task-4222927
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
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 Forward-Port-Of: odoo/odoo#18
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 Forward-Port-Of: odoo/odoo#181579
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
This commit fixes two issues: - The logo displayed on the attendance kiosk mode is always the one of the first company in DB (id=1), no matter which one the user is actually logged. - The list of employees shown when manually indentifying isn't filtered by company and shows all employees. opw-4189915 Forward-Port-Of: odoo/odoo#182062
Original PR description
This commit fixes two issues: - The logo displayed on the attendance kiosk mode is always the one of the first company in DB (id=1), no matter which one the user is actually logged. - The list of employees shown when manually indentifying isn't filtered by company and shows all employees. opw-4189915 Forward-Port-Of: odoo/odoo#182062
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
Steps to Reproduce: - Open Field Service app - Open any task - Click on the Project Field Issue: - You can select any project which should not be possible because we dont use non fsm projects. Reason: - Change in structure of form. - A new label is added before the project field which makes the current xpath being used to become obsolete. Fix: - Updated the xpath. Issue from https://github.com/odoo/odoo/pull/131015 task-4204896 Forward-Port-Of: odoo/enterprise#7085
Original PR description
Steps to Reproduce: - Open Field Service app - Open any task - Click on the Project Field Issue: - You can select any project which should not be possible because we dont use non fsm projects. Reason: - Change in structure of form. - A new label is added before the project field which makes the current xpath being used to become obsolete. Fix: - Updated the xpath. Issue from https://github.com/odoo/odoo/pull/131015 task-4204896 Forward-Port-Of: odoo/enterprise#70850
Versions -------- - saas-17.2+ Steps ----- 1. Activiate Stripe, Sips, or Demo as payment provider; 2. create a subscription & confirm; 3. invoice subscription & confirm; 4. click share link & copy; 5. open link in a private window/different browser; 6. pay invoice. Issue ----- The access token is invalid, which is important if you as user don't have regular access to the document (or are logged out). Cause ----- When a subscription payment flow is followed via an invoice, i
Original PR description
Versions -------- - saas-17.2+ Steps ----- 1. Activiate Stripe, Sips, or Demo as payment provider; 2. create a subscription & confirm; 3. invoice subscription & confirm; 4. click share link & copy;…
Versions -------- - saas-17.2+ Steps ----- 1. Activiate Stripe, Sips, or Demo as payment provider; 2. create a subscription & confirm; 3. invoice subscription & confirm; 4. click share link & copy; 5. open link in a private window/different browser; 6. pay invoice. Issue ----- The access token is invalid, which is important if you as user don't have regular access to the document (or are logged out). Cause ----- When a subscription payment flow is followed via an invoice, it sets the `access_token` in the controller and adds a `transaction_route_subscription` value. The `access_token` is valid for the `transaction_route_subscription`, but this route is only followed when payments are automated (added in 36b238b934f). Initially, the invoice token was passed, which worked for non-automated payments getting passed as regular invoices to `account_payment`. Commit 60fd12a6c65 changed this to a subscription token, to allow automated payments, but broke non-automated payments in the process, as those still go via `account_payment`, which expects an invoice token. Solution -------- Concatenate the access tokens, and decide which one to use in the `_submitForm` override. Also partially undo 2b34ba49ef7: `payment_utils.check_access_token` expects a payment access token, the commit made it pass a invoice access token instead. opw-4152257 Forward-Port-Of: odoo/enterprise#71197 Forward-Port-Of: odoo/enterprise#70503
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
Forward-Port-Of: odoo/enterprise#70849 Forward-Port-Of: odoo/enterprise#70715
Original PR description
Forward-Port-Of: odoo/enterprise#70849 Forward-Port-Of: odoo/enterprise#70715
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