Wednesday, January 31, 2024
5 changes · saas-17.1
Resolved issues and error corrections
This fixes a crash that happened when older web components tried to load required JavaScript, CSS, or other asset bundles. It restores compatibility for legacy widgets, helping affected pages and customizations load reliably again.
Original PR description
`Widget` and `PublicWidget` allow loading any necessary assets/external lib resources by adding them to `jsLibs`, `cssLibs` or `assetLibs` attributes. But after the rewrite of `loadBundle()` in odoo/odoo@14b629192, any widget setting those attributes were crashing when trying to load them (crash); this commit re-add that support. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where website form fields could remain visibly editable after changing the form's send settings and saving. This helps ensure saved website pages appear correctly to visitors and avoids confusing editor artifacts.
Original PR description
With commit [1], the ability to add property field inside a website form was implemented. In this case, some models have different fields available depending on the action they perform. E.g. if you…
With commit [1], the ability to add property field inside a website form was implemented. In this case, some models have different fields available depending on the action they perform. E.g. if you select "Create a task", depending on which project you choose to create a task in, different fields will be available. For that reason, the decision was made to destroy the SnippetEditors of existing fields, so that they would update their available fields. However, while we destroy the editors, we do not properly clean the DOM before destroying them. This can lead to editor elements still being in the DOM after saving. Steps to reproduce: - Drop a form snippet - Add a "selection" field - Change the email address on which the form will be sent to - Click on save => The selection field is still in editable mode This commit fixes that by properly calling `cleanForSave` before destroying the SnippetEditors. [1]: https://github.com/odoo/odoo/commit/5c08ac23 Related to task-3278975
The website configurator now loads the templates it needs from all available themes, reducing the chance that users get blocked during website creation. This is especially important for trial databases that use prebuilt images and may not match the latest code updates exactly.
Original PR description
Commit [1] solved an unseen issue with the configurator introduced with commit [2]. It was preventing the website configurator to go through in some cases, which was detected on odoo.com/trial the…
Commit [1] solved an unseen issue with the configurator introduced with commit [2]. It was preventing the website configurator to go through in some cases, which was detected on odoo.com/trial the day the 17.1 became available there. The fix was quickly deployed, but it was actually not enough.. Indeed, Odoo.com trial databases are not created from scratch but indeed are using custom odoo DB images. Those images are not sync'd with the code where they run obviously (we don't create new images everytime we update our /trial production). Because of that, the fix made at [1] was not enough, as it relied on website module installation. It was quickly done to "revive" the configurator on the production. The biggest problem is actually the fact that there is no workaround this blocked configurator screen: no skip button, no redirect button, nothing. That part will be handled in an upcoming task, see [3], which will mitigate the issue as if the configurator were to be blocked again later, there would be a way for the user to "continue". The fix here is about reverting commit [2] to not take any risk. It means that it will load configurator templates from all themes, even uninstalled ones, but it will reduce the risk of a configurator failure drastically. Steps to reproduce: - Checkout git before commit [1] - Start with `odoo-bin -i website` and design-themes in the addons path. - Create a new website. - Generate a website with "About Us", "Services", "Pricing" and "Privacy Policy". - ERROR: It will crash - Now checkout after commit [1] - Try again the configurator: it will crash. (But note that it will be enough to fix DB created after commit [1]) - Now checkout this commit - Try again the configurator: it works [1]: https://github.com/odoo/odoo/commit/9ae5e2bb25ea164264aeab7e45f53472a7d6aa5a [2]: https://github.com/odoo/odoo/commit/cfed4e391d11058b1b46417f0b630cdbc4070d7c [3]: https://www.odoo.com/web#menu_id=4720&cids=1&action=333&active_id=974&model=project.task&view_type=form&id=3709708
This update restores two user navigation actions that could fail after an internal service change. Users can reliably open “My Account” from the user menu and trigger the home action without interruption.
Original PR description
Since [1], the rpc service no longer exists, and the rpc function can be directly imported. This PR adapts a forgotten usecase, accessible when clicking on "My account" in the user menu. [1] odoo/odoo@137c43d02a27aec8302f823d8e3a1f18599489a2 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
This update fixes an issue in Manufacturing shop floor quality check dialogs caused by a recent technical change in how selection fields receive their settings. It helps prevent errors when users interact with related record fields during work order quality checks.
Original PR description
Due to commit [1] The props on context for m2o take an object but the shopfloor hasn't been adapted [1] https://github.com/odoo/odoo/commit/3670f78be767396f322ff3ebf068af5c2f547b36