Monday, December 30, 2024
4 changes · 17.0
Resolved issues and error corrections
This fixes an issue where the Odoo shell command could fail when launched for a specific database because the database name was not available in the running thread. Administrators and developers can now use the shell command more reliably for maintenance and troubleshooting.
Original PR description
The context variable is missing in current thread when using the shell command. see d19478eb03d2 Description of the issue this PR addresses: Use the `odoo shell -d dbname` command ``` Current…
The context variable is missing in current thread when using the shell command.
see d19478eb03d2
Description of the issue this PR addresses:
Use the `odoo shell -d dbname` command
```
Current behavior before PR:
Traceback (most recent call last):
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 87, in __new__
return cls.registries[db_name]
~~~~~~~~~~~~~~^^^^^^^^^
File "/home/bfontaine/Bureau/local/venv17/lib/python3.11/site-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/lru.py", line 34, in __getitem__
a = self.d[obj]
~~~~~~^^^^^
KeyError: 'db_test'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 110, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/bfontaine/Bureau/odoo17/addons/phyto_base/loader.py", line 13, in load_modules
report = odoo.registry()._assertion_report
^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/__init__.py", line 105, in registry
database_name = threading.current_thread().dbname
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: '_MainThread' object has no attribute 'dbname'
Traceback (most recent call last):
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 87, in __new__
return cls.registries[db_name]
~~~~~~~~~~~~~~^^^^^^^^^
File "/home/bfontaine/Bureau/local/venv17/lib/python3.11/site-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/lru.py", line 34, in __getitem__
a = self.d[obj]
~~~~~~^^^^^
KeyError: 'db_test'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/bfontaine/.local/bin/odoo17", line 246, in <module>
main()
File "/home/bfontaine/.local/bin/odoo17", line 242, in main
run()
File "/home/bfontaine/.local/bin/odoo17", line 233, in run
odoo.cli.main()
File "/home/bfontaine/Bureau/odoo/17.0/odoo/cli/command.py", line 66, in main
o.run(args)
File "/home/bfontaine/Bureau/odoo/17.0/odoo/cli/shell.py", line 123, in run
self.shell(config['db_name'])
File "/home/bfontaine/Bureau/odoo/17.0/odoo/cli/shell.py", line 109, in shell
registry = odoo.registry(dbname)
^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/__init__.py", line 106, in registry
return modules.registry.Registry(database_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 89, in __new__
return cls.new(db_name)
^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/local/venv17/lib/python3.11/site-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/modules/registry.py", line 110, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/bfontaine/Bureau/odoo17/addons/phyto_base/loader.py", line 13, in load_modules
report = odoo.registry()._assertion_report
^^^^^^^^^^^^^^^
File "/home/bfontaine/Bureau/odoo/17.0/odoo/__init__.py", line 105, in registry
database_name = threading.current_thread().dbname
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: '_MainThread' object has no attribute 'dbname'. Did you mean: '_name'?
```
Desired behavior after PR is merged:
shell command works
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue where clicking a non-editable drop zone in the website editor could incorrectly trigger editing hints and move the "Drag building blocks here" message. The editor now respects non-editable areas, keeping the page-building experience predictable for users.
Original PR description
Step to Reproduce: 1. Enter the edit mode of Homepage 2. click on drop zone area having "Drag building blocks here" message. -> sometime the "drag and drop a building block here" unexpectedly moves…
Step to Reproduce: 1. Enter the edit mode of Homepage 2. click on drop zone area having "Drag building blocks here" message. -> sometime the "drag and drop a building block here" unexpectedly moves up. which should stay as it is. Before this commit, all `<p>` and `<div>` elements were considered as potential PowerBox elements, making them editable using the `/` command. This occurred even when the elements had the `o_not_editable` class or `contenteditable="false"` attribute. For example, in the case of the `#wrap` element, it has the `o_editable` class along with `contenteditable="false"`. This caused PowerBox element or placeholders to be added unnecessarily, even though no text editing was allowed. In this commit, we adapted the solution merged[1] in master and specify the selector to make sure that no command hint shown on div while having `o_not_editable` class or `contenteditable=false` attribute. [1] https://github.com/odoo/odoo/commit/302250cdde936a47048b8f3403e024e2e617ace7 Before this PR :  Desired behavior after PR is merged: No hint/placeholder is added to contenteditable false block, resulting in data editor message to stay on its place. task-3443430
A technical issue preventing users from printing session reports has been resolved. The problem stemmed from outdated, unused code related to pro forma orders. This update removes the problematic code, ensuring the session report printing function works correctly.
Original PR description
Issue: ==================== - A traceback occurred when attempting to print the session report from the reporting menu. - The issue was caused by unused code related to pro forma orders left over from the refactoring in version 17.0. Fix: ==================== - Removed the unused code related to pro forma orders. - Ensured the session report can be printed without errors. Task-4438550
This update resolves a display issue where the Timesheets grid would show a 'No Timesheets Found' banner and disable navigation when viewing older timesheets. The fix ensures users can seamlessly browse and navigate through their timesheet data, regardless of age.
Original PR description
Issue:
- When an employee has timesheets older than 2 weeks, opening timesheets for a new week displays a "No Timesheets Found" banner, and the ability to navigate the grid to the previous week or display a month is disabled.
Steps To Reproduce:
1. Go to the Timesheets app.
2. Ensure there are only timesheets older than 2 weeks.
3. Exit the Timesheets app and reopen it.
5. Notice the "No Timesheets Found" banner is displayed.
6. Observe that the ability to navigate to previous weeks or display a month is disabled.
Solution:
- this issue was fixed here: https://github.com/odoo/enterprise/pull/64792/commits/1f2ef9fd9200045b556a6dbcefd2dd3f57098cc8 this is a simple backport of the fix to the 17.0 branch.
opw-4238024