Exceptions were not logged correctly due to a typo in ExceptionLogger.
closesodoo/odoo#51191
X-original-commit: 9ac2ad249bddc631de9a9d587058d6109918f584
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
The purpose of task is to update the 'user/employee avatar' to the new
widget in all the kanban view across all modules.
The below new widget are introduced for avatar:
- many2one_avatar_user (for user_id fields)
- many2one_avatar_employee (for employee_id fields)
which displays the avatar (i.e. picture) of a user/employee in front
of his name and clicking on the avatar will open a chatbox to message
that specific user/employee.
So in this commit, For each kanban view with a user or employee avatar,
replaced it by the field with the new 'many2one_avatar' widget.
TaskID: 2244928
Related Enterprise PR: https://github.com/odoo/enterprise/pull/10420
closes odoo/odoo#50789
Closes: #50789
Related: odoo/enterprise#10420
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Create a PO, order 5 items
- Validate Receipt with 5 items
- Return 1 item to Vendor
- Update Order Quantity on PO, from 5 to 8
A picking of 3 units is created.
If the same workflow is used in Sales, a picking of 4 units would be
created, which is the expected behavior.
We adapt the logic of Sales [1] to Purchase.
[1] https://github.com/odoo/odoo/commit/8a3284685856b6980e3b620abdbbb3e2c79f57c4
opw-2233826
closesodoo/odoo#51174
X-original-commit: 74e8b9ab2311ed2c1c9cea53d09e3b352db3dbe6
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Oversight of efafadc3ee
This commit fixes typos that raise an error when a crm.reveal.rule is created.
Task 2250137
closesodoo/odoo#51173
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, a traceback occured when user clicked in the Sales Analysis in the sales team dashboard
closesodoo/odoo#51170
Taskid: 2246368
X-original-commit: fb5e9cb68c922706e356c78680ddfc4876bbbf85
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The supported case of check_company on `res_company` model fields was
not considered when specifying a default domain on `check_company=True`
fields.
closesodoo/odoo#48674
Nb: It is already correctly supported in the `_check_company()` method.
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Issue
- Install Survey & Contacts
- Have 2 contacts with the same email address
(e.g. test@example.com)
- Create a survey, send it only to that
email address
Email sent 2 times
Cause
When looking for partners linked
to that email address, we do not
provide any limit so the system
send the email to all partners
found.
Solution
If I set one email address,
I expect one email to be sent.
So, the solution would be to
apply a limit of 1 when login
is not required.
OPW-2247693
closesodoo/odoo#51155
X-original-commit: 55b1cc3108d6b672f10ece26db7e13a65ff655d3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Partner autocomplete suggestion popup cropped from the top in small devices.
once you type anything in M2O box, autocomplete popup will display with all
maximum possibilities consist of the database records and records got from
global search partner API.
Currently, we have limit of database record search is 7 and autocomplete
display maximum 16 items databse records + API generated records.
So with this commit, we have reduced the API record display limit for small
devices, based on height it will display number of items in autocomplete box,
this will reduce chance of cropped issue.
Task:2206844
closesodoo/odoo#51151
X-original-commit: ded375786557ae6c7680409faa32cbe3a4e30e99
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have two x2many lists in a group in a form view. Increase the
width of a column in the first table. Before this commit, the
second table was also expanded.
task-2189968
closesodoo/odoo#47652
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
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>
Antoine Prieels