Sunday, April 7, 2024
5 changes · saas-17.1
Miscellaneous changes
Commit[1] aimed to fix a layout issue inside the eCommerce categories form view on mobile devices. Prior to Commit[1], a .oe_left class was applied to the content of the sheet, moving it "out of the flow", resulting in a wrong sized form_sheet. To fix the issue, we removed the `.oe_left` class, but doing such a change introduced a risk for users's customizations. To prevent this issue, we reintroduce the initial lines, and will provide a fix in another PR. Commit[1]: 9837396 Rela
Original PR description
Commit[1] aimed to fix a layout issue inside the eCommerce categories form view on mobile devices. Prior to Commit[1], a .oe_left class was applied to the content of the sheet, moving it "out of the flow", resulting in a wrong sized form_sheet. To fix the issue, we removed the `.oe_left` class, but doing such a change introduced a risk for users's customizations. To prevent this issue, we reintroduce the initial lines, and will provide a fix in another PR. Commit[1]: 9837396 Related to task-3847917 Forward-Port-Of: odoo/odoo#160701
This pr backports some fixed for python3.11 and introduces new fixes for Ubuntu Noble, such as timezones. Forward-Port-Of: odoo/odoo#160842 Forward-Port-Of: odoo/odoo#151989
Original PR description
This pr backports some fixed for python3.11 and introduces new fixes for Ubuntu Noble, such as timezones. Forward-Port-Of: odoo/odoo#160842 Forward-Port-Of: odoo/odoo#151989
On firefox and safari applying a position-sticky on an element inside an other element with an overflow is causing a rendering issue. This was occuring with the dropdown `.o_optional_columns_dropdown` making it unusable as soon as the `overflow-x` triggered the horizontal scroll in the table. This PR moves the `o_optional_columns_dropdown` out of the natural DOM flow with a position-absolute, removing the position-relative on each parents until the `.o_field_x2many.o_field_x2many_li
Original PR description
On firefox and safari applying a position-sticky on an element inside an other element with an overflow is causing a rendering issue. This was occuring with the dropdown…
On firefox and safari applying a position-sticky on an element inside an other element with an overflow is causing a rendering issue. This was occuring with the dropdown `.o_optional_columns_dropdown` making it unusable as soon as the `overflow-x` triggered the horizontal scroll in the table. This PR moves the `o_optional_columns_dropdown` out of the natural DOM flow with a position-absolute, removing the position-relative on each parents until the `.o_field_x2many.o_field_x2many_list` which is out of the horizontal scroll applied by `table-responsive`. This ensures the dropdown-toggle is always displayed on the top right of the table. task-3696473 Will close tickets: 3682280 and 3697814 | Before | After | | ---- | ---- | |  | | Forward-Port-Of: odoo/odoo#160566 Forward-Port-Of: odoo/odoo#151570
Some of the non canononical timezones are not present in Ubuntu Noble, it would be a better practice to only use canonical timezones in data and tests. Note that this is not a real fix for all cases since the database that ran on Ubuntu Jammy and are moved to an ubuntu Noble server will have the issue with timezones already in database. One of the possible fix would be to manage that during upgrades, but this isn't a verry flexible solution since upgrade are meant to manage chyange of vers
Original PR description
Some of the non canononical timezones are not present in Ubuntu Noble, it would be a better practice to only use canonical timezones in data and tests. Note that this is not a real fix for all cases…
Some of the non canononical timezones are not present in Ubuntu Noble, it would be a better practice to only use canonical timezones in data and tests. Note that this is not a real fix for all cases since the database that ran on Ubuntu Jammy and are moved to an ubuntu Noble server will have the issue with timezones already in database. One of the possible fix would be to manage that during upgrades, but this isn't a verry flexible solution since upgrade are meant to manage chyange of version, not change of server. If an old 17.0 versions needs to be moved to a Noble server, this won't work. Another solution would be to install package like tzdata-legacy that may keep the old timezones but it is not the only think since TAI-10 are also in this package. This solution is not ideal because non canonical timezone will still be shown in the dropdown. We would need to filter them. A last solution would be to add the support for those old timezones by monkeypatching the lib. This way, only new timezones would be shown but non canonical one won't crash when used. This is not ideal either because we may need to keep this for a while. But in combination with the upgrade solution, it may work proprely. Forward-Port-Of: odoo/enterprise#60219 Forward-Port-Of: odoo/enterprise#59440
Adapt tests related to changes in community. task-3696473 Related PR: https://github.com/odoo/odoo/pull/153952 Forward-Port-Of: odoo/enterprise#60116 Forward-Port-Of: odoo/enterprise#60079
Original PR description
Adapt tests related to changes in community. task-3696473 Related PR: https://github.com/odoo/odoo/pull/153952 Forward-Port-Of: odoo/enterprise#60116 Forward-Port-Of: odoo/enterprise#60079