In some methods, like group expand methods, it is not uncommon to
transform a domain designed for model A to search records from another
model B. In general this transformation requires two operations:
- Rename some fields in the domain
- Remove leaves from the domain that relate to fields not existing in
model B
The current function filter_domain_leaf allows to realize this second
operation. It currently relies on a recursive implementation with a
complexity of order O(n²).
This commit introduces a re-writing of the function filter_domain_leaf
that:
1. Changes the recursion based implementation to an explicit stack
implementation
2. Introduces a field mapping dictionary as argument
The explicit stack implementation allows to avoid stack overflow when
working with long domains. The complexity order is also improved to O(n)
instead of O(n²) which leads to performance gain. For a domain length of
~100 elements, the gain (timewise) is reaching 50%. It is >95% for
domain length over 10 000 elements.
The field mapping dictionary allows to avoid pre-filtering of domains
when using filter_domain_leaf. In cases where it is used, the domain
then just has to be browsed once in the filter_domain_leaf function.
task-3299357
closesodoo/odoo#120834
Related: odoo/enterprise#40847
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, chat window actions were all placed in
the right part of header. It was showing the main action (call),
close action, and all other actions in dropdown menu from
the "..." (more) button.
This commit now replaces the "..." (more) button by clicking
on avatar/name of conversation. The "..." (more) button has been
replaced to "_" (minimize/fold) button, as clicking on header to
open/fold chat window can become hard due to avatar + name being
clickable to show most chat window actions.
This commit also adds the following actions in chat window:
- Open (Employee) Profile
- Rename (conversation)
Task-3336752
closesodoo/odoo#124592
Related: odoo/enterprise#42480
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
before this commit, in the pos order search view the
product field is not added, and hence user may have
to use the custom filter, in order to filter the pos
order having a product.
after this commit, the product will be added to the
search view, so the end user's can easily filter the
pos orders containing a product.
closesodoo/odoo#121865
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
If Automation Actions's configuration is done wrong it will
cause Error at runtime which will be caught in sentry and
causes unnecessary traffic.
So, we stop catching exceptions from Automated Actions.
sentry-4200700020
closesodoo/odoo#126658
X-original-commit: 3479d998417b60807c288c047a1f469329dee59c
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
If a bill has a price difference with the PO, and if the user
refunds it, it will create some errors in the inventory valuation and
the accounting entries
To reproduce the issue:
(Need account_accountant)
1. Create a product category PC
- Costing method: FIFO
- Inventory valuation: Automated
2. Create a product P
- Type: Storable
- Category: PC
3. Confirm a PO with 1 x P at $10
4. Receive P
5. Bill it at $15
- It should create a price diff SVL, see inventory valuation
6. Refund
Errors: The inventory valuation is not impacted, it is still valued
at $15. Because of the refund, it should be $10 (i.e., the price
difference should be cancelled). Then, suppose the user creates a
new bill at $20, it won't do anything (the stock valuation will not
be impacted).
Long story short: the price difference feature, which is supposed to
impact inventory valuation/account entries, does not work if there
is a (partial/full) refund in the flow.
Now, let's think about a more complicated use case:
- Receive 12 products in several times
- Bill in several times (with different quantities than the receipts)
It could give something like (where `x` are products):
```
SVL01 SVL02 SVL03
/---------------\/---------\/------------------\
x x x x x x x x x x x x
\-----------/\-----/\--/\---------------/\------/
B01 B02 B03 B04 B05
('B' means Bill)
```
We observe that
- a bill could impact several layers
- a layers could be impacted by several bills
And here is the issue: currently in the code, we don't have a relevant
link between layers, account move lines and the quantity that links
both. The only thing we have is a link between the price difference SVL
and the account move line that has generated that SVL (see field
`account_move_line_id` on `stock.valuation.layer`). But this is
clearly not enough and is really problematic: if I refund BILL04, how
should it impact SVL02 ? Then, what if I return a part of the third
delivery before refunding BILL04 ? What if I deliver a part of the
received products before refunding several bills ? What if I refund
B02, B05, then I bill 4 products ?
-> You get the idea: we definitly need a clear link between account
move lines and stock valuation layers and that link has to give a
quantity.
Moreover, it is difficult to create an order between bills. We have
their name, their ID, but the posted time is actually a date. So, if
we mix reset & repost, a draft bill and a draft partial refund, and
so on, and if this mix happens the same day, it is very difficult to
define a clear order. But, considering the above schema, we see that
the order does matter (switch BILL02 and BILL03, the remaining
values of SVL01 and SVL02 will not be the same)
-> So, we also need a way to order the links between account move lines
and stock valuation layers.
Now, about the solution.
First, a **disclaimer**: We are in stable, we are limited by the stable
policy, and we can't let the above use cases unresolved. So, we took
some decisions to fix them and to repesct all the constraints we had.
**This is clearly a (big) patch, it should be considered as such and
will be replaced by a cleaner/better solution on master as soon as
possible**.
About the link between SVL and AML, we had the possibility to create
a new model in a new module. But this would have decreased the
impact of the fix deployment, would have created some
complications for support (different behaviours depending on whether
the module is installed or not) and would have make testing more
complicated (again, different behaviours depending on whether the
module is installed or not).
This is the reason why we decided to "replay the receipts and the
bills". That way, we know which layer is impacted by which invoices,
and vice versa. And, to set the order between all of them:
- For the layers, we use their `create_date`
- For the bills, we use a hack: each time an account move is posted,
because its state is tracked, a tracking value is posted on the
chatter, and this tracking value has a `create_date` (remind the
constraints explained above and the disclaimer...)
OPW-3217215
closesodoo/odoo#126536
X-original-commit: b5e0e1057b81f7333e73ef06e88e8943709119cc
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
This PR improve feedback messages:
- Visitor has left the conversation: as note
- Rating message: as note
- Rating message: Use same emojis as for customer
- Rating reason in same message as the emoji, without writing "reason"
- Feedback done in 1 rpc instead of 3
part of task-3332872
closesodoo/odoo#125925
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Purpose
=======
Some SMTP configuration can be used for many domains names. E.G.,
our own SMTP configuration can be used for both "mail.odoo.com" and
"odoo.com". So we want to be able to set a list of allowed domains
name, separated by a comma, instead of a single domain.
Task-3332488
closesodoo/odoo#122234
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
*: account, event_booth, gamification, hr, project,
website_event_track, website_hr_recruitment, website_slides
HTML fields that appear in the front-end can be modified using the
website editor. Some of them are sanitized in a way that breaks the
behavior of snippets that can be dropped within them.
This commit adapts the sanitization of those HTML fields so that the
snippets behave as expected.
opw-3267589
closesodoo/odoo#126708
X-original-commit: 7fd28afaf3e45cafbef80b69aa45c58b31fb3de6
Related: odoo/enterprise#43311
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
This commit simply makes the account tax groups tour compatible with
odoo enterprise even without the accounting app installed.
closesodoo/odoo#126738
X-original-commit: 450c26a866a58f0441db83376066d606ec429bc2
Related: odoo/enterprise#43323
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Julien Carion (juca) <juca@odoo.com>
Bug:
Currently, trying to import a fatturapa XML that has a document discount
doesn't do anything.
Setup:
- install l10n_it_edi and account_accountant
- have a fatturapa XML that has a document discount
Steps to reproduce:
- switch to the Italian company ()
- make sure that the VAT number on the document matches the one on the
company
- attempt to upload the XML bill
You should be met with an empty vendor bill page.
Cause:
The issue comes from here: https://github.com/odoo/odoo/blob/43c9820b1d3020d89b1b7ca016754e29d1fc6b58/addons/l10n_it_edi/models/account_edi_format.py#LL725C21-L729C83
in 16.0, `invoice_form` is not an instance of `Form`, but a record.
opw-3193634
closesodoo/odoo#123445
X-original-commit: 3443f2fbce36f800ebb5a87ce0d393dbcb30f2bc
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Issue:
------
When a list view is editable and we add a `Group By`,
the create button in the header is no longer available.
This is annoying when we are working with default filters
and do not have any records.
Solution:
---------
Add the "New" button in the header of the list view
and redirect to the form view when we use it.
opw-3304692
closesodoo/odoo#126710
X-original-commit: 8332cca8926a8d032f921b39520227070303fcc5
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
1. Introduce primary variable to simplified overridden value of
`$min-contrast-ratio` and document its need.
2. Reduce `$min-contrast-ratio` to 2.9 to solve the inconsistency with
the previous version 15.0 of text color over some background color.
Of course it won't restore everything to the way it was: we still
want the version 16.0 to be an evolution over version 15.0 using what
bootstrap recommended to compare contrasts. But as going from 3.0 to
2.9 should not impact existing websites too much and solve use cases
we feel need solving, we feel it is an ok change.
3. Restore override of the `color-contrast` method that will now
handle the transparent colors. Before this commit, a color-contrast
function was just considering RGB value only, after this commit it
will consider RGBA value, relying (by default) on the fact the body
background is the background behind the colors we are comparing.
task-3241031
closesodoo/odoo#126759
X-original-commit: 313220ed4a0ff4ae26eb113a3a88b0dc44b649fe
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Divyesh Vyas (divy) <divy@odoo.com>
Release notes:
https://github.com/odoo/owl/releases/tag/v2.1.4
This release contains mostly devtools improvements, but there are three
small bug fixes as well:
[FIX] blockdom: properly merge dynamic class values
[FIX] parser: make t-on stricter
[FIX] compiler: apply translations to t-set text body
closesodoo/odoo#126755
X-original-commit: b26a66d928aad283c7ec17d767c6bc1e42e24206
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
Signed-off-by: Géry Debongnie <ged@odoo.com>
When a user creates the task without a name field and directly clicks on the
'Mark as Done' button, will give UnboundLocalError like the local variable
'task' referenced before assignment.
Steps to produce:
- Install the 'Field Service' module.
- Field Service > My Tasks > Open any task.
- Make the name field unrequired (Studio or Edit form View)
- Create a new task > Set the Customer field and leave the Name field as blank.
- Before saving the task click on the 'Mark as Done' button > Discard Changes.
- Error will be produced.
Fixing the indentation for `task.date_last_stage_update = now` will solve this
issue. We have used the task variable in for loop.
Sentry-4276832131
closesodoo/odoo#126752
X-original-commit: c3649a32c98d7093610a4367b1e72c1b4b0085b7
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Current behaviour:
Any product type of product that is sellable can add
`service_tracking` option on the product.
Expected behaviour:
`service_tracking` should be available only for services that are
sellable.
Steps to reproduce:
- Install `sale_project`
- Create a new product, type `consu`
- Observe we have the `service_tracking` option available (create
project/task/project&task on SO confirmation)
Reason for the problem:
Incorrect domain for the `service_tracking` field in the view.
Fix:
Correct domain for the field. The field should be `invisible` only
when the product `type` is not a service *or* it's not sellable.
Affected versions:
- saas-16.3
- master
opw-3366909
closesodoo/odoo#126750
X-original-commit: 1634019df17d25167bad091933d757f706f7549b
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, if you reset your microsoft callendar account and
set to remove events from Odoo, it won't remove them. The problem is
that the ('ms_universal_event_id', '!=', False) condition is not
implemented, and it can't remove the existing events.
opw-3382445
closesodoo/odoo#126739
X-original-commit: c4d8530c51e48e1f7c264b2b0c1efdab8d1fe0e6
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
=== ISSUE ===
With Milk, we introduced a change related to the active state color
meaning that the `active` state should use the following SCSS variables:
- $o-component-active-bg for the background ;
- $o-component-active-color for the text ;
- $o-component-active-border for the border.
The datetime_picker component was currently using the primary variable
which is not the expected color. This change also affects the different
states of the datetime picker (hover, click, ...)
=== AFTER ===
We apply the right variables on the component for consistency purpose,
and make some little design adjustments using `:before` and `:after`
pseudo elements to stylize the different states.
task-3329797
part of task-3326263
closesodoo/odoo#126728
X-original-commit: df0e75d36bfe85bdbe0a9823003e0849c17a9405
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, if you scan a barcode that it's not related to a
product it opened a popup and showed an error. The solution is to
open the popup outside the `_getProductByBarcode` function.
opw-3357131
closesodoo/odoo#126668
X-original-commit: dcd710dcc50b0d3f10f7bf0bdf0ce33360657439
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
This is a missing test for #126066 .
closesodoo/odoo#126667
Task: 3370869
X-original-commit: 1b4a0d871662670ec2a360379913d1e30feec40c
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Pawel Fertyk (pafe) <pafe@odoo.com>
Before this commit,
In the knowledge app, the date and datetime property fields are not visible in
the item-kanban.
Technical Reason:
In the previous version's date and datetime property field values are of
string type in a non-ISO format. However, from the version 16.2, the values of
date and datetime property fields are of datetime object, which parsed into the
string type ISO format, that's creates the formatting issue.
After this commit,
Now the date and datetime property fields are visible in the item-kanban.
Task-3324573
closesodoo/odoo#126657
X-original-commit: c2868b0c18bc89fd06c7bee43488a1fb1fc4bb67
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
Change the default `chart_template` of Spanish localization
to `PGCE PYMEs 2008` instead of `PGCE entidades sin ánimo de lucro 2008`.
Also reflect this change in demo data.
This make sense to be the default one installed, and is also consistent
with our (documentation)[https://www.odoo.com/documentation/16.0/applications/finance/fiscal_localizations/spain.html].
opw-3329987
X-original-commit: 596eb201bee907d5f956b6aaf88433bb72e2cb10
Part-of: odoo/odoo#126649
When you install a localization with multiple `chart_template`,
the first one in alphabetical order is installed by default.
This is not always the more relevant configuration.
This PR adds an optional `sequence` parameter to `chart_template`
that will be used to decide which one will be used when installing
localization for the first time.
opw-3328807
X-original-commit: ee6408250b13c3ef8160f7f777d9bb8efcaeb37d
Part-of: odoo/odoo#126649
Steps to reproduce the bug:
- Drop the image-text snippet on the homepage.
- Double click on the button inside the snippet.
- Choose the homepage as the URL ("/").
- Open the "Page Anchor" selector and click on "#top".
- Bug: the select does not close itself after selection.
This bug occurred because there are two instances of Bootstrap on the
same element (the link anchor dropdown): the "bs.dropdown" instance and
the "bs.tooltip" instance. The tooltip instance was added by this commit
[1], probably unintentionally during a copy-paste operation.
Additionally, the text of the Tooltip was not correct ("Link size").
Having these two instances on the same element caused an error because,
since this commit [2], we check that an element doesn't have only one
instance. If multiple instances are found, the others are disabled. This
check was the reason why the "bs.dropdown" instance stopped working.
Note that we could have kept the Tooltip by moving it to the
"we-toggler" element. However, we removed it because it didn't provide
any additional value, the text of the label itself is sufficient.
[1]: https://github.com/odoo/odoo/commit/740168ce8d27da3d6a7156d2d79655a898394923
[2]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
task-3378864
closesodoo/odoo#126715
X-original-commit: 6367129caf2c5d4e59ba7db0fe47047be0cb6caf
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit improves the appearance of property fields in the Kanban view of
item Kanban. A label will be shown for the integer, float, date and datetime
property fields. Additionally, The boolean field now has a badge appearance
with a label.
Task-3291930
closesodoo/odoo#126707
X-original-commit: 25e8fbe0a1327c289df826cf6eb7882098a4c325
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, if you stopped sync with microsoft, and
refereshed the calendar, it would change the button back to
synced status.
opw-3382311
closesodoo/odoo#126706
X-original-commit: 1e0e4e8a792513ddecc27ab42d76be0c5873c8bc
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Issue:
------
When applying for a job via an alias mail,
it is sometimes possible to get the wrong information
for the applicant's name and email.
For example:
Applicant's Name: "FirstName SecondName
Email: "FirstName SecondName" <name@example.com>
Because of this, it is not possible to send an e-mail
(for example, to set up a meeting)
because the latter is erroneous.
Cause:
------
Many e-mail services add the name associated with the e-mail in the header.
Example of a sent e-mail (can be retrieved with "Show original"):
```eml
MIME-Version: 1.0
Date: Wed, 21 Jun 2023 12:09:34 +0200
Message-ID: <CAHbiOmS_PHojqKMhoji9iev4I6pzuJ1=dVHgLKNh3SOS_mw7+w@mail.gmail.com>
Subject: Subject test
From: FirstName SecondName <name@example.com>
To: team-recruitment@company.com
Content-Type: multipart/alternative; boundary="000000000000f7db4305fea0f6c3"
--000000000000f7db4305fea0f6c3
Content-Type: text/plain; charset="UTF-8"
Message test
--000000000000f7db4305fea0f6c3
Content-Type: text/html; charset="UTF-8"
<div dir="ltr">Message test<br></div>
--000000000000f7db4305fea0f6c3--
```
Solution:
---------
Use `_parse_partner_name` method
to correctly parse the e-mail
and partner's name.
Note:
-----
Not add `email_from` in `_primary_email` field.
Otherwise, they will be override with the "raw" value.
opw-3347313
closesodoo/odoo#126678
X-original-commit: 551685368971161975d64f480e9bec326db8931e
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
This commit adds Bootstrap JS assets to the web.report_assets_common bundle,
enabling basic interactivity in reports. Currently it is only necessary to allow
JS in the report_layout template.
#104794 removed all JS from reports, stating that they don't need any
interactivity. However, reports do sometimes require a bit of JS. An example is
the Green Savings Report in Sign (see task), which contains a Bootstrap modal.
By adding Bootstrap JS assets to web.report_assets_common, we can make the modal
work again. Additionally, we can fix/add basic interactivity in other reports if
necessary.
task-3285597
closesodoo/odoo#126638
X-original-commit: 21caa81fad84d05b76bd178242a991eef803e4b8
Related: odoo/enterprise#43263
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Viktors Lipskis (vili) <vili@odoo.com>
Since [1] the way thread icons are assigned to thread changed.
This caused an issue with livechat thread expecting the default
icon to be the "smiley avatar" which is not the case anymore.
This PR fixes this issue by effectively defaulting to the "smiley
avatar".
[1]: https://github.com/odoo/odoo/pull/125388closesodoo/odoo#126629
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Adding an override for new secondary outlined buttons that was
missing in community
Task-3380259
Part of task-3326263
closesodoo/odoo#126604
X-original-commit: ddf77772c7f02a002da4525545111e9f501b07eb
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
On the Blanket Order PDF (as well as other purchase agreements), the
vendor isn't specified on the report while it is a required and
significative field on the purchase agreement.
Added it like in the purchase order PDF.
Also added in the Custom Description field into the PDF as it may
contain useful information as well.
Task-3358385
closesodoo/odoo#126561
X-original-commit: 926c6b4aa34c7df46de3121c97742caccbc39be2
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
This PR improves the livechat channel form view:
- managers can remove operators from channel
- operator online name is displayed
part of task-3332872
closesodoo/odoo#125774
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This change introduces ability for users (who don't have enough karma)
to create one pending post per forum.
Previously users could only do it in all of forums.
ticket-3354435
closesodoo/odoo#124112
Related: odoo/upgrade#4841
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
The `name_search` makes at least 2 SQL requests, one to find the records
and one to read fields needed to compute the `display_name`. With the
default `_compute_display_name`, it only needs to fetch the `_rec_name`
field (if there is one), but the ORM perfetch field mechanism will also
fetch every prefetchable field (see `_fetch_field`).
Then, to avoid running two queries and fetching too many fields, we add
the dependency fields (with `_determine_fields_to_fetch`) to the select
clause of the `Query` returned by `_name_search`.
Part-of: odoo/odoo#122085
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
Purpose
=======
In the documents modules, we don't need to give the close props,
and so instead of giving a dummy method, we make it non-required here.
Task-3290796
closesodoo/odoo#126633
Related: odoo/enterprise#40441
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, when opening self-chat and trying to add users,
self id was duplicated with the chat partner id, leading to a crash.
This commit fixes the issue by removing duplicates in inviting users,
so that there's no longer a crash when inviting users in self-chat.
task-3381895
closesodoo/odoo#126605
X-original-commit: d101a82b97989d5c60c1b6dfbc5fa2143680bd3c
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit fixes the malformed comment that would sometimes comment out
the rest of the html resulting in an improper display.
this is due to the new html5 notation --!> not behing understood by
our parser.
this commit replaces any --!> into -->.
this commit also remove <!--> or <!--->
opw-2812488
closesodoo/odoo#126148
X-original-commit: 4fed0c36fedf271acc3520d8219763964753dabe
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
This PR improves the livechat session history list view:
- Clicking on a session opens the channel in discuss if the
user is a member of it. Opens the form view otherwise.
- Display duration of the session (last message datetime - first
message datetime)
- Display country of the visitor
part of task-3332872
closesodoo/odoo#125899
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Since stock.quant are directly related to their lot/serial, we want to be able to show the lot properties on the related quants.
We also want to be able to filter quants based on the properties of their lot/serial.
closesodoo/odoo#125197
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Form fields can be prefilled since [1] and their visibility
conditionally linked to other fields since [2].
1. This commit ensures prepopulated fields trigger the conditional
visibility mechanism (A), including when said field is first hidden,
then conditionally displayed (B).
2. Until [3], with a chain of visibility conditions, when one of them
was "contains", "does not contain" or a date-related condition, a
traceback was raised (C). This commit corrects the fix from [3] to
prevent this behavior now that the reason has been identified.
3. Tests are also set up to enforce these fixes.
Steps to reproduce (A):
- Drop a form
- Make field A depend on field B being set
- Have field B be autopopulated from user mail
- Save and check the form: A won't be shown despite B being set
- Removing one letter or typing anything in the input B will trigger
the visibility of A.
- Expected result: B should immediately appear.
Steps to reproduce (B):
- Drop a form
- Make field A depend on field B being set
- Have field B be autopopulated and depend on field C being set
- Field C is empty by default
- Save: only field C is shown. Type a letter: field B appears, but not
field A.
- Expected result: both should appear.
Note: this bug only occurs when field A is before field B.
Steps to reproduce (C) (until [3]):
- Drop a form
- Field A depends on B containing "abc"
- Field B depends on C being set
- Save and type something in C: there is a traceback.
task-3335536
[1]: https://github.com/odoo/odoo/commit/54873d2
[2]: https://github.com/odoo/odoo/commit/2dcbfec
[3]: https://github.com/odoo/odoo/commit/2714469closesodoo/odoo#126634
X-original-commit: 074dbb6842de1092af2abe51e6da0433ff38a96e
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Setting or changing the manager of an employee would not refresh the
OrgChart.
task-3381781
closesodoo/odoo#126617
X-original-commit: cbd5feed298efece8809d13434409e50326bd79b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
before this commit, name and method field in the
product.removal model is not translatable and
thus always display values in english
after this commit, the field will be translatable
and values will be shown based on the user
language
closesodoo/odoo#126610
Signed-off-by: Tiffany Chang <tic@odoo.com>
Hugo Carlier (Huca)