Thursday, July 11, 2024
27 changes · saas-17.3
Resolved issues and error corrections
This update fixes how Point of Sale handles certain internal extra fields whose names start with an underscore. It prevents those fields from being accidentally overwritten, helping keep POS data more consistent and reliable.
Original PR description
Before this commit, extra fields that begin by `_` were not correctly handled in the `related_models.js` file. This commit fixes this issue by adding a condition to prevent extra fields that begin by `_` from being overridden.
The guided Project app tour now recognizes when a user selects an assignee from the dropdown. This prevents users from getting stuck during the onboarding walkthrough and makes the tour behave as expected.
Original PR description
Steps to reproduce: - Start the project tour - Follow the steps till the tour step comes to selecting Assignee's(user_ids) - Now click on the drop-down and select an user. Issue: - The step is not completed even though we have selected an user. - Now type something the Assignee's the step is completed Fix: - Incorrect trigger causes to generate incorrect consumeEvent (i.e., an input consume type) which is not satisfied by click event we initiate Solution: - Change the trigger and rewrite the run function. task-3906723 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
Removing scheduled jobs now also removes their related progress records. This prevents module uninstalls or other cleanup actions from being blocked by leftover internal tracking data.
Original PR description
It prevents the removal of a cron at module uninstall for example. If the cron is being removed it makes sense to drop their associated progress entries. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The self-order demo setup has been corrected so the home page displays the expected buttons. Product or page images that stopped loading after a previous change are also restored, making the demo experience usable and visually complete again.
Original PR description
Previously, in the self_order data demos, there was no button on the home page. Now there are. Another fix in this PR: images were no longer loaded since refactoring. This has now been fixed. taskId: 4023864
Searching for helpdesk tickets from the customer portal now works without triggering an error page. This improves the portal experience for customers and reduces avoidable support friction when users look up their tickets.
Original PR description
After this commit: Traceback will not occur when searching for tickets on the portal task-3959379
Miscellaneous changes
To reproduce the bug follow the instructions: - Have pos and sales app installed - Go to pos app setting and enable is a Restorant setting - Back to the dashboard you should have a new shop called Restorant - Go to the products from and create a product ('pencil' for instance), make it available in pos and in self-order and assign to it a category - Add another product ('paper') with the same options in pos side and assign to it the same category, then add the first product ('pencil') to it
Original PR description
To reproduce the bug follow the instructions: - Have pos and sales app installed - Go to pos app setting and enable is a Restorant setting - Back to the dashboard you should have a new shop called…
To reproduce the bug follow the instructions:
- Have pos and sales app installed
- Go to pos app setting and enable is a Restorant setting
- Back to the dashboard you should have a new shop called Restorant
- Go to the products from and create a product ('pencil' for instance), make it available in pos and in self-order and assign to it a category
- Add another product ('paper') with the same options in pos side and assign to it the same category, then add the first product ('pencil') to its optional product in sales section
- Back to pos dashboard open a sessing in Restorant shop then go back again to the dashboard
- Click on the tree dots on the top right of the Restorant shop block and click on the mobile view
- Create a new order adding 'paper' to the command then go to checkout
Now the optional product 'pencil' should be shown but it's unavailable.
A feature was added in Odoo 17.1 and newer for the availibility of the product on the point of sale app. It filter the product based on the availability hours of its categories. This brought changes to ProductCard component witch (you can check product_list_page) in pos_self_order modul for that. The thing is that these change wasn't made is pos_self_order_sale modul witch made the product always shown as unavailable.
opw-3977238
Forward-Port-Of: odoo/odoo#170362
Forward-Port-Of: odoo/odoo#170119Create an analytic plan [TEST] with default optional availability Add an applicability line with: - Domain: Expense - Product Category: [CATEG] - Applicability: Mandatory Create an expense with an expense product having categoy [CATEG] Create Report, submit and approve Issue: No message is raised, the action should have been blocked by the mandatory applicability opw-3955683 Forward-Port-Of: odoo/odoo#172404 Forward-Port-Of: odoo/odoo#168312
Original PR description
Create an analytic plan [TEST] with default optional availability Add an applicability line with: - Domain: Expense - Product Category: [CATEG] - Applicability: Mandatory Create an expense with an expense product having categoy [CATEG] Create Report, submit and approve Issue: No message is raised, the action should have been blocked by the mandatory applicability opw-3955683 Forward-Port-Of: odoo/odoo#172404 Forward-Port-Of: odoo/odoo#168312
Description of the issue/feature this PR addresses: Current behavior before PR: - In the onboarding tour, a step guides users in creating sub-tasks. Desired behavior after PR is merged: - Launch the sub-task steps only when the tour is automatically started. task-3990244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172674 Forward-Port-Of: odoo/odoo#169796
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: - In the onboarding tour, a step guides users in creating sub-tasks. Desired behavior after PR is merged: - Launch the sub-task steps only when the tour is automatically started. task-3990244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172674 Forward-Port-Of: odoo/odoo#169796
A few translation issues are fixed with this: - The title of the report was not translating the type of leave - The title was not correctly formatting the dates accroding to the locale of the user. - The months were not translated - The days were not translated Cleaning of the title's English will be done in master --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172594 Forward-Port-Of: odoo/odoo#171976
Original PR description
A few translation issues are fixed with this: - The title of the report was not translating the type of leave - The title was not correctly formatting the dates accroding to the locale of the user. - The months were not translated - The days were not translated Cleaning of the title's English will be done in master --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172594 Forward-Port-Of: odoo/odoo#171976
…ecordset Steps to reproduce: install hr_expense with demo data try to make a jsonrpc or any search on product.product with no domain ->key error Before PR: When the compute for standard_price_update_warning is triggered, if the recordset contains products that have unpaid expenses and some that do not have any unpaid expense, you get a traceback because some product keys are not in the mapp keys opw-3741337 Forward-Port-Of: odoo/odoo#170300 Forward-Port-Of: odoo/odoo#154760
Original PR description
…ecordset Steps to reproduce: install hr_expense with demo data try to make a jsonrpc or any search on product.product with no domain ->key error Before PR: When the compute for standard_price_update_warning is triggered, if the recordset contains products that have unpaid expenses and some that do not have any unpaid expense, you get a traceback because some product keys are not in the mapp keys opw-3741337 Forward-Port-Of: odoo/odoo#170300 Forward-Port-Of: odoo/odoo#154760
**Current behavior:** Lines in an invoice may display a product name incorrectly if they mix arabic/latin characters. **Expected behavior:** These types of product names should respect the RTL syntax if being sent to an Arabic lang partner. **Steps to reproduce:** *Ensure the rtlcss node package is installed and in PATH* 1. Create a Saudi company / switch to a demo one, switch to Arabic language 2. Create a product with the name: `دفتر سلكي بهوية الهيئة A4 - شد 50 ورقة
Original PR description
**Current behavior:** Lines in an invoice may display a product name incorrectly if they mix arabic/latin characters. **Expected behavior:** These types of product names should respect the RTL syntax…
**Current behavior:**
Lines in an invoice may display a product name incorrectly if
they mix arabic/latin characters.
**Expected behavior:**
These types of product names should respect the RTL syntax if
being sent to an Arabic lang partner.
**Steps to reproduce:**
*Ensure the rtlcss node package is installed and in PATH*
1. Create a Saudi company / switch to a demo one, switch to
Arabic language
2. Create a product with the name:
`دفتر سلكي بهوية الهيئة A4 - شد 50 ورقة`
3. Create an invoice to a partner with Arabic set as their lang
4. Confirm the invoice -> print it
5. The product name on the PDF has a mal-ordered name
**Cause of the issue:**
The right-to-left rule of the Arabic language is not getting
enforced.
There is a secondary bug where certain whitespace-delimited
substrings get displayed in a broken, overlapping way. From my
no-comprehensive testing, it seems to only happen when there is
a sequence in the string where you have some substring ending in
a numeral (0-9) followed by a single-space, then another
substring that begins with an Arabic alphabet character.
**Fix:**
When printing an invoice with an arabic partner:
1. Use right-aligned text instead of left
2. Pad single-space breaks between substrings in a product name
where the first substring ends with a numeral and the
second begins with an alpha char.
3. Add explicit `dir="rtl"` attribute to the display node
opw-3971541
Forward-Port-Of: odoo/odoo#172089
Forward-Port-Of: odoo/odoo#169267Description of the issue/feature this PR addresses: Transactions which are "locked" should not be edited through the UI Current behavior before PR: Locking a picking allowed you to change details via the smart button Desired behavior after PR is merged: Locked down more. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172481 Forward-Port-Of: odoo/odoo#172041
Original PR description
Description of the issue/feature this PR addresses: Transactions which are "locked" should not be edited through the UI Current behavior before PR: Locking a picking allowed you to change details via the smart button Desired behavior after PR is merged: Locked down more. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172481 Forward-Port-Of: odoo/odoo#172041
Customers are unable to submit their invoice if the LegalReference is more than 250 letters. This commit fixes this. task-4043343 Forward-Port-Of: odoo/odoo#172461
Original PR description
Customers are unable to submit their invoice if the LegalReference is more than 250 letters. This commit fixes this. task-4043343 Forward-Port-Of: odoo/odoo#172461
## Analysis In case it's a simplified invoice, the 'to_invoice' is automatically set to True if a corresponding journal is set. Simplified invoices then generates a PDF which takes a few seconds to generate (using wkhtmltopdf) and slow downs the user experience. ## Fix This commit avoids generating the PDF in case no orders explicitly require an invoice. It mostly works the same as this commit for the Chilean localization: https://github.com/odoo/enterprise/pull/53655 which introduced a ne
Original PR description
## Analysis In case it's a simplified invoice, the 'to_invoice' is automatically set to True if a corresponding journal is set. Simplified invoices then generates a PDF which takes a few seconds to generate (using wkhtmltopdf) and slow downs the user experience. ## Fix This commit avoids generating the PDF in case no orders explicitly require an invoice. It mostly works the same as this commit for the Chilean localization: https://github.com/odoo/enterprise/pull/53655 which introduced a new context parameter (in the related commit: https://github.com/odoo/odoo/pull/148159). ### References opw-3875944 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171523 Forward-Port-Of: odoo/odoo#164783
Previously, when switching from an email template that overrides the email_from field to one that does not, the original email_from value was mistakenly passed as an argument. Consequently, emails were sent with the wrong sender, using the address from the template instead. Whereas, it is expected behavior that when a template does not specify any user, the current user's email address should be used as the sender. [Changes introduced by this commit] This commit addresses the issue by updati
Original PR description
Previously, when switching from an email template that overrides the email_from field to one that does not, the original email_from value was mistakenly passed as an argument. Consequently, emails…
Previously, when switching from an email template that overrides the email_from field to one that does not, the original email_from value was mistakenly passed as an argument. Consequently, emails were sent with the wrong sender, using the address from the template instead. Whereas, it is expected behavior that when a template does not specify any user, the current user's email address should be used as the sender. [Changes introduced by this commit] This commit addresses the issue by updating the sender email to the current user's email address when the template being updated to does not override the sender email field. [Reproduce] - Install -i contacts - Log in as user U - Create 2 Email templates that "Applies to" Contact (Settings/Technical/Email/Email Templates): - T1: set "From" field in "Email Configuration" tab (different than U's email) - T2: without set "From" field - Go to a contact app, select any user - Click "Send message" -> Expand "Full Composer" - Select template T1 (with set email) - Select template T2 (without set email) and Send - BUG: email gets send with email from T1 (even tho we selected T2, without any email) opw-3769188 # Encouraging discussion I would like to encourage discussion on the fix, as I can imagine different approaches to this problem. (Like maybe instead we could not sent the `sent_from` argument from the fronted side and relay on the mechanism of default values). Any comments highly welcomed Forward-Port-Of: odoo/odoo#170299 Forward-Port-Of: odoo/odoo#158000
The step to check the reward line added was sometimes happening before it had time to render. Changed the order of the step to allow the reward line to be rendered before checking it. runbot error: 69954 Forward-Port-Of: odoo/odoo#171882
Original PR description
The step to check the reward line added was sometimes happening before it had time to render. Changed the order of the step to allow the reward line to be rendered before checking it. runbot error: 69954 Forward-Port-Of: odoo/odoo#171882
Add myself for CLA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171169
Original PR description
Add myself for CLA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171169
In auto-complete field of a vendor bill, the domain before the current commit would only get purchase orders from the current company. The domain was amended to get POs from current company and all its descendant branches. The POs of children companies should be visible on vendor bills of current company. If the user selects a PO that belongs to a child company, the company_id field should be = the child company. task-3987695 --- I confirm I have signed the CLA and read the PR guidel
Original PR description
In auto-complete field of a vendor bill, the domain before the current commit would only get purchase orders from the current company. The domain was amended to get POs from current company and all its descendant branches. The POs of children companies should be visible on vendor bills of current company. If the user selects a PO that belongs to a child company, the company_id field should be = the child company. task-3987695 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171480
Before this commit, Czech language translations of the Czech tax report were wrong. The appropriate Czech translations were added from this sheet: https://docs.google.com/spreadsheets/d/1xqDqpLwY5nCyNA5WuzLSPdR52Jq6f8IPxU4S3Bh1Nw4/edit?pli=1&gid=1709389226#gid=1709389226 task-3127683 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172559
Original PR description
Before this commit, Czech language translations of the Czech tax report were wrong. The appropriate Czech translations were added from this sheet: https://docs.google.com/spreadsheets/d/1xqDqpLwY5nCyNA5WuzLSPdR52Jq6f8IPxU4S3Bh1Nw4/edit?pli=1&gid=1709389226#gid=1709389226 task-3127683 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172559
Tag updates were causing reload of the domain, while updating tag counts, With this commit all contextual values are preserved during tag updates [Reproduce] - Install documents,contacts- Open a contact - Open its documents - Go to "internal" - Upload a document - Add a tag to it (or remove it) - BUG: all documents visible (instead of documents for that particular client) opw-3967799 Forward-Port-Of: odoo/enterprise#65299
Original PR description
Tag updates were causing reload of the domain, while updating tag counts, With this commit all contextual values are preserved during tag updates [Reproduce] - Install documents,contacts- Open a contact - Open its documents - Go to "internal" - Upload a document - Add a tag to it (or remove it) - BUG: all documents visible (instead of documents for that particular client) opw-3967799 Forward-Port-Of: odoo/enterprise#65299
Belgium now asks the pro rata deduction for the VAT export. Mandatory if the business is concerned. Added new module to be able to add fields to the wizard. task-3916995 Forward-Port-Of: odoo/enterprise#66381 Forward-Port-Of: odoo/enterprise#65442
Original PR description
Belgium now asks the pro rata deduction for the VAT export. Mandatory if the business is concerned. Added new module to be able to add fields to the wizard. task-3916995 Forward-Port-Of: odoo/enterprise#66381 Forward-Port-Of: odoo/enterprise#65442
To reproduce: - Create a new db with demo data and install `sale_timesheet` module - Then as a second step, install `documents_project` The installation will crash with: ``` psycopg2.errors.NotNullViolation: null value in column "folder_id" of relation "documents_document" violates not-null constraint ``` When using `search` with no corresponding field, `convert_xml()` will only consider the first value, and in our case because of the ordering of project model, we're not going to set
Original PR description
To reproduce: - Create a new db with demo data and install `sale_timesheet` module - Then as a second step, install `documents_project` The installation will crash with: ``` psycopg2.errors.NotNullViolation: null value in column "folder_id" of relation "documents_document" violates not-null constraint ``` When using `search` with no corresponding field, `convert_xml()` will only consider the first value, and in our case because of the ordering of project model, we're not going to setup the document folder on project which is not `project.project_project_1`. This commit force creating documents folders for all projects with `use_documents` option set. Forward-Port-Of: odoo/enterprise#65964
Add shortcut keys to the recon model buttons in the reco widget. The keys are SHIFT+Number (1 to 5 for the 5 visible buttons) Task-4024471 Forward-Port-Of: odoo/enterprise#66066
Original PR description
Add shortcut keys to the recon model buttons in the reco widget. The keys are SHIFT+Number (1 to 5 for the 5 visible buttons) Task-4024471 Forward-Port-Of: odoo/enterprise#66066
**Purpose this PR:** This commit converts the all the qunit testcases of the crm_enterprise module to hoot. Part of task:[3818666](https://www.odoo.com/odoo/project/1519/tasks/3818666?cids=2) Forward-Port-Of: odoo/enterprise#62256
Original PR description
**Purpose this PR:** This commit converts the all the qunit testcases of the crm_enterprise module to hoot. Part of task:[3818666](https://www.odoo.com/odoo/project/1519/tasks/3818666?cids=2) Forward-Port-Of: odoo/enterprise#62256
To reproduce the bug, follow these steps: - Download the document present in ticket 3991731. - Upload it to the sign app. - Try to drag and drop the sign box to the bottom. You will find that the drag and drop functionality in general is erratic. This is due to the coordinates being incorrect, sometimes even negative, since the method used to calculate the height and width of the PDF view is flawed. I used the getBoundingClientRect method (the same method used to get the sign box coordi
Original PR description
To reproduce the bug, follow these steps: - Download the document present in ticket 3991731. - Upload it to the sign app. - Try to drag and drop the sign box to the bottom. You will find that the drag and drop functionality in general is erratic. This is due to the coordinates being incorrect, sometimes even negative, since the method used to calculate the height and width of the PDF view is flawed. I used the getBoundingClientRect method (the same method used to get the sign box coordinates) to fix this issue. opw-3991731 Forward-Port-Of: odoo/enterprise#65020
Before this commit: -Checkboxes in studio were not clearly visible in dark mode due to the border color being too similar to the background. -o_kanban_group had a white background that looked out of place in dark mode. After this commit: -Color of the border of the checkboxes is inverted in dark mode for better visibility -Background color of o_kanban_group is changed to enhance its appearance in dark mode. Task-3920491 Forward-Port-Of: odoo/enterprise#63040
Original PR description
Before this commit: -Checkboxes in studio were not clearly visible in dark mode due to the border color being too similar to the background. -o_kanban_group had a white background that looked out of place in dark mode. After this commit: -Color of the border of the checkboxes is inverted in dark mode for better visibility -Background color of o_kanban_group is changed to enhance its appearance in dark mode. Task-3920491 Forward-Port-Of: odoo/enterprise#63040
With this PR, the actions to open all journal items have been removed from all GSTR sections of the GST return Period. This change helps streamline the GST Return by eliminating unnecessary actions, ensuring a more focused and efficient reporting process. **task**-3908555 Forward-Port-Of: odoo/enterprise#66406 Forward-Port-Of: odoo/enterprise#64442
Original PR description
With this PR, the actions to open all journal items have been removed from all GSTR sections of the GST return Period. This change helps streamline the GST Return by eliminating unnecessary actions, ensuring a more focused and efficient reporting process. **task**-3908555 Forward-Port-Of: odoo/enterprise#66406 Forward-Port-Of: odoo/enterprise#64442