Thursday, February 9, 2023
4 changes · master
Resolved issues and error corrections
The French FEC export can now omit selected journals, such as IFRS adjustment journals, so companies can provide auditors or tax authorities with local accounting entries only. This helps businesses meet French reporting requirements while still maintaining separate IFRS records in Odoo.
Original PR description
In French accounting, they need to provide a FEC file to the auditors/tax authority to control their accounting. So far it's fine in Odoo. While a company is managing IFRS accounting, the usual way to do it in Odoo is to use a specific journal "IFRS adjustments" for example. This way of working allows you to have a balance in local GAAP (excluding IFRS entries) and in IFRS GAAP (including the IFRS entries). So far it's fine in Odoo. The issue that we met is once a customer need to send his FEC file to the auditors/tax authority, he needs to send only local entries (then excluding IFRS entries). Therefore, it would be great to have an option to exclude some journals from the FEC export. Task: 3133678
Fixed an issue where sending several invoices at once could result in only one email being sent per company when the same email address appeared multiple times. Document-based mail batches, such as invoice sending, can now send each intended email even when recipients share an address.
Original PR description
Steps to repoduce: - Accounting > Customers > Invoices: select several invoices to send - Action > Send & Print > (deselect Print) > Send & Print Issue: - It sends only one invoice per company Cause: - the mail_compose_message sets the status of an email as `cancel` when a mail has already been sent to a specific adress mail in the batch Solution: - If the use of mass mailing is not contact-based (e.g.: sending multiple invoices) it will allow to send multiple emails to the same adress opw-2775121 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users could sometimes have trouble logging back in after signing out because the browser was still checking background app resources tied to the previous session. This fix makes those resources available during login and safely limits personalized shortcut data when the user is not yet authenticated.
Original PR description
Once the user access the backend (aka. `/web`), the browser loads the WebManifest and the ServieWorker is registered. After a logout, he's redirected to the login page (aka. `/web/login`). But this…
Once the user access the backend (aka. `/web`), the browser loads the WebManifest and the ServieWorker is registered. After a logout, he's redirected to the login page (aka. `/web/login`). But this path being still under the ServiceWorker's scope (cf. `/web`), the browser continues to try to check for an updated ServiceWorker. If the user (same or another one) tries to log back in, a race condition appears between the login request and the check for the ServiceWorker. This issue is due to the ServiceWorker's route requiring an authenticated user, which is not (yet) the case in this scenario, conflicting with the login request. This commit fixes it by reverting the `auth="public"` of the ServiceWorker route. A similar issue, even if less likely to occur, affects the WebManifest route for which the same change is applied. Regarding the WebManifest route, shortcut's collection still requires an authenticated user, but we fallback to an empty list if not authorized (not authenticated, no access to apps, not enough rights...). Note: the ServiceWorker, once registered, is entirely managed by the browser ; we don't have the ability to control when the browser will attempt to update it. > Browsers will check for updates to a service worker when: > * The user navigates to a page within the service worker's scope. > * navigator.serviceWorker.register() is called with a URL different from > the currently installed service worker—but don't change a service > worker's URL! > * navigator.serviceWorker.register() is called with the same > URL as the installed service worker, but with a different scope. Again, > avoid this by keeping the scope at the root of an origin if possible. > * When events such as 'push' or 'sync' have been triggered within the > last 24 hours—but don't worry about these events yet. Steps to reproduce: - Login to an Odoo instance - Logout - Try to go to ´/web/login´ and login again. References: https://developer.chrome.com/docs/workbox/service-worker-lifecycle/#handling-service-worker-updates https://web.dev/manifest-updates/
Creating a new Helpdesk team no longer triggers an access error when existing teams are archived. This prevents unnecessary setup blockers and lets businesses continue managing support teams normally.
Original PR description
Previous to this commit, there was an access error raised when trying to create a team when all the other teams were archived. The error was raised because when teams are archived, the multi-company rule for stages is applied even thought it should not. With out addition to the multi-company rule, we ensure that the rule is not applied when a stage has no related teams or when the related teams are archived. Task-3177229