Thursday, January 24, 2019
4 changes · master
Resolved issues and error corrections
This fix adds the automatically generated 999999 transition account to the French accounting chart template. It supports proper handling of prior-year results in France, where allocation depends on whether the result is positive or negative, reducing setup issues after migrations or new chart creation.
Original PR description
Add need to use 999999 account (auto generate), because in France the affectation depends on the result (positif or minus / 120 or 129). And it is not possible to have multi unaffected account in Odoo. https://github.com/odoo/odoo/commit/87db2ccd75a849fce4230c0736e78511d7ad8c99 @alexis-via @alnslang @qdp-odoo Pr link to : https://github.com/odoo/odoo/pull/17777 Impacted version : 9/10/Master NOTA : it seems during the Odoo migration V8 to V9, this account is not add. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the website animation system to its previous behavior after a recent editor-related change made it more complex and less reliable. It also adjusts the website forum integration so animations start correctly without unnecessary checks or restarts, reducing the risk of page behavior issues and future merge conflicts.
Original PR description
* website_forum Following the new editor's merge at https://github.com/odoo/odoo/pull/29775, the website 'animation' system was 'extended' to vaguely use a 'Registry' instance instead of an object.…
* website_forum Following the new editor's merge at https://github.com/odoo/odoo/pull/29775, the website 'animation' system was 'extended' to vaguely use a 'Registry' instance instead of an object. This was however left undocumented, with a require in the middle of a file, restarting all animations when used, only used by website_forum... with more code for no reason at all, ... This commit restores the system to the way it was before and re-adapts website_forum: - No need to check if website_forum is in the DOM as it is already checked by the animation system (on top of that... the new code was checking the DOM before it was ready...). - No need of a dynamic add on a registry, this is always done before the DOM is ready, so before the animations are started. - No need to know the root instance in website forum, just use the animation as the Wysiwyg instance's parent. The goal of this commit is also to avoid useless conflicts with https://github.com/odoo/odoo/pull/29442 (that should not have had any conflict at all as totally independent of the editor task...)
The portal signature feature no longer depends on an unnecessary website editor component. This reduces the chance of loading issues after recent editor changes while keeping the portal behavior unchanged for users.
Original PR description
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775, the 'web_editor.ready' module was moved to website without caring about where it was used. Fortunately the only non-website app which uses it is portal in a module which in fact does not need it. It would probably make more sense if it was in portal though (see https://github.com/odoo/odoo/pull/30409) but as an upcoming PR is about to fix those problems (https://github.com/odoo/odoo/pull/29442), this can stay in website for now.
A typo in the Project Enterprise app setup information was corrected. This ensures the app is properly installed when the Project app is used, avoiding missing functionality for users.
Original PR description
Otherwise the module is not installed when project is...