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>
Use case: website_event_track(_online)
======================================
On sponsor model, image_128 field is defined in website_event_track module as
computed stored Image field. It means that when this binary field is set, an
attachment is created in ir.attachment model -> attachment is set to True.
In website_event_track_online module this field is modified. It is set as
a related (resized) version of image_512 and not stored anymore.
However attachments still exist in ir.attachment table for sponsor records.
This is not an issue when trying to access the image_128 field using the ORM
as the compute (or related) is correctly called. However '/web/image' does
checks if the field has an attachment and loads it. In our case old attachments
still in database are therefore displayed instead of the new related image.
Fix
===
When checking for an existing attachment in _binary_record_content we also
check that the field is not a related. This fixes the current issue. It also
makes _binary_record_content work as the ORM, aka using the computed value
and not any stored information.
DB Cleaning
===========
In 14.0 a script will be added to clean existing attachments for sponsor
model. Indeed there is no need to keep unused attachments. Especially in
14 website_event_track_online has been merged in website_event_track, meaning
only existing db have to be cleaned. New DBs will never have this attachment
issue as the field is always computed.
Task ID: 2341108
closesodoo/odoo#60259
X-original-commit: ada1eab338c6cffb526b03377ec01962f9c26c4c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently the onchange is setting the price_unit to the price_subtotal to work out the proper price unit related to the tax, but does not have a different line quantity in mind.
The update of the price_unit was raising a balance difference UserError which is now resolved by the fact that we only update the price_unit if it is affected
OPW-2362066
closesodoo/odoo#60256
X-original-commit: 8c8d803992c31ba68a12801fa6dd4dcf909d9ed9
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Introduced at 2f67881d45
Taken an event with
start_date: 2020-10-01
stop_date: 2020-10-02
allday: True
The date was displayed as "01/10 - 03/10 (2 days)" instead of "01/10 -
02/10 (2 days)"
closesodoo/odoo#60254
X-original-commit: 5eed28cf927bc504b103cc872712ab0e49830a38
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In the compute of forecasted information of `stock.move`,
instead of using the warehouse of the picking type, use
the warehouse of the source location (if there is).
X-original-commit: ffd447f734e7688a1954d428bfe14c8edfd4ada1
In One2many tree of stock.move, the forecasted button trigger
a traceback in case of new line because there isn't a target record.
Also, don't show forecasted information when the state of the move
is 'cancel'.
X-original-commit: a1285d16ff32fb31f202ebe01a6afa83e14b9c14
Before this commit, It was refering to non-existing decimal precision "Product UoS" which doesn't exists since odoo 9.
Followup on d152106b1bclosesodoo/odoo#60235
X-original-commit: 9199bd588109330344aa505c5930f127a3920f5e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Issue
- Install "Project" module
- Active "Sub Task" feature in settings
- Create a new project `X`
- Go to settings of project `X` and activate "sub task" feature
- Add a Task `A` in project `X`
- Add a subtask `B` to task `A`
- In menu, click on `Tasks` to list all tasks
- Edit view and add `subtask_count` field then save
Wrong value in `subtask_count` field.
Cause
Retrieving childs of self instead of "current" task (`for task in self:`).
Solution
Use "current" task instead of self.
opw-2361013
closesodoo/odoo#60230
X-original-commit: c961638d49a392468ac4a521bcb208dd9d68a99d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, links to the documentation were referenced the
previous version, 13.0, instead of the current one, 14.0.
Eventhough there is a redirection done by NGINX of a "versionless" URL
to the latest one (e.g. /documentation/user/general/auth/google.html
-> /documentation/user/14.0/general/auth/google.html as of today), the
goal is to keep links owrking for users that will still be using the
14.0 in three years (and should not endup on the 17.0 doc).
closesodoo/odoo#60228
X-original-commit: 7ac08486d91d0ff0151abeeda057ffa6beda72e8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
With this commit, pylint will now point out when the same
function/class/method is defined more than once in the same scope which
is a recurring mistake.
closesodoo/odoo#60044
Related: odoo/enterprise#14090
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
This commit adapts the business code in which
class/module/function/method redefinition took place so that it no
longer happens and the pylint test passes.
Before this commit, `journal_id` field was not required on model/view, Creating record without `journal_id` is not allowed since it is required on `account.move`.
Now field is required.
closesodoo/odoo#60146
X-original-commit: 7fbdfba8cbeb2ed724f2493320a5f609d07dca97
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This commit adds a constraint on model stock.warehouse.orderpoint
(reordering rule) to ensure two orderpoint are not set on the same
product and on the same location. This is an issue as the replenishment
will be done multiple times in case of duplicated rules.
Task : 1939567
closesodoo/odoo#47909
Related: odoo/upgrade#1814
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The test fails when running tests with a non-standard http_port (which
is necessary to run tests in multiple Odoo instances concurrently)
because the http port is hard-coded.
Soft-code it properly.
closesodoo/odoo#60192
X-original-commit: 3ab87ade4274600a2d97708e54436db162b68547
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The method _to_action_data needs to retrieve the action as sudo to be
able to read it's content.
Before this commit, an access right error was raised when a user
clicked on the "Overview" button on the project kanban, when trying to
read the content of the project.action_view_task record
closesodoo/odoo#59974
X-original-commit: 80c87e2562681ca95fa9c6c91e6564c8ad8f1cb5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit remove the unclear message from the 'Contact Us' page,
as it could only appear when the google map option is not enabled.
task-2346193
closesodoo/odoo#58479
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Benjamin Vray