1. Install eCommerce
2. Enable Pricelist settings
3. Choose a product P and enable it in the ecommerce view
4. Create 2 pricelists, for P with:
- PL1: One with "Benelux" as country group with a price of X
- PL2: One with a price of Y
5. Assign PL2 to the portal user (Joel Wilis) through "Website > Customer"
6. Connect as the portal user
7. Go into the ecommerce page of the product P
The pricelist PL1 is used instead of PL2, this occur because
geoIp localisation take priority over customer assigned pricelists.
Fixing filter by allowing pricelist with no country defined to be used
opw-2242152
closesodoo/odoo#51115
X-original-commit: aab3c03b2bdab97796e678d3f876ff64d5ecc4d9
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
The properties must always be accessed using the company of the journal entry defined by
its journal.
closesodoo/odoo#51094
Task: 2244829
X-original-commit: bf416d95b1216c5780d3dbeaa32f0e57dc50c574
Related: odoo/enterprise#10543
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Since January 2020, users are required to validate their IAP account via
SMS code validation. This new behaviour needed to be properly ported to
the client to correctly inform the user.
This commit adds support of a new failure_type: 'Unregistered Account'.
Task #2209567closesodoo/odoo#48512
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some country names were not properly handled by the provider.
closesodoo/odoo#51134
X-original-commit: 285d5d65c3c04a12db399000566c8658306622f9
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Introduced in 7daa85dd, in kanban view .value on a number is formatted
and raw_value is the raw value, so if we had an product.image with ID
like 1000 we could have an query argument `id=1,000` which would result
in server error.
opw-2229427
closes#51105closesodoo/odoo#51133
X-original-commit: 84294948a4cc248e8c4e26f8ea93e2ff67435bb1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Go to Sales > Configuration > Settings
- Activate "Variant Grid Entry"
- Go to Products and edit a product with variants (lets call it "Product A")
- For "Sales Variant Selection" in "Variants tab", choose "Order Grid Entry"
- Go to Sales > Orders > Quotations and create a quotation
* Add any product except "Product A"
* Add another product except "Product A" and the previous one
* Switch the 2 added products with the sequence arrow widget.
It allows to be sure that the 2 added products have 2 different sequences.
* Add "Product A" with 1 attribute
- Here there are 3 products in the quotation with "Product A" at the third position
- Save the quotation
After the save the position of "Product A" is not the same anymore.
The bug comes from the fact that when using the matrix configurator, no sequence is provided
and the product is added with the default sequence of the SO line which is 10.
The issue is fixed by checking the sequence of the previous SO line if there is one.
[All of the above steps and explanations can also be applied to Purchase]
opw-2221991
closesodoo/odoo#51112
X-original-commit: 1a2d7e3fa0f33d90c74d3fd5a5ef486b56d8f512
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Let field F of model M be a Selection field.
Before this commit, creating a database with field F, removing/renaming
field F by changing its definition within the code then upgrading the
database to reflect the changes would result in a registry crash because
the field would still exist in the database but not in the ORM (memory),
thus trying to fetch the field in DB from the memory would result in a
KeyError.
This is due to the fact that field renames / removals are not stable
operations and should be handled with a migration script when upgrading
an existing database, nevertheless this can be quite an annoying
behavior while developing which is why this commit simply skips the
processing of the field if it does not exist in memory.
The ORM already foresees these cases and logs a warning to the developer
saying that the field was deleted anyway but that it was only a
partial delete and that it should be handled in a migration script in
order for the change to be production ready.
closesodoo/odoo#51099
X-original-commit: a54fecc35386f8e00018ff3d858b383d43f1dded
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
`**` rules for `py` files in `mail` and `sms` were not working as expected: they
only matched files directly inside the folder, without any depth. Indeed
`gitignore` syntax specifies that a slash must follow the double asterisks.
Doc: https://git-scm.com/docs/gitignore#_pattern_format
Added `rd-sm` to the various mail test folders, and removed `rd-discuss` from
`test_mass_mailing` specifically.
Specified which files are to be observed in `tools` for `rd-images`, as it would
otherwise generate too much noise.
closesodoo/odoo#51019
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
In a form view, have an x2many list with two fields A and B (e.g.
A is a many2one, and B is a char). There is an onchange on the
x2many that is triggered when the user sets A, and that sets B.
In this scenario, let's assume that the user first writes something
in B, but directly deletes it. Then, he sets A. Before this commit,
in this situation, B wasn't updated with the value returned by the
onchange.
Indeed, B's field widget was still flagged as 'isDirty', because
the user interacted with it, but it didn't commit its value, as it
hasn't actually changed. Basically, it remained flagged as 'isDirty'
forever, and thus couldn't be updated with the value returned by
the onchange.
This commit ensures that the 'isDirty' status is correctly updated
when the change is actually undone.
Task 1958793
closesodoo/odoo#51085
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: pka-odoo <pka@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
In a form view, have an x2many list with two fields A and B (e.g.
A is a many2one, and B is a char). There is an onchange on the
x2many that is triggered when the user sets A, and that sets B.
In this scenario, let's assume that the user first writes something
in B, but directly deletes it. Then, he sets A. In this situation,
B isn't updated with the value returned by the onchange.
Commit [1] is an attempt to fix this, but it actually broke what
has been done in [2]. However, tests of [2] still passed, because
they didn't accurately reproduce what happens in practice (outside
the test environment).
An input field widget listens to 'input' and 'change' events. It
commits its value when both occur, but in the 'input' case, the
action is debounced with a large value (so that it actually only
commits the value on 'change', i.e. when the field is focusset
out). In the tests, the debounce value is 0, so fields actually
commit their value directly when 'input' events occur. This is
something we may want to change in the future, to remove this
discrepancy.
This commit adds a test with a large debounce value, so that we
accurately test what happens in practice, and we make sure that
this won't be broken in an attempt of fixing something else.
[1] cdca11db2ec207363df1d4fb3c87014d9c931d25
[2] a71f223702
Related to task 1958793
Due to cache records being used in onchange currently virtual records are
added in onchange, leading to some members being duplicated when moderation
is used on channels.
Spotted in task ID 2238597
closesodoo/odoo#51104
X-original-commit: be6f169edab705a1a89bdc16cf3a1ac60b217c14
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
For most localizations, decreasing quantity of an orderline is
prohibited. This commit generalizes this behavior and is now available
in core point_of_sale.
This list actually contain all moderated emails list, not just banned one.
Name is confusing as allowing emails increases the counter of "ban list".
Spotted when working on task ID 2238597
Currently template rendering in calendar returns a tuple instead of real
results. This is a followup of 7159f657a0 and probably linked to cleaning
done in template while working on new calendar.
This commit makes calendar correctly use the rendering API.
Spotted when working on task ID 2238597
use alternatively symbol of singapore dollar also set symbol before the amount
task-2187155
closesodoo/odoo#51093
X-original-commit: a15027cb6c64bac10334ecc587a74224d946d9c3
Related: odoo/enterprise#10541
Signed-off-by: Josse Colpaert <jco@openerp.com>
Bootstrap uses `font-weight: bolder` for its `<b>` elements. This is
good... but only works if the "bolder" font is actually referencing
an available one.
Indeed, since we only load 400 and 700 font weights for fonts, see the
following table. CSS values on the left, actual fonts being used on the
right.
```
<p> | <b> | <p> | <b>
----------------------
100 400 | 400 400
200 400 | 400 400
300 400 | 400 400
400 700 | 400 700 -> ok
500 700 | 400 700 -> ok
600 900 | 700 700
700 900 | 700 700
800 900 | 700 700
900 900 | 700 700
```
See how bolder and fallbacks works: [1] and [2].
With most fonts, the rendering of `<b>` was thus only working for elements
using 400 or 500 font-weight. For font-weight > 500, we'll consider
this as a limitation for now: bold area cannot be made bolder.
Font-weights < 400 are however more important as used by some of Odoo
and bootstrap style (e.g. the entire blog posts).
The problem is even deeper as website visitors could have more or
different available font-weights on their computer.
This fix adds the loading of 300 weights for all fonts so that:
- The displayed weights are more consistent across different computers.
- Making a light text bolder through the editor works.
[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight#Meaning_of_relative_weights
[2]: https://developer.mozilla.org/en-US/docs/Web/CSS/font-weight#Fallback_weights
opw-2226573
closesodoo/odoo#51061
X-original-commit: e7496b923b097f677bef09b890c52b5a680cf53c
Related: odoo/design-themes#277
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- Have a standard V13 with note
- Connect as Admin A
- Create User U1 and U2 with password and email on partner
- As A, create a note N
- Add U1 as a follower
- Login as U1
- Open N and add U2 as a follower
We have a custom record rule that provide access to notes if
you are in the "message_partner_ids" of the Notes.
An override to the field in notes to compute as sudo fix the issue
opw-2223632
closesodoo/odoo#51082
X-original-commit: e1fbac466ff6c3abfd0de5760f43a3ff2e5cdb90
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Issue
- Install Projects
- All Tasks > Form View
- Edit the view
- Set statusbar clickable to '0'
Still clickable
Cause
In relational_field.js we do
`!!'0'` which returns true
like `!!'anythingelse'`
Solution
Add a '+' which will convert
the value into an integer
for a better conversion.
OPW-2235311
closesodoo/odoo#51083
X-original-commit: 53cc68fce32f46a0b4bc83a1e73a5d13a60fc995
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
The domain on the view was incorrect. The field is a required
selection where one of the selection is 'none'
closesodoo/odoo#51076
X-original-commit: 80dd40dd86484b3ab8c47b3baa315843f0027871
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit: A problem occurs with kanban views that are not
groupable (i.e. for which searchMenuTypes does not contain 'groupBy'):
if the action has a default groupby (set in Studio for instance) then
it is still applied and causes crashes. That happens in the documents
kanban view for instance.
More generally, if a view is not groupable, some information on groupbys
can appear in the interface (in a facet) while not used/useful
for the view.
After this commit:
- if a kanban view is not groupable, a default groupby will never be
applied.
- if a view is not groupable, we ensures that
- the search query generated in the control panel has
groupBy = [],
- groupbys cannot be represented in a facet.
closesodoo/odoo#51041
X-original-commit: 91c80291e90127792623476d8997fd2a67569170
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
before this commit,
tabbing into the date or datetime field input it has only focus, value is not
selected.
after this commit,
navigate through a view in edit mode with the TAB key, when focus comes into
date/dateetime field input then input is focused and value of date/datetime
field is also get selected.
task-2246593
closesodoo/odoo#51062
X-original-commit: 962e4e18b559d90aa3456c77035659ac8017501d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Add Johan as a contributor for SprintIT
closesodoo/odoo#51063
X-original-commit: f96a17c6fdba4cc53d006db28117f46bbaf347ff
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This is related to
826c86e9ab31963e410887a30326f45bcfadf5ea
The case is the same,
a custom field with an invalid depends,
except that this time its through a transitive dependency.
e.g.
custom_field_2 depends on custom_field_1
custom_field_1 depends on unexisting_field
The loading of the registry completely fails,
because the loading of the field `custom_field_2` raises a
`KeyError` exception in
`def transitive_dependencies` @ `dependencies[field]`
because the `custom_field_1` was skipped @ line
`dependencies[field] = set(field.resolve_depends(model))`
Landing in a state where the server can no longer start at all,
and the user can't therefore solve its custom field himself
to repair the situation.
closesodoo/odoo#51057
X-original-commit: 7b642884cc4d643a5a998b4639bf26b4e81cc46e
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When the discount of a sales order is computed, based on the pricelist,
the pricelist price computation is reversed, to find the base price on which
the discount was applied.
The currency considered as the base price currency was potentially wrong in
some cases (multi-currency environment, different currency between cost and sales prices,
...).
This commit ensures the right currency is used.
closes odoo/odoo#51045
Forward-port-of: #50913
Forward-port-of: #50811
X-original-commit: b39228a505151c669876f858941748fa9146279a
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Before this commit, it wasn't possible to multi-edit boolean
fields in list views. Actually, it didn't work for fields rendered
by Owl components. It only impacted boolean fields because it was
the only editable field widget that had already been converted in
Owl.
It didn't work because of three issues:
1) there is some sort of an hack in basic renderers: we set the
attribute '__node' on the field widgets, and this attribute is
used for instance by the controller, when it has to handle a
multi-edition. It tries to read it from the event's target
(typically the field widget). However, with owl components,
'__node' was set on the FieldWrapper (wrapping the actual
Field Component).
2) the original target (the Owl Component which triggered the
event) was lost when the event went through the compatibility
layer (for owl Component embedded in legacy widgets).
3) the multi-edition confirm dialog didn't handle Owl field
components.
Task 2254717
closesodoo/odoo#51044
X-original-commit: 36d23cfcdef3cea3539004ee5bb4479b859b8137
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Complement of PR #50720 to aovid sending email as well.
opw-2250185
closesodoo/odoo#50814closesodoo/odoo#51042
X-original-commit: 64ef9d74753ddf532cb4fc3d9769cd4913a2d9d7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, url preview of a theme was theme_xx/static/yyy.png
Now we make this url absolue /theme_xx/static/yyy.png
It was the expected behavior, and since werkeug 15.0 utils.redirect() don't use
'/' anymore as root but the current path.
Without this fix, theme selector uses /web/image/<id>, and the location become
/web/image/theme_xx/static/yyy.png instead of /theme_xx/static/yyy.png
closesodoo/odoo#51018
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
1) Have a [DEMO] product available on website.
2) Duplicate [DEMO] into several products.
3) Open the website ecommerce page
4) Go in edit mode
5) Click on one of the middle duplicates and go to
Customize -> Promote -> Push up
Item will not raise by one position but will be shifted randomly because
when duplicating the sequence number is copies so it will be the same
and this wil not work with the current resequencing algorithm which just
swap the sequence number to invert the positions.
Forcing copy=False on the attribute solve the issue
opw-2227976
closesodoo/odoo#50603closesodoo/odoo#51039
X-original-commit: 2a3704ac56d1625d8b35df80202473ffee03beb2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Andrea Grazioso (agr-odoo)