Follow-up of #91671 (Task-2817547)
Changes above fixed an issue with composer suggested recipient
feature not properly prompting a dialog to create new partners.
The fix was correct before #90678 (Task-2831082/Task-2849934), but
it needs to be slightly adapted for this small technical changes.
By omiting them, any change of checkbox state results in a crash.
This commit properly adapt code in `_onChangeCheckbox` to take
into account both changes.
closesodoo/odoo#92408
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Top level components should always be wrapped in containers since they have to receive
a record comming from messaging. To do that, we need to wait for messaging to be initialized.
In the PR introducing the new environment in the discuss app, some of those components will
be passed to the main_component registry, messaging won't be ready yet. In order to ease the
transition, the last components missing a wrapper have been wrapped.
task-2582313
closesodoo/odoo#92402
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The note "Quotation viewed by customer" posted when a public user
accesses an order on the portal (with a token) was translated in
the "automatic" language, i.e. the website or user (or browser language).
This doesn't make much sense since log notes are not meant to be shown to
the user, only to the internal user(s) (/salesman).
This commit makes sure that the message is not translated in the website/customer lang,
but in the salesman or company language instead.
Task - 2836421
closesodoo/odoo#90318
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
If you do not have favorite filters available in the mass mailing for
selected model, we display empty drop down, which is not ideal.
This commit improves the behavior with following changes:
- If there is no filter available (for this target) and no condition
set in the mailing domain, do not display anything
- If mailing domain is set but there is not filter available, show a
custom label "Save Filter as Favorite" save icon next to it
Ent PR: https://github.com/odoo/enterprise/pull/26308
task-2711258
closesodoo/odoo#87673
Related: odoo/enterprise#26308
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2859751
closesodoo/odoo#92132
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The only mail.channel rule was that a user only had access to channels
they're members of, or can subscribe to (public, or group based).
This rule applied to admins as well, forcing them to switch to
super-admin mode in order to manage mail channels.
This is undesirable on lots of axis:
- superadmin mode is a bit of a last-ditch feature, as a result it's
somewhat hidden
- there is a much higher risk of screwing up as superadmin mode
basically lifts all the access rules, which can have correctness
implications
- auditing completely breaks down when using superadmin mode, as the
real identity of the user is lost
OPW-2857136
closesodoo/odoo#92299
X-original-commit: 1a77ab5726bbcc477d12f40f67433d474ea85316
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Timeoff is apply in the view to take effect on every view type
instead of only the calendar.
closesodoo/odoo#92027
X-original-commit: 3b89abcc3def129b91221eb983a5a936670d7b9c
Signed-off-by: Kevin Baptiste <kba@odoo.com>
'name' field not present in 'gamification.goal' model
which causes error while rendering mail template such that
object 'gamification.goal' has no attribute 'name'
opw-2844136
closesodoo/odoo#92300
Closes: https://github.com/odoo/odoo/pull/91439
X-original-commit: 0a1970e218527440debb8c75fff2fa47de5e2677
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Using customization, if you add a field on `mail.template`
with a `groups=` attribute with a group your regular users do not belong to,
e.g. `groups="base.group_system"`,
the users will have an access error when attempting to read the given
field when checking if the template is dynamic,
with the `_is_dynamic` method.
We could restrict the list of fields to read/check to the fields
the user has access, but that means a user could
duplicate a template with code in the fields he cannot see.
So, read the field has sudo to make sure they do not contain code
is the way to go.
closesodoo/odoo#92371
X-original-commit: 41cbd3fdfec8e2b7a8b22360c5bb7f7b9bab4b1e
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The constraint is added in `hr_payroll`, checking that if `is_unforeseen`
is True, then so must be `is_leave`. To reproduce the error simply install
`hr_payroll`, edit Work Entry Type Attendance to set as unforeseen absence
and upgrade the module `hr_work_entry_contract`.
closesodoo/odoo#92358
X-original-commit: 5448ddcbec8a1058aa271206d5a8999b3e67dda5
Signed-off-by: Kevin Baptiste <kba@odoo.com>
following commit 55398263f9297ab2709e4c4c2a9c6c3ee7f59c8a
Introduce a new param to fix a notification issue. However
we could use the context instead of a new parameter in order
to avoid breaking the customisation.
Linked to PR #88303 discussion
closesodoo/odoo#92353
X-original-commit: 69dcdd410adcefe29bfa4fecd2e7c50fe3465b19
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This Goal will help end user to find most 404 hits and fix the
legits one...
Fixing typo, creating missing redirect, or fixing code.
We need to cast the event-name since plausible only accept 'string'
as custom event name, so if we push 404 instead of '404' the event
crash.
closesodoo/odoo#92243
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Original 14.0 commit title:
Prevent deadlock on editor save when an option is focused
See [1].
In 15.0, the code worsened... but, by chance, fixed the deadlock bug.
See adapted version via the X-original-commit.
With this master version of the original commit, it is tried to clean
the code a bit... at least around the code that was originally touched,
without starting a big refactoring that is again needed. The deprecated
(and added by mistake) 'edition_will_stopped' and 'edition_was_stopped'
events are now gone.
Hopefully, we will continue to improve that editor hierarchy (and
ultimately converting to OWL?) in future updates.
[1]: https://github.com/odoo/odoo/commit/53a08b3470d7d18488abf93b7ea6551700650460
Related to opw-2767903
closesodoo/odoo#92321
X-original-commit: 483a2d6cac1be3b40a4d1878536baea9e6098ec1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
odoo/odoo#87522 introduced the concept to automatically
inline tree, kanban and form views under one2many/many2many fields
within form views.
The goal being for the web client to make less `get_views` calls.
However, currently, automatically inlined form views
under one2many/many2many fields leads
to more triggered onchanges than before,
triggering more field computations than before,
potentially leading to performance issues
as more fields are computed than before.
Besides, they are not visible in the tree/kanban view
and their computation can therefore be considered useless.
At worst, it can even causes bugs, by triggering computation
in places they were not used / do not handle correctly,
as explained in
https://github.com/odoo/odoo/pull/87522#issuecomment-1132554918odoo/odoo#91878
This revision reverts the behavior to automatically inline
form views, while keeping the inlining of kanban/tree views.
However, by reverting this, we re-introduce a limitation
of the web client behavior regarding onchanges,
explained in odoo/odoo#91935.
This is therefore not perfect,
but at least the previous behavior is back.
In the future, work will be done to re-introduce the automatically
inlined form view, while solving both issues:
- Do not trigger more onchanges than necessary,
- Solve the limitation of the web client shown in odoo/odoo#91935closesodoo/odoo#91968
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Current behavior:
When selling a product that have a taxe set in a PoS, the sale report
was not correct. The collumn untaxed amount to invoice would contains
the amount to invoice that includes the taxes wich is not correct.
Steps to reproduce:
- Install sales & pos
- Set the Acoustic bloc screen tax to 15%
- Open a pos session and Sell an acoustic bloc screen
- Validate the payment and close the session
- Open the sales app
- Sell an acoustic bloc screen to any customer
- Deliver it (update it's quantity if necessary)
- Sales > Reporting > Sales
- Switch to the pivot view
- On the "measures" button, check "Untaxed Amount Invoiced" and "Untaxed Amount To Invoice"
- Show the entries by Order#
- "Untaxed amount to invoice" should be the same as "untaxed total"
opw-2681477
closesodoo/odoo#92217
X-original-commit: 8c20fb4e126822d81fa7e1de6912d5c75a881b7b
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Standard price: 20$
- Add vendor in the Purchase tab:
- name: Azure Interior
- min qty: 10
- price: $15
- Create a PO:
- Vendor: "Azure Interior"
- Product line: “P1”
Automatically, the Quantity field will automatically get populated as 10 Units
and price:$15 as per the pricelist
- Confirm the PO
A picking will be created containing a stock_move with a price of $15 and a QTY of 10
- Edit the Quantity to 9 Units and save the PO
The price will be updated to $20 on the PO line, but not in the `stock.move`
Problem:
When we update the qty in the PO line, a new move with a quantity of “-1” and
a price of “$20” will be created.
Then, it will be merged with the initial move, but since they are not identical in the price,
we can't merge them, so a new picking is created:
https://github.com/odoo/odoo/blob/dda9700d8236091626cbd78efc0ca4116e1e1acd/addons/stock/models/stock_move.py#L869-L881
Solution:
when the price is updated in a PO line, the price of its linked `stock.move` must also be updated
opw-2825160
closesodoo/odoo#92208
X-original-commit: c8d74a1cb4bfed8226e52e0bc6f243b4e483fc98
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Two ACL were giving the same rights to the same group on the same model.
This commit removes the confusing one where the name targeted the
managers when the rule was targeting sales users.
closesodoo/odoo#88210
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Remove rights given to sale manager when the same rights were given to
the sale users, which is implied by the sale manager group.
Part-of: odoo/odoo#88210
Since (at least) Chrome 94+, some element's sizing computation returns a
slightly different value (in the order of a fraction of a pixel). Sadly,
due to rounding, this difference has an impact on exact sizing
assertion.
As the difference is *really* small, introducing a margin of error (i.e.
<= 1px) looks reasonnable ; as implemented in this commit. More
specifically as Element.scrollHeight can have either an int or a decimal
value (cf. fractional-scaling), this commit allows to property handle
both usecases.
Reference:
https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollHeight#determine_if_an_element_has_been_totally_scrolledclosesodoo/odoo#92328
X-original-commit: 93348ae0d0b076fe2dfa094a2d7b3ef74442d390
Related: odoo/enterprise#27790
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
*: website_mass_mailing
Before this commit, some types of buttons were not managed by the
editor, only the primary, secondary and link buttons were supported.
However, if there is another type of btn in the DOM, the editor must be
able to handle it. This commit allows to manage all types of buttons in
the editor. This commit also adds a test so that the bug does not come
back.
Steps to reproduce the fixed bug:
- Drop a block with a <a> with the btn-success class
- Click on the button to edit it
- The link tool part in the editor does not work properly
or
- Drop the newsletter block
- Save and register to the newsletter
- Edit the new "Thanks" button
- The link tool part in the editor does not work properly
opw-2802139
closesodoo/odoo#92325
X-original-commit: 4c68b3e923610e1d573b4bd2b241b2fc5923c412
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit is a copy of 7ddcebfc, which was reverted in dfcfe63c.
Before this commit, the menu_service was not included into the
`pos.assets_backend` bundle which was fine until we had to add
a dependency to `menu_service` in a file which is included in
`web.assets_backend`. Since pos.assets_backend imports pratically
all `web.assets_backend` bundle, there was dependencies errors.
The sublient issue is that the pos bundle was built relying on a
specific feature (the primary copy of Qweb templates) which was
dropped when we introduced the new assets manager (8cc06617).
There a two other approaches that we could consider:
- Create a new bundle `web.assets_backend_primary` that would be
called separately by `web.assets_backend`and `pos_assets_backend`,
it would mimic the dropped behaviour
- Change the `pos_assets_backend` to manually call every specific
element they need to function, which would prevent the depepdencies
issues
Unfortunately, both solutions are not realistic on a stable release,
which is why we chose to reintroduce this patch, and will fix the POS
bundle properly in master, where the side-effects can be handled.
After this commit, there are no dependency issues, and the menus
are not loaded, as expected and as before.
Part of task 2860257
closesodoo/odoo#92324
X-original-commit: b077fe72e8d9338e802cbceb580f3abcb6938462
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
Since [1], during the call of `apply_inheritance_specs` in charge of
resolving all the xpath of inheriting views and building the whole
primary view, processing instructions were added to mark the locations
where nodes were removed. Before that commit, another system was in
place where the following node next to the removal was marked via a
meta-oe-xpath-replacing attribute.
The problem with that change is that some of those processing
instructions were actually not removed once the branding was distributed
before the view was served... indeed all processing instructions which
were in the `<head/>` or a t-ignore area were ignored instead of removed.
This was actually already the case with the old system of the attribute
"meta-oe-xpath-replacing" but it was never noticed (as either the
attribute was there but had no effect or was indirectly gone if it
landed on a `<t>` node).
After [1], a bug was reported in 15.0 with the website configurator
where the processing instruction actually made some nonsense appear on
top of the page (at least without the work being discussed at [2] which
makes it so processing instructions act as HTML comments as it should
normally be the case).
[1]: https://github.com/odoo/odoo/commit/f67832a3ae0d9a3b5b53129132762e6bc1aed874
[2]: https://github.com/odoo/odoo/pull/92213closesodoo/odoo#92316
X-original-commit: 4310d012a16f982c2336d084254b5c5617794ee2
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The kanban view for sales team is defined with a progressbar widget to
indicate sales target. There was a .include of KanbanRecord to customize
the behavior of that widget whenever the target value was not set. This
was problematic for the following reasons:
1. it is a .include, so it is applied to all kanban records in odoo
2. it is a lot of code,
3. and it mostly duplicate the editing logic in the progressbar widget
With this commit, the .include is removed, and a new
'sales_team_progressbar' widget is introduced to mimic the previous
customization. This should be safer and easier to maintain.
closesodoo/odoo#92071
Related: odoo/enterprise#27747
Signed-off-by: Géry Debongnie <ged@odoo.com>
The kanban view was recently improved to add the support of 'action' and
'type' attributes on the kanban arch. This commit takes advantage of
that change to simplify a few views in various addons.
Part-of: odoo/odoo#92071
It is very common when using kanban view to need a way to declare what
action is executed when clicking on a record. The default action
(switching to form view) is sometimes not what we would like. For
example, clicking on a project kanban record should open the
corresponding tasks, instead of the project form view.
Until this commit, it was not possible to do this simply for a whole
kanban record, however it was possible to add a button with a name and
type attribute to specify the resulting action. This commit introduces
the same idea, but on the complete kanban record, instead of just a sub
element.
To specify the action that should be executed when clicking on a record,
one can now use the 2 attributes 'action' and 'type' (which corresponds
to the 'name' and 'type' attribute for the kanban record. 'name' was
also considered, but it was too weird). For example:
<kanban default_order="name" action="action_brand_model" type="object">
...
</kanban>
Part-of: odoo/odoo#92071
Since (at least) Chrome 94+, some element's sizing computation returns a
slightly different value (in the order of a fraction of a pixel). Sadly,
due to rounding, this difference has an impact on exact sizing
assertion.
Specifically in these drag-and-drop tests, it prevents the sorting from
being triggered as the "mouse" doesn't pass beyond the center of the
destination element (aka. next row).
By setting the position to `bottom`, this commit mitigates this issue by
making sure to pass that boundary, just like a real-user would do.
closesodoo/odoo#92292
X-original-commit: ed798b216063caa299800a56c617277aabdfb8fd
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit improves cross-browser compatibility for the `user-select`
property by adapting the css statement to Safari's Webkit syntax.
task-2838625
closesodoo/odoo#90476
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Prior to this commit, there was no mobile layout adaptation on
`NotificationGroup` and this creates some design inconsistencies with
the other components (`ThreadPreview`, `ThreadNeedactionPreview` and
`NotificationRequest`).
This commit fixes these inconsistencies.
task-2838625
Part-of: odoo/odoo#90476
Prior to this commit, there was still some unnecessary css that was
creating conflicts since the revamp of mixins in `NotificationListItem`
(commit: 7760c54ec09f93488ccb89d2925b6655fdb0092f).
This commit removes this unnecessary css.
task-2838625
Part-of: odoo/odoo#90476
Define "Bootstrap v5 ready" utility-classes to handle font-size.
These classes definitions can be safely removed after migrating to v5.
task-2838625
Part-of: odoo/odoo#90476
This provides a new API for those operations, in order to make the
distinction between the use cases more explicit. The former API was
using obscure parameter combinations to correspond to various cases.
In the summary below, `fnames` is an iterable of field names. If the
parameter is not given, it means "all fields" in the given context.
Note that method recompute() is now mostly private, as it should not be
used in business code.
# process pending computations and updates
records.env.flush_all() # all fields of all models
records.flush_model(fnames) # the fields of all records of the model
records.flush_recordset(fnames) # the fields of the given records
# process pending computations, became non-public methods
records.env._recompute_all() # all fields of all models
records._recompute_model(fnames) # the fields of all records of the model
records._recompute_recordset(fnames) # the fields of the given records
# invalidate the cache of fields
records.env.invalidate_all() # all fields of all models
records.invalidate_model(fnames) # the fields of all records of the model
records.invalidate_recordset(fnames) # the fields of the given records
Part-of: odoo/odoo#87527
The users shouldn't be able to edit the answers from the attendees as they don't know
what questions they are answering to or the type of response expected.
opw-2845524
closesodoo/odoo#92283
X-original-commit: 379f8702a9759cdec533e29f43f15bca74de3b43
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Current SCSS is replaced with global Bootstrap classes, in
order to reduce code lines and to increase performance.
Task-2834810
closesodoo/odoo#90174
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Currently, clicking on the blocking stat button throws an error when
there is more the 1 task in blocking stat.
So this commit, fixes the issue by removing the extra comma so that
clicking on blocking stat button doesn't throws an error.
task-2834743
closesodoo/odoo#92257
X-original-commit: cd7b7b02523e0982366f4ca60b6df2448d7e9cb5
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
In fixing leftover jammy warnings in #92078 I mistakenly updated the
setting of `_daemonic` to the public `daemon`, missing that it was a
dedicated and explicit workaround for Python's checks (cf
d03b4f8675).
closesodoo/odoo#92255
X-original-commit: e35a4d87578a588e33f604638289ca7e7ee02029
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When using a sub-location of "Subcontracing Location" and a dropshipped
component, the purchase order doesn't have any dropship address.
To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Multi-Step Routes"
2. Create a new location L:
- Parent: Physical Locations/Subcontracting Location
- Type: Internal Location
3. In Rules, duplicate the rules of route "Dropship Subcontractor on
Order" and replace "Physical Locations/Subcontracting Location" with L
4. Create two products:
- P_finished:
- Type: Storable
- Vendor: V_subcontractor
- P_compo:
- Type: Consumable
- Vendor: V_compo
- Routes: Dropship Subcontractor on Order
5. Edit V_subcontractor:
- Subcontractor Location: L
6. Create a bill of materials:
- Product: P_finished
- Type: Subcontracting
- Subcontractor: V_subcontractor
- Components: 1 x P_compo
7. Create and confirm a purchase order:
- Vendor: V_subcontractor
- Products: 1 x P_finished
8. Open the purchase order linked with P_compo
Error: the Dropship Address is not defined
This address is defined thanks to the value of `partner_id`:
https://github.com/odoo/odoo/blob/aec7fcdb693729f432ae2341c00ef317b65fbcbc/addons/purchase_stock/models/stock_rule.py#L300
However, this key is missing
OPW-2721474
closesodoo/odoo#92249
X-original-commit: 587d8cd0ecb956a5c1b1a32a7abadea3019f848e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Define "Bootstrap v5 ready" utility-classes to handle border-width.
These classes definitions can be safely removed after migrating to v5.
task-2842691
Part-of: odoo/odoo#91298
Current behavior:
If you create an order in a PoS then go in the backend and archive
any of the product in the order. If you try to go back in the PoS
session it will crash
Steps to reproduce:
- Open PoS session and create an order with some products
- Leave the session and archive atleast one of these products
- Go back to the session, the session crash
opw-2854018
closesodoo/odoo#92248
X-original-commit: 0a01e0b97f96754ac2ae84da207584b6b6860b0e
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Brieuc-brd