Thursday, October 3, 2024
13 changes · 18.0
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
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
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…
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
# 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