E.g. the scrolltop button option has a checkbox followed by a select
on the same row and the checkbox was partly cut because of it.
Part of https://github.com/odoo/odoo/pull/60271
task-2312878
X-original-commit: 70570c69989b49b8ab89d71ea89d19195e3028ae
Before this commit, line height on items in a select was not applied
if the items were in a we-title tag (this is the case when using the
string attribute on we-button instead of text content).
Part of https://github.com/odoo/odoo/pull/60271
task-2312878
X-original-commit: d184004c846234ecd9d9924c0e37472c03633f5c
Issue
- Install "eCommerce" and "Inventoy"
- Activate "Fedex" delivery connector in settings
- Publish "Free Delivery" and "Fedex US" delivery method
- Put the "FedEx" one above the "Free Delivery"
- Go to shop and add an item to cart
- Set an adress with no ZIP code and checkout
- Select a payment methode and pay
Order is generated without selecting a delivery method
Same behavior happend when using only "Fedex" as delivery
method.
Cause
The flow make the `payment.payment_form` trigger start after
`website_sale_delivery.checkout` JS module.
In 'start' function of `payment.payment_form`, the `disabled`
attribut is removed from button if no checkbox_cgv is present
and therefore break the `disabling` managemet since
`disabledReasons` payButton data are not sync anymore.
Solution
Remove 'disabled' attribut only if has `disabledReasons` data on
payButton (checkbox_cgv feature alter `disabledReasons`).
opw-2355407
opw-2357605
closesodoo/odoo#60359
X-original-commit: 04e589e80b3ef48640f275cb20d31c17c2126c69
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Steps to reproduce the bug:
- Activate Margins in Sales > Settings
- Go to the pivot view of quotations
- In Measures, click Margin (%)
Bug:
Margin percentages are aggregated by computing the sum of the margin sub-percentages instead of using the data of the aggregated row (i.e. agg. margin / agg. total).
Explanation:
This is one of the flaws of the pivot view. The best way to solve this would be to create a custom aggregation in PostgreSQL.
This commit is just hiding the measure for now.
opw:2349896
closesodoo/odoo#60354
X-original-commit: 1e3fc6894b13d51a3f6327653afbf8d5a316a21d
Signed-off-by: backspac <backspac@users.noreply.github.com>
Issue
- Install 'Dashboard'
- Try to add something to the dashboard via 'Add to my dashboard'
- Enter custom name
- Click on 'Add'
Cause
The name of the action was taken instead the input content
Solution
Take the input content
opw-2363000
closesodoo/odoo#60352
X-original-commit: 933ef22ede27280d34ccf4ce2e172c8207ca2074
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
In a POS session, in a language that does not use dot (.) as decimal separator (i.e. French),
when adding a Product, it can happen that the decimal part of the price is not converted
correctly after applying "field_utils.parse.float". (i.e. 2.69 becomes 269)
The issue happens in "set_unit_price" function.
To prevent this to happen, "field_utils.parse.float" will only be applied if the price given
as parameter is not a number.
opw-2357848
closesodoo/odoo#60344
X-original-commit: 7687732a8a2e1afe87272fc31ccd4437ed9a8db1
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Current behavior:
call to _file_read() within "for attach in self:" loop references self
rather than attach
Expected behavior:
execute _file_read() individually for every record in self (via "for
attach in self:" loop)
This is not an issue in standard where _file_read is an api.model
method but in case of overwrite (e.g. issue reported at
odoo/odoo#60016 has implemented an AWS integration) it makes sense
closesodoo/odoo#60342
X-original-commit: 160043a4f6aa76010aa77ead7cace9a688c17ae8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this change the rollback hooks were never called since rollback() was never explicitely called by the framework. At the end of a transaction, if no error occurs the famework call commit() on the odoo cursor. In all cases, the transaction ends with a call to close(). Into the implementation of _close() rollback() is called on the underlying connection to ensure that not committed changes are rollbacked. That's the reason why despite the fact that rollback() was not called on the Odoo cursor, changes are not committed into the db in case of exception. To keep the same behaviour and avoid to have to explicitely call rollback() on the odoo cursor to trigger the execution of registered rollback hooks, these hooks are now processed in _close(). Since the list of registered hooks is emptied if commit() is called, we are sure that rollback hooks are only executed in case of rollback.
OPW #2294911closesodoo/odoo#60339
X-original-commit: dce9a05f3a5d37fab711c8ca3c5444941f98e814
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
The button text colors were forced to the default link color while that
color should only be forced for links which are not buttons.
Note: this fix will not impact existing mail templates thanks to
transcoding. That's why it is possible to fix safely in stable versions.
Part of https://github.com/odoo/odoo/pull/60308
opw-2360756
closesodoo/odoo#60308
X-original-commit: 3d8c6eca5ffa657485bdf4bec84c07b4f978a71d
Related: odoo/enterprise#14217
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Primary and link buttons are "hacked" by mailing themes scss. We thus
have to fix their preview if possible (as they are previewed as standard
bootstrap while they actually have a different look depending on the
mailing theme).
Note: this commit is obviously a big hack which calls for lots of
improvements in master.
FIXME: this only partially work due to the new editor, it has to be
fixed as soon as the master becomes stable again...
Part of https://github.com/odoo/odoo/pull/60308
opw-2360756
X-original-commit: 7bd7bc2513b72f5ffc006758c4bf4eb42ae6ed67
This commit enables eLearning users to share the channel linked to
certification they cleared directly from the result page.
Notes:
1 - We already have the option to share a certificate from the user info page
or from the slide page, and the same mechanism has been utilised here.
2 - With a recent commit[1], top padding was added to the modal opened on
website front-end to prevent modal overlapping the navbar. But it caused
a side effect on survey result page, where navbar is hidden. So we remove
this top padding on modal for the survey result page.
[1] - https://github.com/odoo/odoo/commit/6ef622772f7d0172553aca6dbce9eb71855460d7
taskId - 2337696
closesodoo/odoo#58104
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If you want to prevent pad creation without the API key, you configure
the etherpad server with the 'editOnly' parameter set to 'true'.
In this case (copy/pasting the settings.json):
* users may edit pads but not create new ones
* pad creation is only via the API
But if you secure your etherpad server like this, you won't be able to
create pads in odoo in certain circonstances.
This use case does not work (using 'pad_project'):
* secure your etherpad server ("editOnly": true)
* open the Project app and choose a project
* open an already existing task (or create one)
* from this task, click on the "Create" button to create a new task
* the 'description' field displays: "You do not have permission to access this pad"
* if you save, you'll get a traceback: "ValueError: padID does not
exist"
The same issue arise if you create a task from the list (not kanban)
view.
If you create a task directly from the kanban view, there is no
problem because there is an 'object_id' in the context dict.
closesodoo/odoo#60333
X-original-commit: 8ffc00fb2a88dbf2c340b6e7fc48ae137464e59d
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, top and bottom padding were not the same in the
items snippet. We also removed horizontal paddings on the section to
keep the snippet columns aligned with other snippets.
task-2312878
closesodoo/odoo#60307
X-original-commit: 22a9a3de3c205709597ab95d8987466bd5579c86
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The widget is intended for informative fields only, i.e. the
fields do not need to be editable. It is not the case for the
date_deadline.
closesodoo/odoo#60317
X-original-commit: a455999588053d528cc779b070cac31ab3b273df
Related: odoo/enterprise#14223
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The `remaining_days` widget is intended to be used for informative purpose,
hence it should not be editable.
opw-2362276
X-original-commit: 4c72b1536a19cd517046113a5ad93b5782774664
This solves an issue with svg images from Isometric for example. The
media dialog assigns width to its displayed images thanks to the
flex-basis and flex-grow properties of their container, based on the
aspect ratio of each image. This was done correctly for SVG images too.
However, after assigning a nice space for a specific SVG image, the
image itself was not made to fill that assigned space... it only worked
if the natural width of the image was higher than the assigned space.
This was of course more obvious with SVG files with no intrinsic width
as they would simply not appear.
closesodoo/odoo#60305
X-original-commit: 585aed8b49b98d014db1e06c11e42b0d38a0b8c6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Changelog:
[IMP] Resizer: prepare for use of Resizer in Odoo
[FIX] FollowRange : constrain floating bar inside the visible viewport
closesodoo/odoo#60267
Related: odoo/enterprise#14201
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
There is no plausible case where "print QR-invoice" button is needed
on Credit Note form view.
closesodoo/odoo#60311
Task: 2351817
X-original-commit: c4ac11aa9bdcb690d9dffbd1759d68ba4398dbb5
Signed-off-by: jbw-odoo <jbw-odoo@users.noreply.github.com>
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Issue: Add dynamic carousel in the page, then change the footer template,
then reply "Yes, I want to save & reload", then the page is broken because
the new class and data attributes are not saved.
closesodoo/odoo#60077
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Behavior before the fix:
- if you create a sales order for a customer invoice address (a child
partner record), then create the invoice for that order, the partner_id
is not consistent between the move_line (some get the child partner id,
some get the commercial partner id = the parent partner id)
- if you create the invoice directly from the accounting app for a
child partner, the commercial partner id is used consistently for all
move lines (the invoice itself keeps the child partner id)
Behavior after the fix:
- when an invoice is created from a sales order, the partner id is set
using the commercial partner id, consistently for all lines (in this way
the behavior is consistent with that of the accounting app)
It is more appropriate to use the commercial_partner_id for this purpose
as it is used pretty consistently in the account_move file
opw-2347878
closesodoo/odoo#60302
X-original-commit: cd299518ae45f2732d47788869b013be16b814e8
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
When you hava a fiscal position that that map one tax included into the
price to another, the new amount is wrong.
I we have a fiscal position that map a tax of 10% included to 20%
included, and a product at 110$ having 10% included. When we map the tax
from 10% to 20%, the new price is 100$ but should be 120$.
This is because for now, the price is fixed to get the amount without
tax, which perfectly works when destination tax is tax excluded. But
when you call compute_all from a price with a tax included (20%) it keep
the price and compute the tax amount out of this price.
So to fix this issue, whent the origin tax and destination tax are
included, we are computing the base amount (like before) and then we
compute the new tax amount wihtout trying to find the tax amount out of
the price.
This will lead to have the same behavior between accounting and POS
closesodoo/odoo#60312
X-original-commit: f8737b4676ea86abc0f39e448849453f28d4b10f
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This way the PCN874 report is already there.
Existing databases will need to relink the taxes
with the report however.
closesodoo/odoo#60295
X-original-commit: 6963f58d1c23065eec440d5be23c93f73c24b3bd
Signed-off-by: Josse Colpaert <jco@openerp.com>
In mass mailing (_sms) when you set `Mailing Contact` as target model the
`opt_out` field is added to the default domain. However as it is a computed
field depending on a single mailing list given in context it should not be
used that way. Moreover current implementation raises a warning as only some
custom views can use this field accordingly.
This commit removes `opt_out` field being set by default in mailing domain and
also removes the UserError raised by the search function, thus avoiding
unwanted warnings.
Opt-out field is automatically taken into account when sending mass mailing on
contacts (see ``_get_opt_out_list``) so removing it from domain is actually
even better for coherency. Opt-out is not an option in sending process.
Task Id-2300427
PR #57310closesodoo/odoo#60262
X-original-commit: 5ccf5b51feaa348d775890e107fd30cd750699d8
Related: odoo/enterprise#14200
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Avoid filtering/checking the same condition multiple times on the same
records...
This allows to avoid n more fetch of all applicable coupon programs from
the database (because _check_promo_code is called on each program in a loop).
Also apply the date filter directly in SQL:
* The computation of inherited fields (_inherits) by the orm is intrinsically slow.
The fields rule_date_from and rule_date_to checked in the _filter_on_validity_dates
python filter are inherited from sale.coupon.program.rule model.
* Filtering recordsets in SQL is faster.
closesodoo/odoo#60292
X-original-commit: 679ebc3381179f6b18364c6f2b4d4f7f34274698
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Use set instead of recordset to incrementally join records
* avoid filtered and mapped calls when possible
* use generators correctly
sum([gen]) --> sum(gen)
X-original-commit: d3daa3793b8fbc9308ec0fb8935d6991b834f3a5
Co-authored-by: Loan Sens <lse@odoo.com>
_get_applicable_no_code_promo_programs always returns a subset of
_get_applicable_programs ...
We can thus avoid summing the results from the two methods, which
triggered unnecessary operations and resulted in a recordset with
useless duplicates...
Furthermore, as _get_applicable_programs returned recordset is only
used to compare to other recordsets (substraction or comparison),
it doesn't need to be sorted by the model order. We can thus
safely order the result by id instead, to reduce the query complexity.
X-original-commit: 5d45322cb6abb689dd15566e938fe75318dfdc4d
When coupon is installed, all cart (SO) updates on the e-commerce go through
the _remove_invalid_lines method. It has been proved to be a performance
bottleneck on big instances with a lot of coupon programs.
To reduce the performance impact of this method, this commit reorganize it
to avoid unnecessary operations as much as possible.
X-original-commit: 447057cfbe28db760834fba2dfd2c79303825cbc
Co-authored-by: Loan Sens <lse@odoo.com>
Instead of summing the programs filtered by "current_order" and
"next_order" usage, use all the programs directly.
We can safely assume that the promo_applicability is always set, and if
not, the code later should still behave correctly considering it wasn't
verified in the other methods.
This allows us to avoid two "useless" walkthrough on the coupons applied
on the current sale order.
X-original-commit: cc74ad0108e47654f4a795556f03841319909c67
If only one of the two dates rules fields is specified, it won't be considered
when filtering coupon programs, and the program will always be considered valid...
This commit reorder the conditon to correctly consider both fields: rule_date_from
and rule_date_to, even if only one of the two field is set.
X-original-commit: 871a118d2c72f58185cbf822375282b613e67337
A check on the company_id field was forgotten in _get_applicable_programs.
To follow the logic of the following method _get_applicable_no_code_promo_program,
this condition is added to the domain, ensuring coupon programs from other
companies cannot be applied to a sales order.
X-original-commit: 559f1e96e17fadad82261eb32a5d02aa5fe91ca9
Create a Server Action with the following code: `raise Warning("")`,
when the SA is executed it opens the crash manager with a traceback
instead of the user error modal.
The `odooExceptionTitleMap` data structure lists all Odoo exceptions
that descend from UserError, this structure is used within the
`rpc_error` function to filter pure Python exceptions from custom Odoo
ones.
opw-2365689
closesodoo/odoo#60275
X-original-commit: 7058e338a980268df1c502b8b2860bdd8be9f727
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Steps to reproduce the bug:
- Install web_studio, contacts
- Activate language English (UK)
- Switch all users' language to UK
- Deactivate language English (US)
- Via Studio, add a related field to a contact: Self > Language
Bug:
Traceback: contacts still have en_US as language and it's deactivated.
opw:2350362
closesodoo/odoo#60279
X-original-commit: 47ec3585f50f030025b39031807be50a9299bcd6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>
Any non `<span/>` element which was transformed into an icon thanks to
the media dialog was transform into a `<span/>` then processed by
summernote. In some cases, this processing breaks the DOM... for no
reason as the DOM should not have been transformed into a `<span/>` in
the first place: `<i/>` elements inside a `<span/>` for example should
stay `<i/>` elements after edition.
closesodoo/odoo#60202
X-original-commit: 4bfcb80e3664ccc74b7ec5e7e10ace6e44ab98d3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The problem comes from how a language handle things like "Last week,
last month, last year".
For example, in Vietnamese, the "last" come after the week/month/year
instead of doing before like what is in English
closesodoo/odoo#60263
X-original-commit: 6eb9dddb9fae117d51d0ae4ca47c01846c9030a3
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When a user can edit it's employee, the field expense_manager_id is
editable but any value is ignored, and the previous manager is forced.
closesodoo/odoo#60261
X-original-commit: 41f73fe92139811bc1f43ea07ca4539768001ae5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
qsm-odoo