Friday, June 9, 2023
4 changes · master
Resolved issues and error corrections
Website headers now keep separate colors for the overlay and scrolled navigation states, including transparent and gradient backgrounds. This prevents unexpected color blending, giving website editors more predictable control over how the navbar looks before and after scrolling.
Original PR description
This commit allows to have really transparent navabars. Before this commit when the user put transparency on his header, it did not become transparent and the color was just mixed with white.…
This commit allows to have really transparent navabars. Before this commit when the user put transparency on his header, it did not become transparent and the color was just mixed with white. Moreover, this commit also allows to fix a bug a bit tricky: To simplify the explanation below, note that option "C" means the Colors option of the header (just below the Template option) and the option "BHP" means the background option below Header Position. By following these steps: - Drop some block in a the page (to be able to scroll) - Set a very transparent red as the value of C. - The navbar is now in a pinkish color. - Set the navbar position to "Over the content" - With the option BHP, set the background color to a dark color. => When you are at the top of the page, the color is the one of the option BHP. So far so good. Now when we scroll, the color of the navbar is dark red. This is not what the user expects. In this configuration, the C option should set the color of the navbar once the user has scrolled. The colors should not be mixed. Technical explanation of the problem: Option BHP applies the color on the header element and option C sets the color on the nav element. `NAV` element is a child of `HEADER` element. So when `HEADER` has a color set by BHP and nav has a color set by C which has transparency, the color of the `HEADER` influences the color of the navbar when scolling. This commit allows to correct this. task-2904507
This update corrects the appearance of mail notifications in the systray menu. It helps users see and interact with notifications more consistently without changing business workflows.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how manufacturing work center productivity values are updated so they are calculated automatically instead of only reacting to manual screen changes. It helps keep production time and productivity information consistent and reliable for business reporting.
Original PR description
In https://github.com/odoo/odoo/pull/107473, a few *onchange*s instead of *compute*s where introduced by mistake. This commit fix this error and change the functions names and body to be more coherent with the new *compute*s. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a duplicate delivery terms field on purchase orders that was defined in two places. Removing the extra definition helps keep purchasing data consistent and reduces the risk of maintenance issues without changing day-to-day user workflows.
Original PR description
before this commit, the field incoterm_id is defined twice in purchase.order model, i.e., in purchase and purchase_stock modules after this commit incoterm_id field is removed from purchase_stock module issue: https://github.com/odoo/odoo/issues/65347 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr