Technicaly it's anoying to create orderpoint and explicitely
set the product_min and product_max to 0.0. If another value
should be use, it would probably not be forgotten.
Task: 2161378
Usabilty. Move the route button under the route params.
People had issue with route and didn't know that this
report exist. We hope that moving it under the route will
help user to configure their route.
Task: 2161378
Set a default route on orderpoint created by the replenishment report.
First it select the first route on the product if it exists (it's
uselss since it's a preferred route on the report but it's used for
clarity). If the product has no route then it tries to guess it
with vendor pricelist or BoM on the product.
Task: 2161378
New report to easily order missing products in each warehouse.
Orderpoint have a new type: 'manual'. Manual orderpoint are not
trigger by the scheduler but the user could create replenishment
from the report directly. The report use the forecast report in
order to detect missing quantity for today (it does not search
depending the lead time for each product warehouse due to lake
of performance). It compares missing quantity with incoming RFQ
and other ongoing orderpoint. If it still missing a new entry
for replenihsment is created (it's also automaticaly deleted if
the replenihsment has been done another way).
Task: 2161378
_search_rule on procurements search in a specific way in this order:
- First: route passed in the procurement values
- Second: route on product/product category
- Third: route on warehouse
- Fourth: remaining route.
However _get_rule doesn't allow to simulate the first usecase with
the route on procurement. This commit add the functionality.
(Usefull for replenishment report where a route_id could be set
on an orderpoint)
Task: 2161378
Have a list view with an Owl field component (e.g. widget="badge"),
visible. Open the optional field dropdown and make another field
visible.
Before this commit, the '_onToggleOptionalColumn' handler was
executed twice, because two click events where triggered: one on
the label, and one on its associated input (because of the for
attribute, see [1]).
As a consequence, the new field was added, and directly removed
from the view. This could even cause subsequent crashes.
The difference between an Owl component and a legacy widget is
that the Owl component is async (more than a nextTick) as we wait
for the nextAnimationFrame to render. When the rendering is fast
enough (e.g. without Owl components), the click event isn't remap
to the input yet (because we empty the list HTML node), so the
handler is executed only once.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/label
Issue reported on task 2204306
closesodoo/odoo#49920
X-original-commit: b02d347e8770835ad28a6487071930a904bce101
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The fields `constr_mandatory` and `constr_error_msg` were removed in some
recent cleaning. They should be available in the survey question form view.
Task ID 2235528
closesodoo/odoo#49919
X-original-commit: 10731089ccd471cb5e70500276061017a1cc6c6a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, It was not possible to copy An employee which is already linked to User due `user_uniq` constraints.
Now we add `copy=False` on `user_id` field, so Employee will be copied without linked User.
closesodoo/odoo#49915
X-original-commit: 2a63df03859166414be338c6655ee8c4052666b7
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, There would be an error due to the required field `name` which was not passed in vals when the user creates new Redirects through Manage Pages from Website, while the `name` field is required at the model level.
In this commit, we pass 'name' field in the values of `website.rewrite`
Followup on be8fc2296bclosesodoo/odoo#49748
X-original-commit: a8125ebc1480b5b215bf3737f4e799ead5b34d9d
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When an element is clicked during the test and a tiemout occurs, message
that appears in Odoo logs is not really clear.
closesodoo/odoo#49907
X-original-commit: 0e1545c52fdca6d311a18533d3d4efed984df329
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, the result of our custom qunit assert
'doesNotHaveClass' was incorrect when it was called with
several classnames.
For instance
assert.doesNotHaveClass(<span class="a"/>, 'a b');
passed, whereas it shouldn't.
closesodoo/odoo#49892
X-original-commit: c40fc67a130ae8e0f061a89d3a21d2507a0f9ae3
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the rainbow man message at the end of tours is fixed
to a hardcoded message.
This commit allows to customize the message within the definition of the
tour, to add the ability to use tailored messages depending on the app
the tour is about. If no custom message is set, the old default will
still be used.
Task ID: 2241549
closesodoo/odoo#49779
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the bug:
- Let's consider a consumable product P with an internal note IN
- Create a SO with P and confirm it
- Process the delivery and validate it
- Print the delivery slip
Bug:
The internal note NI was displayed on the delivery slip.
Fine tuning of https://github.com/odoo/odoo/commit/038221f3180a7a8888503553dbb5eb57875ef3a6
opw:2227613
closesodoo/odoo#49860
X-original-commit: 9b6ea1cdbed02c0f2ccd3e2608e4caf12c8c24ac
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
No functional change, only technical performance improvements. Purpose is
to improve count performances (meeting count, applicant count), ... by using
a read_group and maybe adding missing indexes.
LINKS
Task ID 2196182
PR #44662
Related: odoo/upgrade#973
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
No functional change, only technical performance improvements. Purpose is to
improve forum.post child_count performance.
LINKS
Task ID 2196182
PR #44662
PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
There may be a lot of clicks linked to a given link tracker. Compute the count
of clicks in batch with a read_group to improve performance.
Same for utm campaign mailing count performances.
Some missing indexes are added to speedup queries.
LINKS
Task ID 2196182
PR #44662
Co-Authored-By: Victor Feyens <vfe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
No functional change, only technical performance improvements. Purpose is to
improve meeting count performances.
An index on applicant is also added to speedup queries.
LINKS
Task ID 2196182
PR #44662
Co-Authored-By: Victor Feyens <vfe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
PURPOSE
Several counter fields are performed inefficiently. They use compute methods
using length of 2many fields instead of making use of more efficient ORM
methods like read_group.
SPECIFICATIONS
No functional change, only technical performance improvements.
Purpose is to improve lead_count performance. Some people claim to gain a lot
of queries: from 90 to 30 SQL queries to read 39 partners. Hard to reproduce.
LINKS
Task ID 2196182
PR odoo/odoo#44662
Co-Authored-By: Fabien Pinckaers <fp@odoo.com>
Co-Authored-By: Victor Feyens <vfe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
In v12, the hr module did not have a hard dependency on mail_bot, so the users could uninstall it if they did not want/need its functionality. In v13, mail_bot was added as a dependency to include the notification widget and the odoobot state in the user forms modified by the hr module. However, this also brings potentially unwanted functionality to anyone who installs an hr related application.
This commit removes the dependency on mail_bot by adding the mail_bot_hr bridge module, which has the odoobot state field and includes a dummy notification widget.
Additionally, the automated answers from OdooBot like "Pong" that fill the chatter and annoy many users have been removed.
Task ID 2200878
closesodoo/odoo#48521
Related: odoo/upgrade#1089
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, when there is promotion with usage Automatically Applied
and creating quotation without reward line but on copy of that order
the reward line will be added even the original quote did not have the
reward line(discount).
So in this commit, on copy of the sale order, unlink and apply reward
line only if origin sale order has the reward line.
TaskID: 2228249
OPW-2227968
closesodoo/odoo#49798
X-original-commit: 88aae85cafaeec763a05f49003aff5d593a8922d
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Co-authored-by: Mahendra Barad <mba@odoo.com>
Co-authored-by: Rushi Sathawara <rus@odoo.com>
Currently in kanban view which contains search panel when user click
on kanban dropdown menu then a dropdown menu will be hidden due to
scrollbar of kanban view.
This issue arises from this commit:
https://github.com/odoo/odoo/commit/a95cbbd631a2fa9be62eb42cba43e853fdf4b789
closes odoo/odoo#49791
Task-id: 2204306
Closes: #47586
X-original-commit: d613bb8ba4f5a4d818592a80f4aee2ef67916bc0
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce:
- install website
- install the theme "clean"
- go to website > customize > customize theme
- select the first "extra color" (alpha) and change it
Previous behavior:
All extra color that have not been set previously have changed
automatically without notice
Current behavior:
the theme is either showing primary/secondary colors or only "extra" colors
Good themes are supposed to enforce primary = alpha and secondary = beta
All extra color that have not been set previously change automatically but
an information tooltip shows up when you hover alpha to avoid confusion
opw-2180611
Forward-Port-Of: #46099closes#49730closesodoo/odoo#49789
X-original-commit: c9aada53b1e6b24da4e1fe9ac4d44db3ff8cacda
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
For some specific report (i.e account followup report) the mail_message
sent will contains no company informations because it will be sent on
the partner context, so when generating the template the logo will be
retrieved from the route /logo.png?company=False which yield back the
odoo company logo.
Adding a default 0 allow to retrieve the company logo for the current
user
opw-2232184
closesodoo/odoo#49787
X-original-commit: eea99fe1e00eb2dbd2bbeaca3e2f09845b426267
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Impacted modules:
hr, hr_contract, hr_recruitment, hr_payroll, fleet, hr_skills, hr_appraisal, ....
Several onchanges have been converted to computed fields in the following modules :
Community :
- hr
- hr_contract
- hr_recruitment
- hr_work_entry
- hr_maintenance
- hr_expense
- hr_expense_check
- hr_holidays
- sale_expense
- account_analytic_default_hr_expense
Enterprise:
- hr_contract_salary
- hr_referral
- hr_payroll
- hr_payroll_expense
- test_l10n_be_hr_payroll_account
There are still 2 onchanges with complex behavior that couldn't be converted easily:
- an onchange that updates "tz" (timezone) that is defined as a related field
to "resource_id.tz". Apparently it is useless except to initialize the default
value of "tz".
- an onchange that updates "name" that is defined as a related field to
"resource_id.name".
the applicant.
closesodoo/odoo#45414
Taskid: 2169099
Related: odoo/enterprise#8572
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, the 'selection' fields were treated like 'char' fields in the
"Add Custom Filter" menu of the control panel's filter menu. This meant that their
value was defaulted to "".
Now, the default value of a selection field is its first selection value.
closesodoo/odoo#49772
X-original-commit: 62b62570725bc8eb3d3fa77fd1e8efd7a4fb5d2b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Purpose
=======
Avoid to show to much information to leave responsibles.
Specification
=============
- Dynamically add/remove the leave_manager_ids on the group
group_hr_holidays_responsible, on employee creation/modification
- Retrict the available employees when creating a leave. For
manager/users : Everyone. For responsibles: The employee for
who the user is responsible. Otherwise: Only me.
- Don't obfuscate the leave name on employees for who I'm the
responsible.
- Add a new SQL view for "Everyone" report. To select only the
information we want to share instead of showing the hr.leave
model directly.
closesodoo/odoo#47659closesodoo/odoo#49765
Taskid: 2206862
Related: odoo/enterprise#9239
Related: odoo/enterprise#10021
X-original-commit: 781147dcaf1552b8f2ab687ed73034b8fd1f7352
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Or, in other words, set auto probability to 0 if no statistics yet.
Before this commit, if the automated probability could not be computed,
the automated_probability field on crm.lead was not modified.
That led to having leads stuck at 100% once won, even if going back to another
stage.
This happened only :
- in an empty DB (no demo data) or
- in a DB where the PLS cron had never ran and the PLS threshold was
inactivated (=0).
Because, if the frequency table has never been built, we cannot compute the
automated probability.
After this commit, if the automated probability cannot be computed, we set
it by default to 0. If the probability and the automated probability was
aligned, probability is also set to 0.
Note: this could be an issue if both probabilities were aligned, then
someone deactivate the PLS cron and set the threshold to 0 (if not yet the
case), and clear the frequency table. (unlikely to happen but still..)
When updating updating a lead, we would lose the probability
-> auto proba set to 0 + proba set to 0 as they were aligned.
Task ID: 2232036
closesodoo/odoo#49766
X-original-commit: b43ecf73958273a126135966422112b90f9f12cc
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to clean test that broke nightly recently.
Task ID
closesodoo/odoo#49759
X-original-commit: 61f9b05ccc61a7e00dc5cc43cb1f8196195bee60
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
According to some PO, the email is useless to salespersons.
According to salespersons, the email is very useful.
This reverts a26a010324
opw-2215123
closesodoo/odoo#49756
X-original-commit: 0709890357005e4c1b205816061c3ec1582ad16d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider the customer invoice journal J with the default credit account A1
- Let's consider a customer invoice I with one line L1
- On L1 is set account A2 and product P1
- Import on I a new line L2 with account A3 and product P2
Bug:
The account of L1 was changed by A1 instead of keeping A2
opw:2230808
closesodoo/odoo#49582
X-original-commit: 115a18a1cdecdc6d76920efdf323fb91f2f408ee
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Issue
- Install Dashboard & Sales
- Add a graph & a list to the dashboard
- Go in the dashboard
Rendering ok
- Click on a list item
- Go back with the breadcrumb
Traceback
Cause
When going back with the breadcrumb
we retrieve the previous view controller.
https://github.com/odoo/odoo/blob/9400059073d7401789eb1a60d6a0ec6f58dfc66b/addons/web/static/src/js/chrome/action_manager_act_window.js#L457
By restoring the board controller, we
restore all the subcontrollers too.
But the actual board renderer is re-creating
controllers. This creates inconsistencies
with the view.
Solution
Remove the restored controllers
OPW-2232713
closesodoo/odoo#49728
X-original-commit: 4f3d818052d689da762d8afbf1789daaa3d39821
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Consider a sales order with a single line. Edit the sales order: remove
the line, and add another line with the same subtotal. When saving, the
total of the sales order is 0.0.
Here is the explanation: the form view performs a `write` on the sales
order, and modifies the lines with a command `2` (remove line) and a
command `0` (create line).
After deleting the first order line, the cache is emptied, and a call to
`flush()` forces the recomputation of the total. The value is computed
to be 0, and assigned to the field. The assignment converts the value
for the cache, without prefetching the currency field (optimization),
and puts 0.0 in cache. The assignment then converts the value for the
database, which prefetches most fields on the sales order: the cache is
now inconsistent and contains the old value V, while the database is
then updated with 0.0.
After creating the new order line, the total is once again recomputed.
Its value is V, and because the cache also contains that value, no
update is performed to the database, which remains at 0.0!
The fix consists in avoiding the prefetching of fields when accessing
the currency field to round a monetary value.
opw-2223134
closesodoo/odoo#49741
X-original-commit: 048ea2f20a0a2fa6d629cbe262cbbe765248d36f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
During the onboarding, if Invoicing is installed but no chart of account
is set the field property_account_receivable_id and
property_account_payable_id prevent from validating a new partner
because they are required but not auto-filled, and the fields are not
visible if Invoicing is not installed.
closesodoo/odoo#49732
X-original-commit: 29c362b7c3353c2be11ab117f454d04ed9853f75
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
Arnold Moyaux