Wednesday, May 15, 2024
3 changes
1 change
Enhancements to existing features
The Journal Report now shows a cleaner, more focused view with key journal and tax indicators instead of loading detailed move lines directly in the interface. Users can still audit details when needed, while PDF and XLSX exports remain complete and gain improved readability and workbook organization.
Original PR description
The old Journal Report was made in order to have a structured export of the move lines available, via its xlsx and pdf exports. Because of that, its user interface was heavy (since it needed to…
The old Journal Report was made in order to have a structured export of the move lines available, via its xlsx and pdf exports. Because of that, its user interface was heavy (since it needed to reflect what we wanted in the pdf/xlsx), and its computation was both slow and complex. Therefore, we now make the choice to simplify a lot what is shown in the UI by replacing the core of the report by a custom engine (which means the user can now use custom groupby values for this part, so it's more flexible). Only KPIs on the journals used in the periods, and the taxes used within them are shown, not the details of all the move lines. Of course, it is still possible to audit the amounts to see the details behind them, like on any report, so there is no functional loss (before, unfolding all the journals manually and loading more elements until you found the one you needed was useless anyway => people audited the lines to see their details directly within a tree view and used the search feature from there). In the meantime, we keep pdf and xlsx exports as complete as before (so, they do show way more information than the UI, and keep a full listing of all the move lines). For XSLX, we now ensure a new page is used for the rendering of every distinct journal. For PDF, we improve the style of the report, for better readability. task-3698843
2 changes
Resolved issues and error corrections
This fix resolves a critical issue that occurs when upgrading from version 16.0 to 17.0 if certain HR document records have been deleted from the database. The problem was caused by a dependency chain where some records were set to be forcefully created while others were not, causing the upgrade process to fail. By ensuring all dependent records are forcefully created, the upgrade now completes successfully even if records are missing.
Original PR description
The record `documents_hr_contract.documents_hr_documents_contracts` has `forcecreate=1` and there is a chain of dependency of these 3 records: 1.…
The record `documents_hr_contract.documents_hr_documents_contracts` has `forcecreate=1` and there is a chain of dependency of these 3 records:
1. `documents_hr_contract.documents_hr_documents_contracts` [--> 2.](https://github.com/odoo/enterprise/blob/17.0/documents_hr_contract/data/documents_tag_data.xml#L12)
2. `documents_hr.documents_hr_documents` [--> 3.](https://github.com/odoo/enterprise/blob/17.0/documents_hr/data/documents_facet_data.xml#L7)
3. `documents_hr.documents_hr_folder`
But for the latter 2 records **forcecreate=0**. All of these records are set `noupdate=1`. That is why during upgrade the latter 2 records will be skipped from creation if they are missing in db, but it will try to create the 1st one because of that forcecrete=1. This will cause dependency issue if the db is missing the other 2 records.
For solving the issue we set `forcecreate=1` to the latter 2 records.
**Steps to reproduce:**
1. Install modules documents_hr, documents_hr_contract in version `16.0`
2. Delete the document facet `documents_hr.documents_hr_documents`
3. Delete the document folder `documents_hr.documents_hr_folder`
4. Try to upgrade to `17.0`
You will see similar traceback to this:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 113, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
...
...
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 693, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 613, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 556, in _tag_root
f(rec)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 569, in _tag_root
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/17.0/documents_hr_contract/data/documents_tag_data.xml:10, somewhere inside
<record id="document_tag_signature_request" model="documents.tag" forcecreate="1">
<field name="name">Signature Request</field>
<field name="facet_id" ref="documents_hr.documents_hr_documents"/>
<field name="sequence">15</field>
</record>
```Fixed a bug in the web editor where deleting content across empty lines would incorrectly remove all text before the empty line. The issue occurred when users selected and deleted text that spanned multiple paragraphs including an empty one. The fix ensures the editor correctly identifies which content should be removed by recalculating the selection position after handling empty lines.
Original PR description
Issue: ====== The whole content is removed when deleting empty line Steps to reproduce the issue: ============================= - Go to to-do - Add some text in the first line - Keep the second line…
Issue: ====== The whole content is removed when deleting empty line Steps to reproduce the issue: ============================= - Go to to-do - Add some text in the first line - Keep the second line empty - Add some text in the third line - Select some prefix of the third line with the second line too - delete - All the content before the empty line is removed Origin of the issue: ==================== We are in this case: `<p>abc</p>` `<p>[<br></p>` `<p>d]ef</p>` - The `startContainer` in this case is the `p` element and not the `br` so we will not insert the `zws` node inside the `p`. - We assign `next` as the text node containing `ef` - Extract content will remove all the content inside the second `p` element and will be like this `<p>abc</p>` `<p></p>` `<p>ef</p>` - We set selection at the end of the `start` node `<p>[]</p>`so it's like we set the selection in `<p>[]ef</p>` so now `getRange` will return `startContainer=endContainer=textNode(ef)` so `joinWith` is equal to next which is the text node containing `ef` - In the join `while` loop , we have `doJoin=true`, `next` always truthy, `next.previousSibling` will never be equal to `joinWith` since `next=joinWith` so it will keep deleting until we don't have anymore previousSiblings which is basically remove everything before. Note: This doesn't happen in the case the second line has some text because we insert a `zws` before the text node. Solution: ========= Since we apply `fillEmpty` on `start` after extracting the content, we need to get the range after we insert the `br` again to make sure we get the correct `startContainer` and `endContainter`. opw-3878575 Forward-Port-Of: odoo/odoo#165104