Generic search bar was introduced with #65871.
But the trigram search would fail if it encounters a (SQL) NULL text
from the database. This is because when word_similarity() receives NULL
as a parameter it returns NULL, and NULL not being a number cannot be
compared with the similarity threshold.
After this commit the trigram search will exclude matches returning a
NULL similarity.
Step to reproduce:
- Enable trigram in the DB, run `CREATE EXTENSION pg_trgm;` in psql
- Create a product, name it `myproduct`
- Insert NULL values inside the translation table (not sure how the
user did it):
`update ir_translation set value = NULL where src = 'myproduct';`
- Search 'mypro' in the eshop search bar
-> Traceback
opw-2680659
closesodoo/odoo#80426
X-original-commit: ef17edc32d4646c93e31e730249be83469951241
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
These negative tax groups were removed in a previous commit:
1687248
The message of the previous commit was:
Remove the negative tax groups from account_data. The negative tax groups have no application. The taxes that were in the negative tax groups are reassigned to their positive counterparts.
The previous commit was accidentally overwritten in a forward-port:
odoo/odoo#77295closesodoo/odoo#76586closesodoo/odoo#80240
Signed-off-by: William André (wan) <wan@odoo.com>
Purpose of the commit is to do the generic improvement for the
project:
So in this commit, done the following changes:
- duplicating a project, copy all milestone of project and
set is_reached and deadline field as 'False'.
- chanage the order of the state button in sale order form view.
- pass mail body as default description value in message_new
method of project task.
task-2652943
closesodoo/odoo#77065
Related: odoo/enterprise#21199
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Previously, when underconsumption occured, we split the move (in
post_inventory). And if backorder, the moves not done would be linked to
the new backorder MO (when backorder MO is created).
After 8883c06ada, we create backorder MOs
before _post_inventory, making it so the moves not done will not be
linked to the backorder MOs and reserved qtys are not released.
To fix, we set cancel_backorder to be true to cancel all the leftover
moves and release the reserved qty.
Task-2697611
closesodoo/odoo#80446
X-original-commit: cffb2b455d73f64d96f91b9e0301c346989eae63
Signed-off-by: Tiffany Chang <tic@odoo.com>
Instead of "saving" the state into the DOM (which is lost at next render) save
the state of each button in JS.
task-2308951
closesodoo/odoo#80358
X-original-commit: 58d4d65e98d8f5196b4d6ca91cd5df96dfac1360
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this fix, all moves of type “entry“ were considered as misc operations in regard to repartition tags and the tax report. And only moves of type “out_refund” and “in_refund” were considered refunds.
Now reverse entries with sale/purchase taxes get their tags set accordingly to repartition lines.
Account D C Tax Tax Grids
700000 Ventes en Belgique (marchandises) 0 1000 21% +03
451000 T.V.A. à payer 0 210 +54
400000 Clients 1210 0
Was reversed to:
Account D C Tax Tax Grids
700000 Ventes en Belgique (marchandises) 1000 0 21% +03
451000 T.V.A. à payer 210 0 +54
400000 Clients 0 1210
Is now reversed to:
Account D C Tax Tax Grids
700000 Ventes en Belgique (marchandises) 1000 0 21% +49
451000 T.V.A. à payer 210 0 +64
400000 Clients 0 1210
closesodoo/odoo#80427
X-original-commit: a337d5d5b3886eabbdc8de95eb615dffc91d5d8e
Related: odoo/enterprise#22532
Signed-off-by: Olivier Colson <oco@odoo.com>
The currency.compute method is deprecated. We use _convert instead
closesodoo/odoo#80416
X-original-commit: 8fa0312d4a59198757a0daab68927e75fa1bab23
Related: odoo/enterprise#22527
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When editing the billing address of an existing portal partner P,
the salesperson of P was changed by the default website salesperson
opw:2649732
closesodoo/odoo#80415
X-original-commit: 52442484897d95bfffa3f8672908bd3d00923363
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When the user opens the survey module for the first time, the user may
find it difficult to create and configure a new survey as there are many
options available. To improve the onboarding experience of the user, we
will provide a new link on the action helper of the survey module (for
the kanban and the list view of the surveys).
When the user clicks on that link, the system will open a new modal. The
user will then be able to choose a sample to load. Each sample will be
pre-configured for specific purposes. We will have:
- A sample for the feedback forms
- A sample for the live presentations
- A sample for the certifications
After loading a sample, the user will be able to adapt it to fit their
needs. Thanks to the samples, the user can create a survey more easily
and more quickly.
task-2670605
closesodoo/odoo#79255
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Co-authored-by: Carlos Valverde <cvs@odoo.com>
Purpose
=======
As an Interviewer, I want my questions to be as clear as possible. To this end
I would like to be able to detail a bit which kind of answers I expect.
Specifications
============
For all the question types that require an input, display a char field
"Placeholder" in the Answers tab with an helper that says:
"When set, this text will appear in the field to help participants answer."
Then on the survey, display the placeholder in the question input zone.
Task-2671388
closesodoo/odoo#78682
Related: odoo/upgrade#2998
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* Avoid computing logic in get_values, use a clean compute instead
* Leave the management of config parameters to the generic behavior in
base, no need to override set_values to do it "manually".
Furthermore, in the mail case, the set_values override enforced the creation
of a falsy parameter, which goes against the generic parameter logic to avoid
having falsy values for nothing in database.
Part-of: odoo/odoo#62249
When "Saving" a settings wizard, all its settings are written, even if
not modified.
This implies updating ir.default and ir.config.parameter models.
By verifying whether there were effective changes, we can
avoid:
1) the searches to get the corresponding records from database
2) the cache clear triggered by default/parameter updates/creation
This commit thus reduces the queries triggered when saving settings,
but also the queries of future operations, since we avoid clearing
the ORM cache if not needed.
Part-of: odoo/odoo#62249
The settings wizard provides the implied_group logic to add/remove
implied_groups to an existing group (by default base.group_user).
When verifying those special fields (onchange, default_get and execute
calls), ref is called once by group, by field.
E.g. a field
group_broll = fields.Boolean(implied_group="broll")
will trigger two refs ("broll" & "base.group_user") for each
onchange/default_get/execute call on res.config.settings.
This commit uses the cached method to fetch ir.model.data,
avoiding a lot of queries (depending on the fields defined on
res.config.settings model)
Part-of: odoo/odoo#62249
Following the API for ir.model records, the same logic is provided for
ir.module.module records.
This allows to avoid a bunch of queries when modifying/opening settings.
Part-of: odoo/odoo#62249
At create, the ORM fills the missing create values with the defaults,
calling default_get.
In the case of res.config.settings model, the default_get overrides triggers
a lot of operations to manage its custom field logic (config parameters,
defaults, modules installation, ...).
This slows down the creation (and application) of settings updates for "nothing".
This commit ensures the defaults are not recomputed for fields whose value
was provided to the create call, reducing the effective time of settings flow.
Part-of: odoo/odoo#62249
Steps:
- Install POS
- Create Tax T :
- Type : Sales
- Computation : Fixed
- Amount : x
- Create a product P with price 0
- Go to POS and select P to sell it (qty = 1). Taxes = x
- Now set qty = -1.
Issue:
- Taxes remain x where it would be expected to be -x.
Cause:
- The calculation of the price doesn't take the sign of the qty into account
because it takes a "base amount" that takes it into account.
- However, this base amount doesn't give any indication about the qty,
which is necessary to determine which way the tax should be applied.
Fix:
- If the "base amount" is zero, return quantity * fixed tax.
opw-2655317
closesodoo/odoo#80389
X-original-commit: 6a4f51f4254041229cf264d713f0d2b0db880601
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit, when the user creates a quotation and add a SOL with
product contained a project in `project_id` field, the
'Project Overview' stat button is shown even if the quotation is not
confirmed.
This commit changes the visibility condition of this button to display
it only if at least a project is contained in `project_ids` field of
`sale.order` model and if the quotation is confirmed that is when the
quotation becomes a sales order.
Step to reproduce:
=================
1) Go to the Sales app
2) Click on 'Create' button to create a quotation.
3) Add a SOL with 'Customer Care (Prepaid Hours)' product
Actual Behavior:
===============
The 'Project Overview' stat button is displayed.
Expected Behavior:
=================
This stat button should not be displayed while the quotation is not
confirmed to become a sales order.
task-2697063
closesodoo/odoo#80408
X-original-commit: ed58a99a235e4116a13982a4615c1fc8948a6ecd
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
When cancelling a manufacturing order that does not include any
component, the associated moves won't be cancelled.
To reproduce the issue:
1. Create a storable product P
2. Create & Confirm a MO for 1 x P
3. Cancel the MO
4. Consult the form page of P
Error: The forecasted quantity of P is 1 instead of 0
The finished move associated to the MO hasn't been cancelled. Since [1],
we have the possibility to process MOs without any component, so the
cancellation process shouldn't be bypassed anymore.
[1] bf5e1debf9
OPW-2691422
closesodoo/odoo#80407
X-original-commit: 2adff866a598fc8fb872fb8127875fbb7cc7335c
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When we are syncing Outlook events with Odoo events, there is no need
to call back the Outlook API to patch/delete some events.
closesodoo/odoo#80404
X-original-commit: c0094ec99e5fc24b650a257d4792f4be8b09a661
Signed-off-by: Arnaud Joset <arj@odoo.com>
After this commit, all users will be able to access the Debug Command.
closesodoo/odoo#80122
X-original-commit: faf208d939ea3a97ae85a31274b061c91e4cef7b
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
With a recent commit[1], we added the scrollerService. However, as a side effect
'Track Visitors' and 'Event Sub-menu' customize menus are not clickable because
they are anchor tags with href=# and the clicks on such anchors are disabled
with scrollerService..
With this task, we take the opportunity to clean up customize menus a bit
because and instead of the anchor tag, now such menus are wrapped within
label (<label>) tags with 'dropdown-item m-0' classes.
Menus are now cleaned and clickable again.
commit[1] - 0573aca
Task-2616588
closesodoo/odoo#80391
X-original-commit: 7e010500fbe64bddb944335ca5960586699484af
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently if event website menu main checkbox is unchecked the related website
menu is removed. Its children are also removed through the cascade attribute on
parent_id field.
However this is done in SQL, meaning some overrides on unlink of website.menu
is not called. This does not properly cascade unlink views linked to website
menus through the specific "website.event.menu" model. This leads to some
views staying alive in DB. This causes issues with web editor when calling
``_views_get`` as he may receive several views linked to a given view_id (key)
while it expects only one.
We fix that behavior by removing the menu and its children explicitly. This
calls various overrides done in website_event.
Task-2616588
X-original-commit: 9722baee83adea9808de1247c300e226cf6fc537
Part-of: odoo/odoo#80391
Currently in the mobile view, all the event sub-menus are showing horizontally
which looks ugly and hard for selection. This horizontal display is ok for
big screens, not for mobile.
This commit changes the direction of the events sub-menu from horizontal to
vertical when being in mobile. It also sets the left margin to fix the
flicker effect in the mobile view.
Task-2616588
X-original-commit: 2cb67c6be51af61fbdbe6f069e6a32839d7a682a
Part-of: odoo/odoo#80391
PURPOSE
After this commit when creating a partner the language will default
to the crm lead value.
LINKS
Task-2580065
Pr: odoo/odoo#76812
Related: odoo/enterprise#20689
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE
Before this commit, when a partner was created through the
suggested recipient tool the langage wasn't considered...
The email was thus sent in the wrong langage most of the time
After this commit, the suggested recipient tool had the
langage correctly if present in the record.
LINKS
Task-2580065
PR : odoo/odoo#76812
If the subject is not set, the wizard set the subject as "Re: False"
closesodoo/odoo#80372
X-original-commit: 169775419e0f14723c19ff5f14e0907c179721d9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When changing a value for a o2m (list) within a form, the _setValue
returned a Promise that did not take into account the real rendering of
the list renderer.
The use case at hand is:
- enable product configurator
- have a product with options
- add that product in a SO
- add the option as well through the product configurator
- confirm the configurator
The configurator triggers an add_record event, with an onSuccess callback
Before this commit, the onSuccess callback was called too early, when the previous
rendering operations were not finished yet.
After this commit, the onSuccess is executed when the list renderer is really ready
opw-2580044
closesodoo/odoo#79591
X-original-commit: 8def0d103020aed4211fd22f2b917567fb06de1e
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Commit [1] and its forward-ports introduced a test tour (properly added
in assets_tests) but was not declared as a test one. Meaning that if you
were in debug=tests, you were able to follow a strange tour not meant
for user testing.
[1]: https://github.com/odoo/odoo/commit/3c194faa930b0d3a537ca8b893b2c0442b5464e7closesodoo/odoo#80362
X-original-commit: 732addec9452813a404823f28703d54d37a6b87f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The use case happens in studio.
have some overflowing app submenus in an app
go into studio
refresh with a simple F5.
Before this commit, the navbar's overflowing buttons wouldn't put themselves inside the "more" dropdown
This was because the studio client action also reacts to change in the menu service, so the technical flow was:
- laodState (webClient)
- setMenu (MENU-CHANGED on the bus), then because of it:
- studio client action > render (1)
- studio navbar > render (with adapt right after that render!) (2)
- studio navbar > render (because of 1) which cancels the render in 2 without cancelling the promise, that is
adapt is still called.
To remedy this, the standard use of useEffect and useBus are is put into place.
After this commit, the studio navbar has its overflowing menu items in the dropdown.
The adapt algorithm now uses getBoundingClientRect to get the not rounded width of elements that should be adapted,
otherwise, slight differences in browser's computation and rounding of offsetWidth may influence test results.
closesodoo/odoo#80353
X-original-commit: 231902738287a897f50a1711f991bc55928b77d9
Related: odoo/enterprise#22498
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Introduce the onDestroyed hook which makes a callback executable
whenever the component is destroyed.
X-original-commit: 0f454392b39dcbc7e297e882117452c5adc342be
Part-of: odoo/odoo#80353
From a list view with multiple records, go on a record of that list
Click on the pager next button
Before this commit, the browser tab's title was not updated to the second records.
After this commit, it is.
closesodoo/odoo#80346
X-original-commit: 3d27b739a3e8243d50e9764000727b31727dc2d2
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Allow log date changes tracking by adding chatter on company and tracking lock date fields.
closesodoo/odoo#78730
Task: 2651834
Related: odoo/enterprise#22479
Signed-off-by: Laurent Smet <las@openerp.com>
Description of the issue/feature this PR addresses:
In hr_holidays, there is no information about the conflicting time off when a second time off is scheduled at the same time.
There is a validation error saying "You can not set 2 time off that overlaps on the same day for the same employee".
The validation error should display the conflicting time off
Current behavior before PR:
The validation error displays the following:
"You can not set 2 time off that overlaps on the same day for the same employee"
Desired behavior after PR is merged:
The validation error will display the following:
"You can not set 2 time off that overlaps on the same day for the same employee.
Existing time off: Mitchell Admin / Trip with Family : 24.00 hours / from 06/09/2021 to 08/09/2021 / To Approve"
task-2641682
closesodoo/odoo#76452
Related: odoo/enterprise#22490
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Some data are formatted as a tree structure with a relation of parent.
We are adding meaning to the structure:
* This improves readability and allows to fold/unfold records in
editors.
* This could be done before using `eval`, but this allows to have an
xml_id for those records. It also allows to update the records without
having to rewrite on the parent x2many field.
Part-of: odoo/odoo#76675
Before this commit, website shop had some blocks without names
which could make it hard for a user to understand to which block was
an option related.
This commit adds names to these blocks.
task-2670809
closesodoo/odoo#78889
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Benoit Socias