Current behaviour:
When removing the ribbon from a product,
the other ribbons are removed as well.
Steps to reproduce:
1. Go to website
2. Go to Shop
3. Click on Edit (top right)
4. Add a ribbon to multiple products
5. Click on Save
6. Select a product with a ribbon
7. Remove the ribbon
8. (other ribbons are gone)
Cause of the issue:
Reverting fix introduced by https://github.com/odoo/odoo/commit/5d13fa522e7d06b03a098ada5fa6be15ddc49618
t-out was modified into t-field to be considered dirty when modified.
but when removing a ribbon, t-field is set as empty,
which overwrites ribbons html value.
opw-3487397
closesodoo/odoo#145864
X-original-commit: 71bdf1f674d0340a726dba96c65af6fdff25822f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- Make an invoice and setup the layout of the document
- A preview will be displayed
- Make the invoice and download it
Issues:
The layout of the preview and the invoice doesn't match the updated layout from commit 3764914c86.
Solution:
Correct the view of the report templates.
opw-3584286
closesodoo/odoo#145815
X-original-commit: 778cc239010f3bb8618824fdaf06cb19922d6498
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps to reproduce:
- Install Accounting app
- Go to the Accounting app
- Go to Configuration > Chart of Accounts and create a New account with a name containing %
- Go to Accounting > Journal Items
- Select a Jounral item and from Actions, choose move to Account
- In the popup displayed, choose the new account created ealier in the To field, and choose a Journal
- Click `Create Journal Entries`, an error arises
Invistigation:
When the `account_target_name` contains a % literal (ex. "test %"), the `transfer_format` beccomes `"{amount} ({debit_credit}) from %s were transferred to <strong>test %</strong> by {link}"` https://github.com/odoo/odoo/blob/a56586119845969e9d867a220f5330a6c7daa5c2/addons/account/wizard/account_automatic_entry_wizard.py#L429-
- You can notice that now the string has two % placeholders that need two be substituted, but only argument is provided which is `account.display_name` and so we get a the error `TypeError: not enough arguments for format string` https://github.com/odoo/odoo/blob/a56586119845969e9d867a220f5330a6c7daa5c2/addons/account/wizard/account_automatic_entry_wizard.py#L433
opw-3601886
closesodoo/odoo#145762
X-original-commit: 1582a0ae28fec12175845dcfdebbb8d6b4bcde33
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Steps to reproduce:
- install the e-commerce module
- in General settings, add and switch French -or any- language
- Go to website
- Under e-commerce > product in the menu bar
- click on any product
- click on go to website smart button
- click on edit button to edit the website page
- choose any block to insert, You can notice the message (DROP BUILDING BLOCKS HERE TO MAKE THEM AVAILABLE ACROSS ALL PRODUCTS) stays in English
Investigation
- The message is not add to website_sale.pot file, as the message string passed to an attribute not an actual string inside a tag.
opw-3573881
closesodoo/odoo#145755
X-original-commit: 9a595cd19fba3a68dacd5159d0b04102bc76cadf
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Issue:
The _predicted_field is still slow after refactor.
Analyze:
Due to the refactor of the query made in account_move.py
_predicted_field, an index is needed on partner_id.
Fix:
Add an index on partner_id Many2One.
Note:
The previous PR has already been merged
https://github.com/odoo/enterprise/pull/50911 but without the index it
is not as fast as expected. This index had been added by
hand.
Benchmark:
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
| 30M | 22.827 s | 18.59 ms|
Related task:
opw-3539632
closesodoo/odoo#145836
X-original-commit: 50ecb11320c739f734641cf912902f5620dd891d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Benjamin Hanquin (beha) <beha@odoo.com>
The aim of this commit is to fix runbot build error.
Before the commit:
The test could fail if the EUR currency was inactive
After the commit:
The test activate the currency first
closesodoo/odoo#145817
Runbot-error-build: 51509
X-original-commit: 09808f2c91985263090cb9bd38b34d3443a2d7d7
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
The accuracy "Product Unit Of Measure" does not exist, it is "Product Unit of Measure"
closesodoo/odoo#145805
X-original-commit: 8a8a3720bf2ed938dddc1c5889b4207562381234
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit:
The readonly readonly modifier of the statusbar field was not taken into
account when the "clickable" option was set.
After this commit:
Even if the "clickable" option is set to true, if a readonly modifier is
set, it will prevent (or not) changing the stage of a status bar.
closesodoo/odoo#145766
Opw: 3222998
X-original-commit: 9e1d01bc44e5e90ed2b809cfadbd05a5793b3c07
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Steps:
- Install timesheet_grid.
- Start the timer.
- Try to add new task without selecting project.
Issue:
- We can create a new task and afterwards the task would have the projects as
private.
Fix:
- We are taking the canCreateEdit option from props.
task-3378532
closesodoo/odoo#145760
X-original-commit: a92d7d5a92d84074e1d4b0511051c906953c5003
Related: odoo/enterprise#52518
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Currently Team Expense Approver have full access to journal, we
shouldn't do that
closesodoo/odoo#145737
X-original-commit: 9078b6cf4770c8b3b42bde8e36c4eff5f924c7bd
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Steps to reproduce:
- Decimal Accuracy for Product Price > 4 digits
- Purchase a product using a price (1.2345 in my example)
- Go to Purchase > Reporting
- Enable the List View
- Add the field Average Cost (price_average)
- This displays as just two decimals
Note:
can be edited with studio but you can just add the field "price_average"
to the "purchase_report_view_tree" view xml
Fix:
round using product price Accuracy
opw-3560792
closesodoo/odoo#145667
X-original-commit: d5a3430cecb673a06057673d0671228449fa3f60
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Since the update in https://github.com/odoo/odoo/commit/d4b366f2d741f2087a947d61d7e0618492cc2bf1, the POS loyalty program stopped
printing customer names on receipts for transactions without points won
or spent. Originally, printing a loyalty program also included the
customer's name, which users relied on to print the customer's name
on receipts.
This commit ensures the customer's name is printed on the receipt,
regardless of whether any loyalty points were won or spent.
opw-3620536
closesodoo/odoo#145629
X-original-commit: 57037253a472b4a25e2be6622c505a08b7f207ff
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
If the current company is a branch and we're in the product form, we
will not be able to access our parent's account in the following fields:
- `property_account_income_categ_id`
- `property_account_expense_categ_id`
- `property_account_income_id`
- `property_account_expense_id`
This commit aims to fix that behavior by updating the domain to consider
branch companies too
closesodoo/odoo#145355
Task-id: 3549961
Related: odoo/enterprise#52299
Signed-off-by: William André (wan) <wan@odoo.com>
When getting a domain from activeFields in Owl, sometimes the value
passed is not a list or function.
When the field mentioned have a `check_company=True` in the
initialization, the domain passed will be in a form of string instead of
a list.
This commit aims to publicize the domain handler in Field so that it can
be used anywhere by calling the function, as getting field's domain is
getting increasingly common
Task-id: 3549961
Part-of: odoo/odoo#145355
Before this commit, if a new order was created with an existing
pos_reference, it would not be captured even though it was a completely
new order. This occurred because pos_reference was assumed to be unique.
However, there have been several customer reports of orders not being
captured when the receipt contains a pos_reference that already exists.
Some bugs causing duplicate pos_references were found but the root cause
remains unclear.
With this commit, orders are now synced even if pos_reference matches a
previous order. This prevents lost orders and allows customers to access
all their receipts via pos_reference lookup.
An investigation into the cause of duplicate pos_references needs to
continue, but this change unblocks the more serious issue of missing
orders.
opw-3499011
closesodoo/odoo#139974
X-original-commit: 269702891980eb56ddc83e199a9673b1e146d348
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
This commit enables support for functional color notation in CSS
(https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/color).
This new feature accommodates various color spaces utilized within the
'color()' CSS function, seamlessly converting them into an RGBA format
that is comprehensible to the right panel.
Steps to reproduce:
- Enter edit mode
- Add a snippet with a column
- Click on the column
- Set border-width to 5px, enter
=> A gray border appears but the option colorpicker shows no color
Since [this commit] the border has as default opacity of 15%. But now
the custom color in the colorpicker is correctly set.
[this commit]: https://github.com/odoo/odoo/commit/fad514ebdc25b9de03fd387a0c07dbbc274c364e
task-3536051
closesodoo/odoo#137698
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Previously, products loaded from the background included the internal
reference in their displayed name. This behavior was due to the
'display_default_code' context, which prevents the inclusion of
'default_code' in the product name, not being utilized within the
'get_pos_ui_product_product_by_params' function.
opw-3617195
closesodoo/odoo#145644
X-original-commit: b6c87e4c3451fbb554557be95788c8e1a5e0332f
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
- refund tax repartition lines lack tax grids -> added
- Outgoing credit notes lack base line grids -> should decrease total
active transactions -> added.
- Purchase taxes 0% G and 0% S should increase total passive
transactions, not increase total active transactions -> fixed
closesodoo/odoo#145636
Taskid: 3175384
X-original-commit: 114a3e3c1587a057da96d4148d61416cfd434dac
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Issue:
======
Attachment files aren't sent with the event invitation email.
Steps to reproduce the issue:
=============================
- Add any attachment to the email template : `Calendar: Meeting
Invitation` and save it.
- Go to website and book an appointment.
- Go to Scheduled Actions and run manually email queue manager to send
the notification.
- The sent email doesn't have the attachement you provided, it has only
1 attachement which is the calendar one.
Origin of the issue:
====================
The notification of the event invitation was taking only the calendar as
attachment and ignores the template attachemnt.
Solution:
==========
Now the calendar event invitation email will take into account the
attachment of the email_template.
opw-3593140
closesodoo/odoo#145628
X-original-commit: 28880c32e62b6e2e6c87c35094da0e20c6c14c21
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
This change allows to remove discounts from all sale order lines at once, by enabling 0% discounts in the discount wizard.
task-3584450
closesodoo/odoo#144244
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
-------------------
- on ecommerce, activate "Extra Info" feature;
- go to the extra info form;
- write something for "Your Reference";
- press Enter.
Issue:
------
The Bad Request message is displayed.
Cause:
------
Pressing Enter triggers the form's default submit.
To use the controller of the `/website/form/shop.sale.order` route,
we need to apply the JS logic of the `s_website_form`
widget (the `send` function).
Solution:
---------
Add an event for the `submit` which will prevent
the default behaviour and send the form data.
opw-3591135
closesodoo/odoo#145707
X-original-commit: 14fc7f3c923847f5e052888c2cfda0bf92316972
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In Accounting settings set 'Cash Discount Tax Reduction' to Always
Create an invoice
Add a line with tax
Add as payment terms "2/7 Net 30"
Confirm
Click "Add a credit note" and create the credit note
Confirm
Issue: Credit note is missing the epd vals from the invocie so the moves
cannot fully reconcile
opw-3429678
closesodoo/odoo#145653
X-original-commit: f7b371be24a842392a8b46f337256ef13bf8a5ae
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Current behaviour:
When checking the overview of a normal BoM,
the product is available if component is in stock
Expected behaviour:
The product should not be available unless BoM type is kit
Steps to reproduce:
1. Go to Manufacturing
2. Go to Products > Bills of Materials
3. Create a new BoM
4. Product: p1 (and create product p1)
5. Component: p2 (and create product p2)
6. BoM type: Manufacture this product (normal)
7. Save the BoM
8. Click on Overview
9. p1 and p2 are not available (Normal behavior)
10. Go to the p2 product page
11. Click on Update Quantity > new quantity > Apply all
12. Go back to the p1 BoM
13. Click on Overview
14. p1 and p2 are available
15. p1 should only be available if BoM type is kit
Cause of the issue:
Caused by https://github.com/odoo/odoo/commit/f13b4d1ae8c12a1668222e6994dea26a27c6f5d4
opw-3601298
closesodoo/odoo#145598
X-original-commit: f34d5ef9dd2d1ad0c0acaa6a40c8ab7c517fc75d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Applied fixes:
- a lot of translations were outdated, not matching official ones
- box 205 was missing
- box 289 had translation of missing box 205
- box 200 had translation of the section
- boxes 381a and 381b removed, completely outdated: we already removed all other 3X1 boxes.
- boxes 200,299,479 had wrong computation
- reordering lines to match the report
Source: https://www.estv.admin.ch/estv/fr/accueil/taxe-sur-la-valeur-ajoutee/decompter-tva/formulaires-tva.html
task-3349511
closesodoo/odoo#145328
X-original-commit: c43f34b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
If you have the backend in a language A but the website in English only,
you can:
1) modify a record's (event, product...) name in language A (say "New
Name").
2) visit the page `/new-name-11` => the server will redirect you to the
English page `/origin-11`, with the only slug that actually exists on
the website. Chrome caches the redirection.
3) give the same name in English as in language A, try to visit
=> the server now wants to access `/new-name-11`
=> Chrome uses the cache to redirect `/new-name-11` to `/origin-11`,
=> the server tries to redirect to `/new-name-11`
=> infinite loop, Chrome puts an end to it after ± 20 redirects.
In effect, Chrome injects a "Too many redirects" layout inside the
iframe, which in turn raises a CORS error when the app tries to update
it.
At the time of this commit, the flow described here should be expected
of users, because the translation UI in the backend is not clear: the
default field displayed is in language A even though the website does
not use it, and the way to update translations is not obvious (you have
to click on the language tag, which doesn't look like a button).
Another way to artificially reproduce the issue would be:
- Create a website.redirect from /dog to /cat
- Same from /cat to /dog
- Go to /@/dog
After this commit, if we detect that behavior, we reload the iframe with
a new query parameter, making the URL brand-new (and not cached) for
Chrome.
opw-3479651
closesodoo/odoo#145306
X-original-commit: 16d47ddf128f31f13e8d0d74597635faf7f9702a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Before, the websocket client was built manually, usign string
concatenation.
Now, urllib.parse() is used to appropriately adapt the database URL.
This update enhances security.
closesodoo/odoo#144303
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Current behaviour before commit:
When pressing crop button, crop widget is not getting
opened and 'connection lost' notification is appeared.
This happens because in wysiwyg.js file _rpc function
does not get the proper arguments from loadImageInfo
function.
Desired behaviour after commit:
Now, _rpc function is removed from wysiwyg.js as it
doesn't need anymore and _serviceRpc is passed directly
through the props. As result crop option works.
task-3546160
closesodoo/odoo#138482
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Steps:
- Open sales.
- Go to products.
- Create a new product.
- Keep the 'Can be sold' option unchecked.
Issue:
- If a product is not sellable then the user should not be able to create
invoicing policy 'Based on Timesheets' or 'Based on Milestones'.
Fix:
- We are raising the user error 'This option is only for sellable products.'
when a user tries to select any of these two options.
task-3378532
closesodoo/odoo#145631
X-original-commit: 94982163f81175c9d2d670dc28704a716696604f
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
- Open Project
- Go to Tasks > My Tasks or All Tasks
- Create New Task
- Create Project from Quick Create
- Clicking on Save, will give a Validation Error
Issue:
- Validation Error is raised and thus, we aren't able to add the project and
thus creating a task.
Cause:
- Due to the addition of context, the default_type_ids isn't obtained, and thus
the SQL error occurs as the name of the task stage isn't set which is a mandatory
field.
Fix:
- removing the context from the form view of Quick Create and set the stage
closesodoo/odoo#145599
Task: 3378510
X-original-commit: 83119d5de49ae69d08a0f798453d9c5c56b2276a
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Following fdb692c25b:
- when creating/unarchiving an employee, we should only create global
time-off of the same company as the employee itself
- when computing the working hours relative to the GTO, if we had both
calendar GTO and company GTO (not linked to a specific calendar), we
were not correctly creating calendar GTO; we should merge those
intervals intead of company GTO interval simply overwriting calendar
GTO intervals
closesodoo/odoo#145596
Task-id: 3619083
X-original-commit: 8ec0c6c106352c19e5c7b5613be2f610fa6e0adb
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In the `onMounted` hook of the calendar renderer, the given callback
function will schedule a new function call using `setTimeout` with a
delay of 0 if some conditions are satisfied. The scheduled function will
then trigger a scroll in the calendar view to display a precise timeslot.
If the component is destroyed before the scheduled function is executed,
the scheduled function may trigger an error as the root element of the
calendar will be removed from the DOM when the component is destroyed.
This commit will fix that issue by checking that the root element of the
calendar exists before calling the `scrollToTime` function.
Steps to reproduce the error:
1. Open Knowledge
2. Open the template gallery
3. Select the template "Sprint Calendar"
4. Quickly apply the template
=> If you have the right timing: a traceback will be displayed indicating
that the function `scrollToTime` is not defined on `null`.
TO BE: No traceback should be displayed when applying the template.
task-3627780
closesodoo/odoo#145292
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
When a tour fails, the tour system is supposed to log the failing
step (with the 3 previous/next steps). Before this commit, this
didn't work, and the first 3 steps were always logged, no matter
which step failed.
This didn't work because to determine the failing step, we try to
find the step from the list of steps, with reference matching
(steps are objects).
However, since [1], steps are obtained from a getter which calls
the steps function of the tour, so they always get a new version
of the steps.
This commit fixes the issue by memoizing the steps, such that the
function is called only once, and we keep the same references to
the step objects.
Note that this could be reworked in master to make it more robust
(e.g. finding steps based on ids).
[1] https://github.com/odoo/odoo/commit/81be42d8f9421e796087325c99aa4289d3912352closesodoo/odoo#145385
X-original-commit: 16ffd4d0bcb705c86fedd8dc7e6dd749c35eb5bc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
On deletion of records, foreign keys are updated.
For larger tables (like account.move, account.bank.statement.line) this could take some time.
adding a "not null btree index" on sparsely populated many2one fields significantly improves performance.
In the analysis of deleting a bank statement line.
Before:
7.4s to delete the bank statement line (missing index on suspense_statement_line_id consuming 99% of the execution time)
3.8s to delete the corresponding account move
After:
With the indexes, a 700x performance improvement was found.
This opportunity is taken to add an index on all many2one fields to account.move & bank.statement.line.
Issue report by @tsb-odoo
closesodoo/odoo#145643
X-original-commit: f10b87991cc72f5e16b587b6c9ede7e338ec79ac
Related: odoo/enterprise#52466
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
SG Government has announced to change the GST-rate
on 01 Jan 2024 MN from 8% to 9%
Changes:
- Added new taxes (8% -> 9%)
- Added tax groups
- Added migration script to l10n_sg to apply those changes
task-3454556
closesodoo/odoo#145686
X-original-commit: 3d406214fb226ffe3aa222c422472bcc549a53cd
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The issue:
the default currency for Montenegro is LYD (Libyan Dinar) instead of EUR
The fix:
Set it to EUR
opw-3601783
closesodoo/odoo#145668
X-original-commit: 97c57c8dbb0f6ae19619c963552552454f92da93
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Based on 50a91e0c531ec05a432cd8c468b74db27bd30985. By default
pos_stripe does the authorization and capture in two steps. This is
not supported for eftpos payments [1]. It can be supported in two
ways:
- always auth + capture in one step with the `automatic`
`capture_method`, or
- only auth + capture when manual isn't possible with the
`manual_preferred` `capture_method`
Although both could work, `manual_preferred` was chosen because:
- it's a bit simpler to figure out whether to capture the payment in
the frontend (we can just check card_present.brand),
- this keeps non-eftpos transactions the same, which is more in line
with our stable policy
For completeness pos_restaurant_stripe was updated to not capture
these eftpos payments, although this style of tipping isn't used in
Australia.
To test similar steps as in 50a91e0c531ec05a432cd8c468b74db27bd30985
need to be taken:
1/ use an Australian Stripe account,
2/ allow discovery of simulated readers by passing {simulated: true}
to this.terminal.discoverReaders()
3/ manually simulating an eftpos payment via the browser
console (necessary per payment) [2]
To be safe this also guards against the possibility of there being no
`charges` key on the payment intent. This was done elsewhere with
6a6057caf63d7e6a60dac190b2ea1ebb954d8f6a. It does seem that Stripe
rolled back this change (maybe only for Stripe Terminal intents),
because I always receive `charges` with the latest API
version (2023-10-16). Additionally,
50a91e0c531ec05a432cd8c468b74db27bd30985 has been live for 3 months
without issues, it would have caused errors if `charges` was missing.
[1] https://stripe.com/docs/terminal/payments/regional?integration-country=AU#integration-requirements
[2] posmodel.payment_methods[X].payment_terminal.terminal.setSimulatorConfiguration({testPaymentMethod: 'eftpos_au_debit'})
opw-3523604
closesodoo/odoo#142603closesodoo/odoo#145665
X-original-commit: ffddab3aa437c997fd1d63d592b47598a4bad9f5
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Joren Van Onder (jov) <jov@odoo.com>
When changing the fiscal country of the company, the country of all taxes and tax groups belonging to this
company are recomputed. However, moving taxes from one country to another doesn't make any sense since
they are part of a chart template specific to a single country.
This becomes more annoying when there are custom fields that depends of the current country in some localization.
In this case, changing the country of the company will also erased some data coming from the chart template.
At this point, the user will be forced to reload the whole chart template to recover those data.
closesodoo/odoo#145423
X-original-commit: 58393169fb51db387562baaa67e9c9ca52ed066b
Related: odoo/enterprise#52331
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
The aim of this commit is to leverage the power of the tax prediction
when possible to improve the quality of the tax retrieval of the edi
import.
Context:
The tax prediction happens when the invoice is given manually or with
the OCR but doesn't happen when it's imported by EDI because the tax is
already set by the edi.
Before this commit:
During EDI import, the tax retrieved could always be the same even if
the user make some modification to the previous bill.
After this commit:
The tax retrieved leverage the previous data to get better quality
result regarding tax retrieval.
closesodoo/odoo#145572
Task-id: 3626501
Ticket-id: 3531473
X-original-commit: 62bd397490cfcb21c2c92d67d761f68850054039
Related: odoo/enterprise#52430
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Before this commit, during an onchange, when we received an update command
for an x2many referring to an unknown record on the front end (does not
have a Datapoint Record) during the save, we sent all the contents of
these commands without removing the readonly fields.
In this commit, we're going to filter all the readonly fields according
to the backend (fields). We're not taking modifiers into account because
the command refers to an unknown record, so we don't have the data to
evaluate modifiers correctly.
How to reproduce:
- Go to a form view with an x2many field
- Edit a field that causes an onchange
- The onchange command returns an "update" command for an x2many record
which is not on the actual page (unknown record) with a value which is readonly
according to the backend
- Click on the Save button
Before this commit:
The "update" command doesn't contain the readonly field
After this commit:
The "update" command contains the readonly field
Task ID: 3607260
closesodoo/odoo#145556
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes two issues that occur when a customer has a very long
name within the `point_of_sale` module.
1. If you create a customer with a very long name, this will cause the
left panel to extend, pushing the numpad to the right, making it out of
use.
To fix this issue, we add a `mw-50` class to the container, so that we
limit its growth, and we validate the `text-truncate` class applied to
the customer name.
2. If you use the `point_of_sale` module on a mobile device, the buttons
related to main actions such as refund, customer note, billing etc are
wrapped into a `more` button. When you open that interface, if the name
of the customer is too long, it will overflow the parent container and
so generates an overflow.
To fix that issue, we simply add a `text-truncate` class to the customer
name to be sure it doesn't generate any overflow.
task-3631878
closesodoo/odoo#145531
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
The SFU is a server used to relay streaming between the participants of
a call to provide better scalability and performance than the current
peer-to-peer connections.
The required fields have been added in https://github.com/odoo/odoo/pull/138581
* `/mail/static/lib/discuss_sfu` contains the client code that is used
by the odoo client to interact with the SFU.
From: https://github.com/odoo/sfu/releases/tag/v1.0.0
* The Json Web Token code has been extracted from `web_push` while
adding support for the HS256 algorithm, to be used as the authentication
method between the SFU and Odoo.
* The python code has been updated so that the odoo server requests a
channel from the SFU when going above a participant threshold, and swap
the participants to a SFU connection afterward.
* `rtc_service.js` has been updated to support both peer-to-peer and
SFU modes.
* The `call_context_menu` has been updated to display information
relative to the SFU connection when in SFU mode.
task-2765922
closesodoo/odoo#132153
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Avoid invalidating cache when not needed.
This improves a lot performances.
Closes#143403
Fixes a bug which causes that: self.flush() and self.clear_caches() were called on every property write/update and delete.
Known at least in V14/15/16/17.
closesodoo/odoo#145549
X-original-commit: b444330050a4d98e7ade42a30a6a27522b5cf4c8
Related: odoo/enterprise#52395
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
before this commit, the pricelist concept is added in
label printing in this commit: 168b56e
and missed to adapt the zpl reports to respect the
selected pricelist in the wizard
after this commit, the price printed in the zpl
product label will be based on the selected
pricelist in the wizard
closesodoo/odoo#145518
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Test "Load 100 recipients at once" goes from 2500ms to 1200ms on my
machine.
closesodoo/odoo#145442
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
onChange on each field is extremely costly, and it's not actually used
unless the field is computed or sorted.
Time of test "Load 100 recipients at once" is divied by more than 2.
Part-of: odoo/odoo#145442
Antoine (ande)