Daily updates from Odoo
Tuesday, December 10, 2024
33 changes
1 change
Resolved issues and error corrections
Point of Sale receipts now show the company name again, matching behavior from previous versions. This helps customers and staff clearly identify the business on printed or digital receipts.
Original PR description
**Steps to reproduce:** - Make a POS order - Process to payment - Check receipt **Issue:** The company name is not displayed on the receipt as it was in previous versions. opw-4349203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
26 changes
Resolved issues and error corrections
Timesheets now avoid selecting projects that cannot be used for timesheet entries as the default, reducing confusion and incorrect entry setup. The change also adds supporting model data to make future timesheet testing easier and more reliable.
Original PR description
This commit's purpose is to add some data model in order to ease the writing of hoot tests. These data are introduced due to a necessity in the enterprise part of the pr. https://github.com/odoo/enterprise/pull/74264 task 4268687
Customers and staff can now download invoices for point-of-sale orders paid online. The fix ensures the invoice can be accessed even when only its reference is available, reducing failed invoice downloads after online payment.
Original PR description
Before this commit, it wasn't possible to download the invoice of an order paid with online payment. This was because the account move of the order was not loaded, even though it could have its ID, which is sufficient. opw-4357927 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Quotations created from repair orders now keep the correct product quantities when opened in Point of Sale. This prevents items added during a repair from appearing with a zero quantity, helping staff process the quotation accurately.
Original PR description
When opening a quotation created from a repair order in the PoS the quantity of the products would always be 0. Steps to reproduce: ------------------- * Create a repair order for whatever product * Add some product to the list with the "Add" option * Start and End the reparation * Create a quotation for the repair order * Open the quotation in the PoS > Observation: The quantity of the product in the pos is 0 Why the fix: ------------ If the sale order line has no `valued_move_ids` it means that it's linked to a repair. In this case we take the product_uom_qty into account for the pos order line quantity. opw-4261097
This update fixes an automated purchase product matrix walkthrough by removing outdated jQuery usage. It helps keep internal testing reliable so future purchase product matrix changes can be validated with fewer false failures.
Original PR description
In this commit we fix tour by removing the usage of jQuery. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures users can still find and select records in dropdown fields even when a model has no configured display name search. It avoids unintentionally narrowing results while keeping the existing warning for administrators or developers.
Original PR description
We already display a warning message, but we need to explicitely not restrict the search. The `name_search` method is called when trying to populate many2one fields and we want to be able to select items even when name searching is not defined. task-3484032 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The replenishment list no longer applies the "to replenish" filter automatically, avoiding repeated calculations that could slow down the page. Users can still apply or save this filter manually when they need to focus on products that require ordering.
Original PR description
The filter to replenish use the `qty_to_order` field. However when adding a filter multiple function are called. `web_search_read`, `search_panel_select_range, `search_panel_select_multi_range`…
The filter to replenish use the `qty_to_order` field. However when adding a filter multiple function are called. `web_search_read`, `search_panel_select_range, `search_panel_select_multi_range`
However they all use the search domain and in the default search there is the `to replenish` filter with [('qty_to_order', '>', 0)] And each time they trigger while it's not needed to recompute them.
We think about storing the qty_to_order_computed but it's not optimal to store a value that needs to be updated everyday, just to cache it.
Instead we will remove the default filter. It's a good trade off since it's only needed when people create their orderpoints automatic themself. In general, it's not needed since the automatic rr are deleted and created on missing quantity. For people that create the automatic rr they can still use the filter and move it default but it could continue the performance issue
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prClosing the tour recorder now clears its active state, so it no longer appears to keep recording when users return later. This prevents confusion and makes the tour recording tool behave more predictably.
Original PR description
When closing the tour recorder, the state should be clear. Because if not, when leaving and coming back later, the tour recorder would be still recording. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers could hit an error when opening invoices linked from project tasks in the portal, especially when a sales order had multiple invoices. This fix correctly handles the updated invoice data format so portal users can access their invoices without a crash.
Original PR description
Currently a traceback occurs when the user opens an invoices from the tasks in the portal. To reproduce this issue: 1) Install sale, timesheet 2) Open a sale order having a project or create a…
Currently a traceback occurs when the user opens an invoices from the tasks in the portal. To reproduce this issue: 1) Install sale, timesheet 2) Open a sale order having a project or create a confirmed SO with product type as service 3) Create multiple invoices for that SO 4) Now open the related tasks of that SO having invoices from the portal 5) Click on `invoices` from side panel Error:- ``` AttributeError: 'list' object has no attribute 'ids' ``` This error is occurring from the below line https://github.com/odoo/odoo/blob/88c0f9d953d077510961243080dcab2cc1920c27/addons/sale_timesheet/controllers/portal.py#L43-L50 Clearly, we get invoices as a list of dict in values from the below line. https://github.com/odoo/odoo/blob/88c0f9d953d077510961243080dcab2cc1920c27/addons/account/controllers/portal.py#L126-L133 Initially, we get the recordsets of invoices in `values['invoices']`. But because of the recent changes from the below commit, we get a list of recordset values, from which we can access the value of invoice ID. https://github.com/odoo/odoo/pull/174812/files#diff-3b907221102acd53c211a3a6b50b00543dcbbc865d50ef4451bea465f7300cbaR107-R112 We can resolve this issue by looping in invoices and access the invoice id. similarly like this https://github.com/odoo/odoo/blob/48629b94dac45dad0766fbaeef0f71934a5adcc4/addons/account/controllers/portal.py#L90 sentry-6117277208
This fixes applicant creation from job platform emails so recruiters no longer see generic email subjects used as candidate names. Applications from sources like Indeed will keep the actual sender name, making candidate lists easier to read and manage.
Original PR description
Emails sent by some job platforms (e.g. Indeed) result in applicants with a display name like: [Action required] New application for Developer, San Francisco, CA This makes it hard for recruiters to…
Emails sent by some job platforms (e.g. Indeed) result in applicants with a display name like: [Action required] New application for Developer, San Francisco, CA This makes it hard for recruiters to efficiently use the recruitment app. These emails don't use `hr.job.platform`, because the platform (e.g. Indeed) sends out the email under an application-specific `From: `, e.g. `"Joren Van Onder" <jov2ueneo87n_g88@indeedemail.com>` So the `hr.job.platform` mechanism isn't needed. Before this commit, when an application like this was received, the name on the hr.applicant (computed field based on candidate_id) would become the email subject name. This is the default behavior of `mail.thread`: it fills `_rec_name` with the subject if not set [1]. To fix it, always force partner_name in `hr.applicant`s `message_new()` (this already was being done if an `hr.job.platform` matched). [1] https://github.com/odoo/odoo/blob/f4990442904a23a387f21822b91d096f5eb987fc/addons/mail/models/mail_thread.py#L1412-L1422 opw-4383191
This update prevents Korean localization accounting report codes from overlapping with codes used elsewhere in Odoo. It helps avoid test failures and reduces the risk of reporting setup conflicts for Korean accounting features.
Original PR description
Some code used in accounting report lines are also used in other reports outside of the KR localization. As of now, unlike what the constrains hint, codes are not expected to be unique per report but instead unique entirely which was not the case. The Unallocated Earnings lines had the same code as the standard ones which ended up causing some tests to fail. To fix this, we are adding a prefix to all codes. The constrains was also temporarily changed to ensure that the new codes are at least unique in the KR module and do not clash with account_reports. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes an automated stock picking batch test more precise by clearly identifying when actions happen inside pop-up windows. It helps prevent false test failures and improves confidence in future updates to batch transfer workflows.
Original PR description
In the test_stock_picking_batch_sm_to_sml_synchronization tour, it is imperative to be exhaustive about whether we are in a modal or not. The trigger targets an element that is not in a modal when it should be. In this commit, we stipulate each modal for each trigger. This not only makes the tour more understandable but also avoids any ambiguity. runbot-error-id~109487 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Worldline payment references are now kept intact when transaction IDs are processed. This prevents payout reconciliation errors and avoids possible reference collisions caused by accidentally shortened payment IDs.
Original PR description
Fixup of #185951 When removing the trailing _0 in transaction IDs from the API response, any trailing 0 in the PAYID gets truncated as well, due to the use of `rstrip()`. A series of consecutive transactions are then saved with the following provider_reference values: 8390248265 8390248266 8390248267 8390248268 8390248269 839024827 8390248271 which leads to mismatching reconciliations of payouts for the truncated ones, and may cause collisions of PAYIDs with older transactions.
The Update DGI Status button is now hidden when a Uruguayan electronic invoice has already been accepted or rejected by DGI. This prevents users from trying to refresh a status that can no longer change, reducing confusion on completed documents.
Original PR description
This PR hides the “Update DGI Status” button on the account.move form view when the CFE Status is either “CFE Accepted by DGI” or “CFE Rejected by DGI”. This change is necessary because both “Accepted” and “Rejected” are final states that cannot transition to another status. Once a CFE reaches either of these states, there is no status update possible, making the button irrelevant in these scenarios. Task Adhoc side: 43467 Task Latam side: 1295
Fixes issues that could cause the timesheet timer header to appear empty or fail when starting, stopping, or discarding timers in list views. This improves reliability for users tracking time, including when entries are grouped or no timesheetable projects exist.
Original PR description
Currently, the timesheet header is not working correctly in the list view. There are a bunch of issue that this commit aims to fix: An empty header is displayed when the start button is pressed, and…
Currently, the timesheet header is not working correctly in the list view. There are a bunch of issue that this commit aims to fix: An empty header is displayed when the start button is pressed, and trying to either stop it or discard it will triggers an error The grouped by function triggers a similar issue as the one above when trying to start & stop the timer When there are no timesheetable project inside the database, an error is triggered too when starting the timer. Source of the issues : - when trying to start a timer in the list view, the function 'cleartimesheetname' is triggered. The problem is that function triggers an update on the listview. This update then triggers a second execution of the 'onWillUpdateProps' of the timesheet_timer_hook class. This second execution is not expected in the flow and set the value of the timesheet of the header to 'false'. - when the view is grouped, the record are not loaded inside the the folded section. This means that when we search for the record inside the 'popRecord' function of the timesheet_timer_hook class, we find nothing. In this use case though, the record is supposed to be found and set. - when there are no timesheetable project, the method 'popRecord' will set the timesheet of the header back to 'undefined'. Solution : - Removed the 'cleartimesheetname' method, as it is no longer usefull. A check up in the write/create of the model will prevent the required field 'description' from being null. The 'enterEditMode' has also been restricted to the kanban view, since doing this in the list view was also triggering an extra call to 'onWillupdateprops' - Checked the view to get a dynamicRecordList we can use to correctly set the data. More information inside the comment in the code. - added a condition inside the 'popRecord' method so that in no longer set the timesheet to undefined when we dont need it to task - 4268687 affected version 18.0-master
This change corrects a recent condition that caused errors when exporting Spain's Mod 347 report. It ensures the report can still generate the required export file when period comparison is needed, reducing disruption for accounting users.
Original PR description
The condition previously added leads to an error when exporting mod 347 in l10n_es as generating the export file for this report always requires period comparison. Previous pr: https://github.com/odoo/enterprise/commit/045fd08c11d5f1407e971da52ea29654ac28aa93#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecR659
This update fixes several issues affecting accounting reports, payroll editing, POS tax matching, appraisals, preparation displays, and Studio visibility rules. It also improves WhatsApp voice message handling so received audio can be played directly in discussions, reducing errors and improving day-to-day usability.
Original PR description
Avoid calling registry with a fix mode name to allow model ihnritance for new model
Example:
```
Class SaleOrderMutation(models.Model):
_name="sale.order.mutation"
_inherit = ["sale.order.line"]
```Italian point of sale receipts now handle rounding adjustments correctly when sending data to fiscal printers. This prevents printer crashes when totals are rounded up or down, helping checkout operations continue smoothly.
Original PR description
When managing rounding adjustments at the point of sale (either excess or defect), Odoo modifies the amount to be paid accordingly. This requires sending an XML tag `printRecSubtotalAdjustment` to the fiscal printer, which is populated differently based on whether the adjustment increases or decreases the total. Without this tag the printer goes wrong and crashes. The issue is resolved by ensuring the adjustment value is properly quoted in the XML. Proper XML formatting prevents the crash. Example: ``` Product price: 1.23 Rounding: 0.02 Total: 1.25 ``` or ``` Product price: 1.23 Rounding: -0.03 Total: 1.20 ``` --- CLA signed here: https://github.com/odoo/odoo/pull/186833
This update prevents quantity adjustment buttons from appearing on full package lines in the Barcode app, avoiding errors when users move entire packages. It also ensures barcode-specific forms are only used in the right context, reducing unexpected errors in inventory workflows.
Original PR description
**[FIX] stock_barcode: move entire package button** > Before this commit, the buttons to add quantity on a barcode line were also displayed for package lines. It shouldn't be the case and it doesn't work (traceback when clicked.) This commit fixes that. **[FIX] stock_barcode_*: views priority** > *: stock_barcode_mrp, stock_barcode_picking_batch > > This commit adds missing priority on primary `stock.move.line` form inherited views: > - `stock_barcode_mrp.stock_move_line_product_selector` > - `stock_barcode_picking_batch.stock_move_line_product_selector_inherit` > > Without this field, those views will have the default priority and will sometime be displayed instead of the default move line form view (`stock.view_move_line_form`) which causes a traceback because those views were explicitly created for the Barcode app and use specific widget which is no usable in other contexts. task-4329041
This fix prevents Spanish invoice records from being incorrectly marked as manually modified when their invoice type is adjusted during creation. It helps keep invoice status information accurate and avoids unnecessary follow-up or confusion for accounting teams.
Original PR description
this fix adds skip_is_manually_modified context to the moves in spanish localization create method, so that is_manually_modified field is not unnecessarily changed to true when changing the invoice type. [link to runbot build errors](https://runbot.odoo.com/web#id=99362&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form)
Korean accounting report line codes were updated to avoid overlaps with other reports. This prevents related report tests from failing and helps ensure the Korean localization remains reliable.
Original PR description
Some code used in accounting report lines are also used in other reports outside of the KR localization. As of now, unlike what the constrains hint, codes are not expected to be unique per report but instead unique entirely which was not the case. The Unallocated Earnings lines had the same code as the standard ones which ended up causing some tests to fail. To fix this, we are adding a prefix to all codes. The constrains was also temporarily changed to ensure that the new codes are at least unique in the KR module and do not clash with account_reports.
This fixes an error that could stop customers from opening invoices linked to helpdesk tickets in the portal. Users can now access those invoices normally, improving the support portal experience and reducing support interruptions.
Original PR description
A traceback occurs when the user opens an invoice from the tickets in the portal. Error:- ``` AttributeError: 'list' object has no attribute 'ids' ``` This error is occurring from the below line https://github.com/odoo/enterprise/blob/a2cfc7c223dfe915a1965d08c2e1f91cfeabe2f6/helpdesk_account/controllers/portal.py#L40-L47 Initially, we get the recordsets of invoices in `values['invoices']`. But because of the recent changes from the below commit, we get the list of recordset values, from which we can access the value of invoice ID. https://github.com/odoo/odoo/pull/174812/files#diff-3b907221102acd53c211a3a6b50b00543dcbbc865d50ef4451bea465f7300cbaR107-R112 Community PR:- https://github.com/odoo/odoo/pull/190062 sentry-6117277208
**Issue:** Some terms don't appear in Spanish in DIAN invoice PDF files.  **Expected:** These terms should be translated in Spanish. **Steps to reproduce:** - Activate Accounting app in a Colombian database; - Configure the DIAN credentials, client, journal and product (https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html?highlight=dian); - Create a cust
Original PR description
**Issue:** Some terms don't appear in Spanish in DIAN invoice PDF files.  **Expected:** These terms should be…
**Issue:** Some terms don't appear in Spanish in DIAN invoice PDF files.  **Expected:** These terms should be translated in Spanish. **Steps to reproduce:** - Activate Accounting app in a Colombian database; - Configure the DIAN credentials, client, journal and product (https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html?highlight=dian); - Create a customer invoice; - Send and print with (only) DIAN checkbox checked; - Open the PDF for the invoice. **Cause:** No translations (or erroneous ones) have been found for these keys. **Fix:** Add Spanish translations for these terms. <img width="642" alt="Capture d’écran 2024-12-09 à 11 52 44" src="https://github.com/user-attachments/assets/77f548f4-f87e-4823-9fdc-5b54d0db2a1f"> **Testing:** Testing needs actual credentials and complete configuration (including setting the client's language to LATAM Spanish)  opw-4343184
Project kanban cards now show the budget progress symbol again. This helps users quickly see budget status directly from the project overview without opening each project.
Original PR description
Because of a missing field, the budget symbol to indicate the progress of the budget of a project was not displaying on its kanban card. This commit adds the missing field. Task-4353196
Barcode scanning now avoids accidentally loading every product when handling GS1 barcodes. This prevents slowdowns and reduces the risk of incorrect or delayed warehouse scanning results.
Original PR description
In the `get_specific_barcode_data_batch` method, we convert the search domain if we use GS1 nomenclature.
In some point, we have this code:
```python
converted_barcodes_domain = expression.OR([
converted_barcodes_domain,
[(barcode_field, 'ilike', barcode)]
])
```
The issue with that is `converted_barcodes_domain` is first an empty list, so the call to `expression.OR` results into `[(1, '=', 1)]]` domain. That means when we will search products with this domain, we will get every products.
This fix ensures `converted_barcodes_domain` is not empty before to call `OR`, otherwise we simply assign the converted domain to the variable without the use of `OR`.Portal users can now see the Document link on a shared project task when a related document has been shared with them. This makes shared task documents easier to access and avoids confusion when no other task links are present.
Original PR description
- 18.0 ### Steps to reproduce: - Install document and project. - Create a portal user. - Create the project and the task. - Upload the document in the task. - Share the document with the portal user. - Share the project with read access to the portal user. - Login with the portal user. - Open the shared project and created task. ### Issue: 'Document' is missing from the left sidebar, even after sharing with portal user ### Cause: 'Document' is in the link section of the sidebar. It will be visible when any task link is shared, eg, invoice, sale order, and helpdesk ticket. So, when there is only a document shared it doesn't display. ### Solution: Display the 'Document' when the document is shared with the portal user. task-4194318
Deleting a project now also archives its related document folder when no remaining projects use that folder. This keeps Documents cleaner by preventing unused project folders from lingering after their projects are removed.
Original PR description
Purpose ======= When deleting a project, its documents are archived but not the documents folder. Fixing that by archiving the folder if every projects it is related to has been deleted. Specification ============= As a folder is created for every new project, it seems logical to archive the folder if the project is deleted. This prevents having "flying" folders, i.e. empty project folders not being linked to any project. Technical: - As the same folder can be linked to multiple projects, only archiving the folder if every projects it is related to has been deleted. - Using sudo(False) because documents access rules can be slow. Task-4262380
6 changes
Resolved issues and error corrections
This update resolves a warning message appearing in payment receipts for Mexican invoices. The fix addresses an issue with how PyPDF2 handles XML data, preventing errors during CFDI generation. This ensures payment receipts are consistently produced without technical disruptions.
Original PR description
**Steps to reproduce:** - Make sure that PyPDF2 is in version 1.26.0 - Install l10n_mx_edi - Switch to a Mexican company - Create an invoice: * Customer: [a Mexican customer] * Payment Way:…
**Steps to reproduce:**
- Make sure that PyPDF2 is in version 1.26.0
- Install l10n_mx_edi
- Switch to a Mexican company
- Create an invoice:
* Customer: [a Mexican customer]
* Payment Way: [Effectivo]
* An invoice line with a product having a UNSPSC Category
- Confirm the invoice
- Generate CFDI via "Send & Print" button
- Register a payment with "Efectivo" Payment Way
- Update Payments on the invoice
- Go to the payment
- Force CFDI
- Make sure the CFDI status of the payment is "Signed"
- Print "Payment Receipt"
**Issue:**
PyPDF2 raises a traceback:
"IndexError: list index out of range".
**Cause:**
PyPDF2 is executing this code to format a warning: file = filename.replace("/", "\\").rsplit("\\", 1)[1] where filename is something liked "<xxx>" (coming from the qweb compilation). Therefore, there is no index 1.
The warning is coming from lxml and is due to the fact that we are evaluating a xml value as it is in a qweb template:
"FutureWarning: Use specific 'len(elem)' or 'elem is not None' test instead." And since this commit:
https://github.com/odoo/odoo/commit/fd67b56fc695526d09706d2b6218519ea255fc30 Python's "warning.py" is overridden in PyPDF2.
**Solution:**
Use "len(cfdi['cfdi_node'])" as advised to check if the xml node has children in the payment receipt template.
opw-4359466
opw-4366016This update resolves an issue where appointment templates weren't consistently rendering correctly. The fix ensures the website appointment template no longer relies on updates to the underlying appointment module, guaranteeing stable template rendering across Odoo versions. This improves the user experience for appointment scheduling.
Original PR description
Versions -------- - 17.0 - saas-17.2 - saas-17.4 - 18.0 Steps ----- 1. Install appointment pre efd76940c999; 2. install website post efd76940c999. Issue ----- Template rendering issue. Cause ----- The commit added a xpath to website_appointment relying on an updated appointment module, which isn't always the case in stable. Solution -------- Make the xpath in website_appointment not rely on the appointment change. opw-4394557
This update resolves intermittent errors that prevented the documents access rights tour from completing successfully. The fix involves adding a check to ensure the page correctly transitions between companies before the tour finishes, improving the user experience and reliability of this onboarding feature. The issue was identified through automated testing and addressed with a targeted code change.
Original PR description
backport of pr-s [68962](https://github.com/odoo/enterprise/pull/68962) and [68770](https://github.com/odoo/enterprise/pull/68770). broken runbot builds are [here](https://runbot.odoo.com/web#id=60274&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) Added an extra trigger, that will check that the page has properly changed from one company to another, and to let this page to load before finishing the tour.
This update resolves a bug where users managing appraisals without specific group access were unable to view appraisal feedback. The fix ensures that users with manager roles for an appraisal can correctly access the feedback, regardless of their group membership. This improves usability and prevents workflow disruptions for managers.
Original PR description
To reproduce: ============= - assign a user U without any group access to Appraisal app as manager of an appraisal - login as this user U and ask for feedback on the appraisal - fill the feedback, and change it's deadline to the past - try to consult the answers as user U -> redirected to survey expired error page Problem: ======== the access to appraisal feedback is checked based on the user's group access, but the user can be the manager of the appraisal without any group access to the appraisal app Solution: ========= in addition to the group access, check if the user is the manager of the appraisal opw-4354685
This update fixes a visual issue in the mobile and form views of Odoo where long checkbox labels would overlap with the checkboxes themselves. Now, checkbox labels and checkboxes are properly aligned, ensuring a cleaner and more user-friendly experience. This improves readability and usability for users.
Original PR description
`*` = [sale_subscription] Before this commit: In the mobile and form view, when a checkbox field had a long label, the checkbox would appear on top, with the label text displayed below. After this commit: In the mobile and form view, checkbox fields with long labels are now properly aligned, with the checkbox and label text displayed. Task-4269578
This update fixes a display issue in the General Ledger report where the table overflowed, causing the right side of the page to be cut off. The fix addresses a problem with a column width that was too wide, ensuring the report is fully visible and readable. This improves the user experience when generating and reviewing financial reports.
Original PR description
Steps to reproduce ================== - Install account_accountant,l10n_ch_reports - Use the CH company - Create a new chart of account 12345 "Current Account Abcdgraph Labs 12345 Pvt Ltd" - Create a new customer "Abcdefghijklm Abcdefghijklm 1234" - Create and post a new journal entry for journal 12345 - Go to the General Ledger - Print the ledger => The right side of the page is cut off Cause of the issue ================== The column containing account is too wide and the table overflows the body  opw-4286133