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>
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>
Address format and vat label are not properly set for Austria and
country states are missing for localized needs.
closesodoo/odoo#51038
X-original-commit: 5f05e2f83a9ceebed1dac04ad9fd9f1791738c31
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Try to Reproduce the Issue:
Enable Multi Website
My Website: Set `On invitation` (b2b) under Website settings. -- It will set `auth_signup.invitation_scope` to b2b
My Website2 : Set `Free sign up` (b2c) under Website settings. -- It will set `auth_signup.invitation_scope` to b2c
Place a Guest Order for Website one.
`Sign Up` button will be visible as current Implementation is checking for ICP only.
With this commit, We are checking Invitation Scope based on the Current Website.
Fixes#50964closesodoo/odoo#51037
X-original-commit: 608e8b4c4a11b569cf3ad7e7586c731bad108afa
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, It was considering the company from the current company of the User while User can be in different Company Environment.
With this fix, we are taking the company from Environment.
closesodoo/odoo#51023
X-original-commit: 7b32cc6ed23d15212621c80a44fcf628fa98847e
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this, User was unaware of the fact that Popup might be blocked which due to which window won't be opened.
With this commit, We notify users about that.
closesodoo/odoo#51015
X-original-commit: 393f417ce0d437118fc1ba72f05caeeb42ca70f4
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, Creating New Employee from User's form was taking default company from the current logged-in User instead of the User for which it Employee is being created.
With this commit, We take default company from User for which employee is created.
closesodoo/odoo#51014
X-original-commit: 9206cc4db2a8dc5a7fbc281c1574f09bfba76544
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Message with type user_notification are special "invisible"
notifications that are not accessible to users normally. That's why they
were excluded from the automatic message deletion in
mail.thread.unlink(), to avoid permission errors. But this caused
orphans leftover notifications in the database, and the fix here is to
instead do the deletion of messages in sudo mode, and make sure
user_notification messages are deleted as well.
Doing this is not a security risk because the deletion of the record
itself (the super call) is still done without sudo, and if it fails,
the whole transaction will be rolled back. And it is part of the
expected ACLs for messages that if you can delete a record you are
allowed delete its messages. The fact that user_notification messages
are not accessible by normal users is for usability reasons (noise in
chatter), not security reasons.
opw-2234282
closesodoo/odoo#51010
X-original-commit: 094559aef4fdfebcba43a089cec4da5f4028a8f2
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
- Have a user in an early timezone (for example Samoa Standard Time);
- Open a POS session in the evening (say 20h).
- Buy something, pay and ask for an invoice.
Before this commit, the date of the order was correct (today at 20h),
but the date of the invoice was wrong (it shows tomorrows date). This
issue occurs because the invoice date wasn't taking into account the
timezone.
Now, both dates are corrected.
opw-2231820
closesodoo/odoo#51001
X-original-commit: 19e9c4a0380e7ad7af297d13909dcbc63629a20d
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, the last closing date of the POS didn't take into
account the timezone.
Now, the date take into account the timezone.
opw-2231820
X-original-commit: 1b738ac4b8b52042976ad209a1968135c55a16dc
- Have a user in an early timezone (for example Samoa Standard Time);
- Open a POS session in the evening (say 20h).
- Buy something and pay with cash.
- Close the session.
- List the session orders, and open the newly create order.
Before this commit, the date of the order was correct (today at 20h),
but the date of the payment was wrong (yesterday at 13h). This error
occurs because a wrong format was used and the date was taken into
account two times the timezone.
Now, both dates are corrected.
This fix is a partial revert of 2157540768
opw-2231820
X-original-commit: 020e5547ad10583000748659de0e2b14ceabbf97
that the argentinian chart of account has been installed
closesodoo/odoo#50880
X-original-commit: 3c55cae48936e195ec3411c55f577422c56828c3
Signed-off-by: Josse Colpaert <jco@openerp.com>
We need a hook to be able to personalize the procurement values
which will be used on procurement group creation when creating MO
closesodoo/odoo#51016
X-original-commit: 9a100e99ad401e5ca6bf45bf8371388c47ec7849
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
1. Install MRP
2. Launch an Odoo shell on the database
3. Type the command
`print(env["mrp.bom.line"].browse(1).child_line_ids)`
Traceback will occur with exception
odoo.exceptions.CacheMiss: ('mrp.bom.line(1,).child_line_ids', None)
This occur due to the empty value that the computation of the field
yields, which is not saved in cache.
Fix by adding a default value.
opw-2226951
closesodoo/odoo#50950
X-original-commit: fc885499a3c75d8d564569ec4cea41a8a64f3164
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Step to reproduce:
- Go to CRM app
- Create a new opportunity and edit it
- Alter the website field under "Contact Information" tab
with "www.anywebsite.com"
- Save and click on the website field value.
Without this fix, the field redirect as it's local:
"http://www.myodoo.com/www.anywebsite.com"
porting 726fad8
opw-2247853
closesodoo/odoo#50942
X-original-commit: 072400ad12ea17438a0175d94eb887f51172e461
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, It was not possible to Hide Working Time or Deleting Working Time if Resource is linked to it.
Now we add, Active field to Hide Working timw without removing it.
closesodoo/odoo#50963
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This refactoring extracts parts of sale_coupon module to create a more
generic module called coupon. This new module can be extended in
different sales modules to implement functionalities specific to modules
that extend it.
TASK-ID: 1967639
Enterprise PR: odoo/enterprise#6020
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#38382
Related: odoo/upgrade#1072
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
If there is cron worker timeout logger error, there is a log for the
last cron running
If a "Base Action Rule: check and execute" fails, we need to know what
is the last base automated action based on-time running
This logger helps to looked for it
closesodoo/odoo#50493
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Write something in a many2one field, and click on 'Create "..."'
to quick create a record with the given value (name_create). When
the name_create fails (e.g. because there are mandatory fields in
the model), we open a form view.
Before this commit, when this happened for many2one fields inside
x2many editable lists, it crashed, since [1].
[1] 50bf8309f8closesodoo/odoo#50948
X-original-commit: 43c513306094444ff25ad98584b426ddb8a3b525
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With this fix, record.with_context(lang='fr').compute_url will have the url
with the slug in french.
Before, it was ignoring the lang since the field was not translatable.
The first compute was stored in cache, and next call just ignore the lang in
the context.
```py
for lang in ['en_US', 'fr_FR']:
print(record.with_context(lang=lang).website_url)
> "/my-name-1"
> "/my-name-1"
```
now
```py
for lang in ['en_US', 'fr_FR']:
print(record.with_context(lang=lang).website_url)
> "/my-name-1"
> "/mon-nom-1"
```
closesodoo/odoo#50951
X-original-commit: 43822adef4ee4c44d10786f28af46df4be260cf5
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit, the /event/event-id/page/inexisting_page crashes with an
internal error 500:
of1 ValueError: View 'website.404' in website 1 not found
X-original-commit: d493fdd2e837b5e6931bd8c2c4d57712432f9107
Joseph Caburnay