Scenario:
- Go to Contacts
- Open a contact
- In "Contacts & Addresses" tab, add a child and configure its image
- Once child form is saved, image of the child is not displayed in the
kanban view used for children
It will only appear once the main contact form is saved.
The same issue occurs when editing a child image.
The new image will only be shown once the main contact form is saved.
The issue at the creation is due to the fact the function retrieving
the URL of the image tries to generate the URL from record id, which
is not set. It should use raw data of image in this case.
For the edition, it is due to the fact that the child form is changing
image_1920 field while the kanban view used for children is displaying
image_128 field. image_128 is a related field to image_1920, but it
does not appear in the child form. It is therefore not recomputed (by
onchange) when image_1920 is modified. Adding it in the child form view
solves the issue.
opw-2516188
closesodoo/odoo#72375
X-original-commit: 7eac23573c77415c84cb9c234c8063d4c68be425
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
The frontend enroll message was display as a `<small/>` tag, but it
seems that lxml HTMLParser parse it wrongly, for example:
html.tostring(html.fromstring('<small data-oe-model="test"><p></p></small>'))
returns:
'<div><small data-oe-model="test"></small><p></p></div>'
So branding attributes like data-oe-model that are on small tag are not
found on root node that has become a `div` tag after parsing => this causes
a traceback error when saving a change in this part.
Fix: use small as wrapper for `<div/>` tag that is treated correctly by
HTMLParser (span is also treated correctly but div makes more sense
here).
opw-2573955
closesodoo/odoo#72315
X-original-commit: 6334c7282c19362ca8bc79dbaefe3d38c055e746
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, when editing a mass_mailing template, on save,
the editor would not tell the snippet menu to perform a cleanForSave
which it should normally do for the option to properly prepare to save.
Bug discovered while working on task-2327045
Ideally, would need to be backported but requires a different fix in the
old editor.
closesodoo/odoo#72346
X-original-commit: 639b6a55586107bd3d855d322c1102df101eb079
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit fixes the case when the reconciliation never ends due to an infinite loop.
This happens when we attempt to reconcile two journal items having differents foreign currencies but an amount_residual = 0.0.
In that case, partials are created everytime with zero amount, zero debit_amount_currency and zero credit_amount_currency.
We don't need to handle such reconciliation because exchange difference journal items are always created using the same foreign currency as the originator line.
The way the reconciliation is made for reversal moves is also edited by this commit to avoid reconciling lines on the same moves but with different currencies.
closesodoo/odoo#72266
X-original-commit: 1231d54b8c2084db6ffb9551af7ed4ee9e31a95a
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When adding a section or a note on an invoice, default taxes are set on
the account move line, making the corresponding Tax Group to appear on
the invoice.
opw-2541722
closesodoo/odoo#72337
X-original-commit: a8d3f466dfffca08214acecf08ec298e3ace6272
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
- Change an image option in mass mailing editor (e.g. Quality)
- save
- edit -> The option can't get the new applied value.
The body_arch's field used in mass mailing editor is
sanitizing attributes and as a consequence, option related data
attrs are removed on save.
task-2327045
closesodoo/odoo#72311
X-original-commit: 7c5666611363a73bc6fef070565039cf065a0176
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- New and multiples pictures
- Empty URL instead of odoo.com by default
task-2471323
closesodoo/odoo#70528
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, the implementation of Ogone and PayU Latam's
requirements regarding the transaction reference was preventing the
computation of the reference prefix from being based on the related
document (invoice, SO).
This commit attempts to compute the reference based on the document if
no reference prefix is provided, before applying the said requirements.
task-2494916
closesodoo/odoo#72291
X-original-commit: f18a1d67b769ea69a07fb3c0343e092038df5c93
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Bug
===
1. Create a new database from the database selector
2. Do not select a country for your company
3. Install CRM
4. Create a new opportunity and select your company
5. The sync "warning" will be displayed, and it should not
The reason for that is the phone of the company is an empty string and the
phone of the lead is False. So we try to sync them and we show the warning
message even if for the user, nothing will happen.
This commit fixes that behavior by correctly checking that False / empty
strings are considered as equal.
UPDATE
In this commit we also display warnings about update only in edit mode to
avoid displaying irrelevant information to the user. Indeed email and phone
will be propagated at save, aka in edit mode.
TaskID-2499659
closesodoo/odoo#72286
X-original-commit: efea8fce6c7cb6e40b590cd827fe22e134cc3d13
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since _filter_included_tax_company filters the taxes of other companies,
there is no need to give taxes from other companies if the filtering was
already done.
closesodoo/odoo#71591
Related: odoo/enterprise#18670
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since product can be shared between multiple companies, their taxes m2m
fields may hold taxes from multiple companies. When working in sudoed
or multi-company environments, those taxes were incorrectly filtered and
taxes from other companies may erroneously impact records from other
companies.
This commit ensures that the product taxes are properly filtered to only
consider the ones from the current/record company.
Passing an id directly to `search_view_id` is not working. It is silently
ignored.
The framework js code expects an id/name pair, as described in the ORM doc.
Most of the time, this will be unoticed as the specified search view being
ignored, the default one will be used instead, which is often the same one as
there is only one search view.
Only 3 occurences are real misbehavior.
Note that the `name` of the pair is useless, you can just pass the ID in an
array.
Working:
'search_view_id': [123, 'search'],
'search_view_id': [123],
Not working:
'search_view_id': 123,
closesodoo/odoo#72247
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Until now, when you create a view of type qweb with a model, we use the model
as first part to generate the key. Since this model can contains dot, it is
wrong and we got some key like ir.ui.view.gen_key_xyz
This bug has been seen with commit ee8756b311
which make the installation of website & sale_timesheet impossible in dev mode.
File /home/odoo/addons/base/models/ir_ui_view.py, line 294, in _compute_arch
arch_fs = get_view_arch_from_file(fullpath, xml_id)
File /home/odoo/addons/base/models/ir_ui_view.py, line 166, in get_view_arch_from_file
module, view_id = xmlid.split('.')
Too many values to unpack
Now we never try to make key beautiful. At first view it doesn't bring any
advantage, but only bug.
closesodoo/odoo#72238
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
When a serial number SN is trying to be consumed and has been unbuilt in the past,
an evaluation is used to check that the # of times SN was unbuilt is equal to
the # of times SN was consumed. However, when counting the unbuild SN it did not take into account if
it was from an unbuild order.
opw:2510294
closesodoo/odoo#72272
X-original-commit: 47d6ff49b19e68d84a68d8c4b999cb6115398805
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Purpose is to have sponsors always behaving like other website records, aka
not published are not displayed. It allows manager to create sponsors without
having them displayed on frontend while not completely ready to do so.
Add field in search as well as in form view, allowing to better distinguish
sponsors ("display in footer") from exhibitors (classic website published
button with redirection to frontend page).
Task ID-2558875
PR odoo/odoo#71787
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Choose lowest sponsor type as default when creating a new sponsor. Purpose
is to avoid being blocked by required fields. Choosing the lowest available
sponsor type allows to ease discovering the feature without breaking any
feature.
Also set a default sequence when creating a sponsor type to avoid jump
effect on list view: always send new sponsor types at the end.
Also set default ribbon as no ribbon to avoid a "void" entry in ribbon style
when creating new sponsor types.
Task ID-2558875
PR odoo/odoo#71787
When confirming a sale.order that includes a product that is either an
event registration or an event stand it shows the event edit registration
wizard which has no sense for the event stand part.
Fix the event_configurator_tour since the autocomplete showed the wrong
product at the first place.
The test was based on the event_id field of the sale.order.line but should
be based on the event_ok field instead.
Also add more text to the tour so the autocomplete shows the right product
at first place.
LINKS
Task ID-2318655
Task ID-2558875
PR odoo/odoo#71787
Before this commit, the number you saw on the stat button was not always
the same as the number of sale order you would see when you clicked on it.
Indeed, there was a domain force on the action to only show confirmed orders,
while the stat button was counting quotations too.
Fixed#70911closesodoo/odoo#72249
X-original-commit: 79afc80e5b4f45c6bc716f55a21f8a2b478e49f6
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Steps to reproduce the bug:
- Go to Elearning > choose any course or create a new one
- Click on “add content” :
- Add a title to slide
- Click on "Go to Website"
Problem:
An error is triggered because we call the "create" method to save the slide, which tries to access the “channel_id”, the course ID in which the slide will be added. However, the field is not set in values.
The "create" or "write" function in "slide_channel" must first be called to save the course, which will then call the create function in "slide_slide"
Solution :
Hide the "Go to website" button as long as the course is not created and therefore has no id
opw-2526541
closesodoo/odoo#72199
X-original-commit: e412ba4898e35c8519adafb05407bdb78f311c09
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
The link preview is a bit messy inside a mega menu.
Hiding it during typing clears the UI.
task-2566651
closesodoo/odoo#72009
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When computing the foreign key name,
`check_foreign_keys` didn't take into account the limit of 63 characters
for constraint names.
Because of this, some constraints were dropped and recreated
over and over while they were correct, during install and upgrades.
For instance, when installing `base`
when adding the foreign key for which the name was computed
`base_partner_merge_automatic_wizard_res_partner_rel_base_partner_merge_automatic_wizard_id_fkey`
Postgresql created the constraint under the name
`base_partner_merge_automatic__base_partner_merge_automatic_fkey`
and therefore, as the name did not match,
the constraint was dropped and re-created.
closesodoo/odoo#72234
X-original-commit: 43a4738ebf8a74a389b99f8f58330b3044beaa0c
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The printer dialog was not shown when going through the manage order if there
was no printer connected.
In order to fix this issue, the tryReprint doesn't check anymore if a printer is
connected or not. It'll print via printer if connected or show the the printer dialog.
closesodoo/odoo#72230
X-original-commit: 7a7aacedde81998ec0f1a7f3283337236e56de42
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
The commit e123aa2f30 optimizes the call
to fields_get() made in the NameManager to post-process the combined
arch of a view. The optimization consists in avoiding translations,
with the assumption that the result is only used for validations. It
turns out that the regular post-processing actually returns the field
descriptions as part of the result of fields_view_get().
We fix this mistake by keeping the optimization only when the flag
'validate' is true, so that the regular post-processing of a view
returns field descriptions with the expected translations.
closesodoo/odoo#72216
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When changing the color of the header with the custom colorpicker and
saving the changes, the autohideMenu widget was destroyed before
finishing the rendering.
The commit fixes the destroy method of this widget, testing if the
variables are defined before using them.
task-2519545
closesodoo/odoo#72193
X-original-commit: c003c8d0620c6eda8f8b482d7519ca00a3007d03
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The background color displayed on the blog posts list page was static,
instead of being the background_color_class saved from the
CoverProperties. Also, on the blog post page itself, the two were
combined which made no sense.
Part of https://github.com/odoo/odoo/pull/71593
task-2497846
closesodoo/odoo#72186
X-original-commit: b3ebc427fd519c29788eadedfca2f956e3695a3e
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit fixes a bug happening when changing the background with the
CoverProperties SnippetOption from the blog posts list page.
As it selects the default sizing class and applies it, the min-height
css property was applied and breaking the layout.
The covers min-height is now set as !important to not be overriden in
that context.
Part of https://github.com/odoo/odoo/pull/71593
task-2497846
X-original-commit: aa9591bf546729162f44d1f34cbee094131aba73
As [1] added `!important` flag on .o_full_screen_height and
.o_half_screen_height global classes, the current override in
website_blog was not effective anymore.
Also, the value of the height override is also changed to offer more
differences. Also, simply restoring the old rule would "restore" 13.0
databases but "break" 14.0 databases which relied on it. So a compromise
between both was chosen.
[1]: https://github.com/odoo/odoo/commit/7cc6fdf36569be85e995c962321f2926822ac604
Part of https://github.com/odoo/odoo/pull/71593
task-2497846
X-original-commit: 3929eece7face5f6ed497a119787cd841b917c08
It is not possible to define a working time that lasts a whole day. This
can lead to calculation errors.
To reproduce the error:
(Need mrp,hr_payroll)
1. In Settings, enable:
- Work Orders
2. Create a Work Center WC
- Working Hours: <Create and Edit>
- 2 shifts:
- Monday, From 0 To 24
- Tuesday, From 0 To 24
3. Create a routing R:
- Add an operation:
- Work Center: WC
- Default Duration: 1440 (i.e., 24h)
4. Create a Bills of Materials BM
- Routing: R
5. Create a MO:
- Bill of Material: BM
- Plan From: Next Monday
6. Save, Mark as ToDo, Plan
Error: Since the operation should last 24 hours, the end time should be
the same. However, the Planned Date field is incorrect: the end time is
one minute too late. This error is even more noticeable when increasing
the quantity to be produced.
On step 2, when setting the 'Work to' field to 24, it automatically
becomes 23:59. The first consequence is directly observable on working
time form: we should have a total of 48 hours/week but the current total
is 47.98 hours/week. Another consequence is the end of the planned date
(as described above).
OPW-2462094
closesodoo/odoo#72210
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The skip button of the configurator's first screen has been moved beside
the 'let's do it' button for more visibility.
task-2518565
closesodoo/odoo#72191
X-original-commit: e6871f1991a951391fe1942f86ed208385d31b38
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Sébastien Mottet <smottet@users.noreply.github.com>
Consider the following example:
1) Create tax ONE, 10%, include_base_amount=True
2) Create tax TWO, 20%, is_base_affected=False
Create an invoice with just one line of 100€, with taxes ONE and TWO (in this order).
The journal entry then contains:
- The payable/receivable line => 130
- The base line => 100
- The tax line for ONE => 10
- The tax line for TWO => 20
The bug this commit fixes concerns the tax_ids set on tax lines. In our example, none should be set, since tax TWO is not affected by ONE. But tax line for ONE actually had tax_ids=TWO, hence impacting TWO's base. This was wrong; the base for TWO is 100, not 110.
closesodoo/odoo#72063
X-original-commit: ff2d1728c835e7d43638502d69245291d0fa3c59
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
In fb556ed09c7e the middle vertical line is removed from the timeline
widget because the display was changed to table.
We need display:block so this commit override the value (adding
"height:100%" also fixed it but not for all browser (eg. in safari)).
opw-2558670
closesodoo/odoo#72198
X-original-commit: 7971bcc3ed2c14254b089a6871d151952b4c4d62
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Without this patch, each time the compute reaches the line with `.filtered()`, it needs a new fetch from the database. With too many sale orders, this becomes a bottleneck.
Now, before getting to that line, Odoo knows that it'll need all sale.order.line records, so it can fetch them all at once.
In a production database, loading the sale.order list goes down from 7s to 500ms with this patch.
@Tecnativa TT30390
closesodoo/odoo#72141
X-original-commit: 7969a052a19f3572e4819d163f969ae02bc8a80e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Traces are always linked to documents as mailings are sent on
documents. Those fields should be required to ensure database
coherency.
Task ID-2525759
closesodoo/odoo#71786
Related: odoo/upgrade#2513
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Overall purpose of this merge is to add some tests on activities notably
about ACLs and access to records.
See sub commits for more details.
Task-2272475
closesodoo/odoo#71131
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds a little label on the top corner of animated shapes
previews.
Part of #70843
task-2319488
Related: odoo/design-themes#17
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
1. Change some shapes to apply correctly the color presets:
e.g. the default color of the shape erased the background
color of the preset.
2. Improve some shapes to have a better render by changing
the colors and/or adding animations.
3. Some svgs could give the same result. To have a clean list,
many svgs were combined.
4. Letting the old svg files to assure the compatibility with themes.
5. Improve the preview of some shapes for a better reading.
Part of #70843
task-2319488
The goal of this commit is to add a new page to the shapes
(Floating shapes) and new animated shapes in the current
categories.
Colors should be, as other shapes, linked to the theme.
Part of #70843
task-2319488
Right now, for notifications handled by odoo (which are being displayed on
discuss app / object chatter), few of the buttons have unexpected scroll
(mostly the CTAs that redirect to record / portal views) and ruins the UI.
This commit fixes the issue by improving such templates by using proper
paddings on the button.
TaskId:2518863
closesodoo/odoo#70083
Related: odoo/enterprise#18225
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Variable `mutations` may have thousands of records. Using `.push(...mutations)`
would lead to error
STEPS:
* install website_sale
* create many categories:
```
for x in range(0, 4000):
env['product.public.category'].create({'name': str(x), 'parent_id': 9})
```
* open /shop
* click [Edit]
BEFORE:
```
Uncaught RangeError: Maximum call stack size exceeded
```
---
opw-2515707
closesodoo/odoo#72169
X-original-commit: 853a2cab3f896e99d5a4c498eea6ebf02e787b94
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When a view is created/modified, it is required to validate it, the
validation checks the syntax, the inheritances, the fields, etc. When a
view is rendered there are a few more steps to perform like to (dis)able
the `edit` button from a view form if the user only have `read`
accesses. Those postprocess are useless when the view is validated and
should only be performed when the view is rendered.
closesodoo/odoo#68469
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
This is a pure technical fix, computing `view.xml_id` is only needed
when there is a problem with the view. Computing the `xml_id` is not
free, as it needs to be retrieved from the database. During a regular
installation, there should be no problem, the view is validated without
errors or warnings.
Aaron Bohy