main #169
main #169
Conversation
|
|
27 similar comments
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The **`btw_X0`** tax was updated [Here](02ccb58#diff-de6184d4eb5e7e2450afafb9d22046721e4931216a636ec6b945ea27a1488591L391). Despite this update, some customers are still using the original tax, which was mapped during migration [Here](https://github.com/odoo/odoo/blob/17.0/addons/l10n_nl/migrations/3.3/post-migrate_update_taxes.py#L22). As a result of these changes, the customers are unable to view the tax report correctly as it appeared in the production environment. To address this issue, I have added the XML ID of the tax. opw-4091389 upg-1874716 closes #182937 Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Order of company values on reports is different in most of local software in Slovakia. Fix is only cosmetic to follow standards. This commit changes order of specific company values on report_template & report_invoice. Order before commit: vat (IČ DPH) company_registry (IČO) income_tax_id (DIČ) Order after commit: company_registry (IČO) income_tax_id (DIČ) vat (IČ DPH) closes #182156 Signed-off-by: William André (wan) <wan@odoo.com>
|
|
|
|
… in order When user tries to apply a discount code in order, a traceback will appear. Steps to reproduce the error: - Install "website_sale_loyalty" - Activate "Demo" payment provider - Go to Website > Shop > Add a product to cart > View cart - Pay with Demo > Pay - Click the back button - Apply Coupon code Error: A traceback appears: "ValueError: Expected singleton: sale.order()" https://github.com/odoo/odoo/blob/9a9063a2d1f385b02f8453b766ec225def531d7e/addons/website_sale_loyalty/controllers/main.py#L16 When user clicks the back button and applies the coupon, "order" will be empty, So, it will lead to the above traceback. sentry-5856780654 closes #180450 Signed-off-by: Valentin Chevalier <vcr@odoo.com>
…lendar view This issue arises when multiple clicks are made on the calendar view button. Steps to reproduce: - Install either the google_calendar or microsoft_calendar module. - Go to calendar > Click multiple times on the calendar view button. - Error will be generated This issue specifically occurs if either the google_calendar or microsoft_calendar module has been installed. this issue occurs because here https://github.com/odoo/odoo/blob/79666cbab0ab0947b3d853ab58a929635c309bab/addons/google_calendar/static/src/views/google_calendar/google_calendar_model.js#L28 google or microsoft sync will taking longer then 1s, this promise will resolve after 1s and the component is destroyed. so to address this issue, we need to eliminate the race condition and await the completion of the google/microsoft sync. Task-3768492 closes #173783 X-original-commit: odoo-dev@eafea98 Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page - With the `admin browser`, update the demo user language from the Settings to English - Reload the page on the `demo browser`, the menus will have stayed in French while the rest of the page is translated in English Details: - Only the first query after the following step will have an issue, the problem corrects itself on the second refresh. - Could not reproduce on the runbot but could do it locally and on Odoo.SH (in 16.0) and on `odoo.com` free database (18.0). closes #183575 X-original-commit: d74768a Signed-off-by: Julien Castiaux (juc) <juc@odoo.com> Signed-off-by: Laurent Desausoi (lade) <lade@odoo.com>
Steps ----- - Install Employees app. - Have a user with "Settings" Administration rights and no "Employees" rights. - Open an employee profile, open "Work Information" tab and click on an employee in the organizational tree. ** Access error for `message_main_attachment_id` field ** Cause ----- We are checking if the user has access rights on the employee https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L294 and redirecting to the private employee if that's the case. However, this does't guarantee that the user has the `hr.group_hr_user` group necessary to access some fields that were added with `groups="hr.group_hr_user"` https://github.com/odoo/odoo/blob/c58253e6c9c7a92ced59beaf296427311e756237/addons/hr/models/hr_employee.py#L122 opw-4096073 closes #183537 X-original-commit: d0828ee Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com> Signed-off-by: Tanguy Quéguineur (taqu) <taqu@odoo.com>
Steps
---
* install `stock`
* from *Settings* > *Stock* activate packages
* create a product P and put 2 packages (pk1, pk2) of 10 units each
in stock (inventory adjustment)
* create a delivery order for 10 P > *Mark as Todo*
* go to the detailed ops for the move
* => it auto suggest the sml: pk1, qty = 10
* set the qty on the generated sml to 3
* *add a line* > pick from *WHStock - pk2*:
* => this creates the sml: pk2, qty = 7
* set the new sml's package to pk1
* => the *Pick From* field doesn't change
* *save*, the second sml's package has been reset to pk2
Cause
---
In the detailed ops we use a dummy `quant_id` field on sml to allow
selecting a quant and carrying some fields values from it to the sml.
But, when the quant was selected, setting the values of the carried
field, will not affect back the quant. And later, because the quant is
set, we use its values instead of the ones the user specified.
Fix
---
Hide the affected fields in the view, so the user cannot attempt to set
them, which would not work.
opw-4089523
closes #177260
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, logging into the PoS with a user not present in another session and then navigating back to the backend to open a different session resulted in an error due to the missing employee. This commit resolves the issue by incorporating the confid ID when saving employee ID in sessionStorage, ensuring employee information is accurately maintained. opw-4255768 closes #183566 Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). Also add a warning to the try_loading to ease debugging in case of misusage of the method. opw-4231366 closes #183359 Signed-off-by: William André (wan) <wan@odoo.com>
Steps --- * In the setting enable sublocations * Create an internal transfer with 1 operation for some product > *Mark as Todo* * On the stock.move operation line click the list icon for detailed operations. * *Add a line* => this opens a Wizard where we can choose the quant from which to pick the product for the sml * set the line's quantity to some amount less then overall quant availability * After adding the line *Add a line* again, we cannot pick the same quant Use case --- For internal transfers, we would like to be able to pick products from the same quant and dispatch them to several sub-locations of the picking's destination location. Fix --- Remove the check which explicitly prevented picking the same quant twice. Replace it with code that checks if some quantiy is still available for the quants we can choose from. Side Fix --- Delete `onRecordDiscarted` method, which wasn't being used because of the typo and doesn't appear to be necessary. opw-4072541 closes #174984 Signed-off-by: William Henrotin (whe) <whe@odoo.com> Co-authored-by: ajf-odoo <ajf@odoo.com>
Issue: When creating a vendor bill for a non EU partner, setting the tax to "22% G RC (Goods)" and generating the XML file, checking the generated XML file gives the error: "Tipo Documento must not be empty." Steps to reproduce: - create a vendor bill with a non EU partner - add a product with tax "22% G RC (Goods)" - post the bill - click Send Tax Integration - check the generated XML file using an online checker like www.fatturacheck.it - it will show the error "Tipo Documento must not be empty." Solution: - The document type is usually computed. However, in this specific case, it cannot be computed because it does not meet any of the conditions in the computation logic. Additionally, there is no safeguard to prevent the generation of the XML file if the document type is not set. - A check has been added to prevent XML generation when the document type is not set, ensuring the document type is always correctly provided before XML generation. opw-4182531 closes #180364 Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
before commit: When link-preview is done on public channel invitation links it posts a guest joined the channel message in the public channel. after commit: now we are ignoring public channel invitations links for link-preview, so it does not post guest joined the channel backported PR: #178932 which handle's ignore link-preview. task-4083161 closes #180187 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, if you changed the time format in the language, the Gantt and the form view of the attendance did not follow those formats. With this commit, the dates displayed in the Gantt and form view are based on the time format set in the language. Task-4098672 closes #176599 Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
During this commit: 00af576 We changed the CoA but when doing it, we added some subtitle as accounts which was wrong and can be misleading for the users. Also adding some missing accounts. We don't remove the accounts from the reports in case a user used those account, and we don't want them to be impacted by this change. closes #181513 Task: 4210069 Related: odoo/enterprise#70710 Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Reproduce --- - -i hr_holidays - open two secure user sessions - 1st user session: set to handle notifications in odoo - 2nd user session: tag 1st user in the chatter of a approved time off - 1st user session: receives notification just fine - 2nd user session: Refuse opened time off - 1st user session: Traceback opw-4138108 closes #183759 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Taxes with l10n_es_edi_facturae_tax_type field were not updated correctly from the `account.tax-es_common.csv` file causing `TaxTypeCode` in XML to be incorrect in case of withheld taxes(IRPF) and xml file is refused. With this commit, bug is fixed automatically for new users installing the l10n_es_edi_factuare module. task-4095945 closes #179638 Signed-off-by: Josse Colpaert (jco) <jco@odoo.com>
|
|
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