The decimal precision feature makes sense to be an ORM feature, no need to be
in a specific module.
The limitation was also that models like res.currency were not able to use a
decimal precision as this was raised at #19668
Keep a backward-compatible signature with a warning.
Task id: 48198
Closesodoo/odoo#25467
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since previous commit moved decimal_precision module's feature into base,
use the new syntax for fields declaration
Remove the imports to the removed module
Remove the module from dependency in manifest
sed -i "s|digits=dp.get_precision('\([A-Z a-z]*\)')|digits='\1'|" **.py
sed -i "/from odoo.tools import decimal_precision as dp/d" **py
As the decimal_precision module was removed, allow code like
from odoo.addons import decimal_precision as dp
fields.Float(digits=dp.get_precision('Foo')
to keep working
Co-authored-by: Olivier Dony <odo@odoo.com>
The decimal precision feature makes sense to be an ORM feature, no need to be
in a specific module
Previous syntax was
from odoo.addons import decimal_precision as dp
fields.Float(digits=dp.get_precision('Foo'))
and now is:
fields.Float(digits='Foo')
Remove the possibility to have a callable method on the digits attribute (it
was only used for precision anyway) and directly retrieve the digits on the
decimal.precision model
Rename the method digits to get_digits to avoid confusion between the field
attribute when declaring a field and the method to retrieve the precision
Task id: 48198
The formatLang method used to accept a value that has a _field parameter
This was introduced in 2010, at 6b19c64976 and is no longer used
Removed it to make the decimal_precision migration easier
Before this commit, we only sent the list of connected devices to
the odoo instance (thanks to `self.send_alldevices`) when a device
is newly connected. Now, we also send this list when a device is
disconnected. We also try to call this method once if multiple devices
are connected/disconnected during an iteration.
task-id 1939338
closesodoo/odoo#32678
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit: when textarea is on second tab of notebook and it has long
value then autoresize can not compute actual height of the textarea as it is in
second tab and has display: none property, it is not resized until focus comes
on it
After this commit: call DOM_updated event on notebook tab change, DOM_updated
event will call resize method again, so when tab changes resize is called and as
textarea is visible now, proper height is calculated and assigned to textarea.
task-2007558
closesodoo/odoo#34503
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Purpose
=======
We would like to re-use the work entries in the attendance module.
As hr_attendance is not dependant on hr_payroll, we move the whole
mechanism into its own module.
This could be reused too into others modules, like forecasting or whatever.
TaskID: 1904850
closesodoo/odoo#34434
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
These variables aren't used in Odoo and can be easily computed
anyway.
Also deprecate the support of integer values for t-foreach, for the
same reason.
closesodoo/odoo#33981
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
For 3000 lines (3 for 1000 products):
- 35s before this commit
- 22s after this commit
Gain around 30%
closesodoo/odoo#34295
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
In a list/kanban view when applying a default_order on the view, it does not
work with favourite filter
Before this commit,
1) The default_order was not applied to the view when favourite filter is
applied
2) when default_order applied, Click on an element of the list/kanban and
then go back to the list/kanban with the breadcrumbs, default_order has been
changed.
This is because the ```_getOrderedBy ``` returns [] when favourite filter is
applied and it does not have sort value, added check if favourite has orderedBy
and has length then and only then pass orderedBy else pass undefined
After this commit,
1) default_order will be applied to the view
2) default_order will not be changed when going back through breadcrumbs
task-1922576
closesodoo/odoo#34001
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
On Inventory Adjustment lines view, when you set serial number for a
tracked product, its quantity is automatically set on 1.
Task #2025397closesodoo/odoo#34301
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The purpose of this commit is to allow to define lead generations rules based on the website visited.
Task-ID: 1964025
closesodoo/odoo#33391
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
In order to make the overview more understandable, we provide some modifications:
- remove some value when they are zero ("No task found", ...)
- the whole middle column (percentages) is merged inside the hours one
- provide some tooltips
- renaming titles
- ...
To do so and to avoid leaving empty lines or doing complicated template branching, the
above table is split in two different tables, so that we can remove lines independently.
We also added a new category in the overview, concerning timesheets that are related to a cancelled so. This meant tweaking the project_overview plan_prepare_value method, in order to have the new numbers calculated and keep the others consitent.
Task-1968121
closesodoo/odoo#33015
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
If the user tries to save the recurrent event with 0 as the number of
repitations or interval there will be a traceback so instead of traceback
display the warning so user will not be able to save that event.
Task-1930809
closesodoo/odoo#31388
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Having :
- a pricelist with 10% of discount for all the products.
- the discount policy in the pricelist set to : "Show public price &
discount to the customer"
- a product with negative price (ex : -$125)
- add the product in a SO with the 10% pricelist
Before this commit, the unit price was the price with the discount
already applied: -$112.5, and not the original price as expected; The
subtotal price was $101,25 (the discount is applied twice) which is
wrong.
Now, the unit price is -$112.5 as expected, in Odoo surcharge are always
included in the display price.
opw-1986582
closesodoo/odoo#33717
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
oe_view_nocontent_smiling_face does not exists in css
when using this classname, the smiling face does not appear
closesodoo/odoo#33519
Signed-off-by: Christophe Simonis <chs@odoo.com>
When recreating the auto-generated view of user base.user_groups_view (e.g.
with a '-u base'), the view was generated in the language of the admin.
In case the database was in a different language than English, the source arch,
stored in database in arch_db field, was translated.
Instead, the source must be in English and translations must change the content
based on the user's language.
This was introduced at 894143cb4c as the view content was not translated.
At that time, the arch field was not translatable and the xml_translate mode
did not existed yet
Fixesodoo/odoo#33482closesodoo/odoo#33566
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Create a lead without Salesperson assigned
- Edit the lead, set a Salesperson => the Assignation Date is set
- Edit the lead, change the Salesperson
The Assignation Date is reset.
There is no reason to change the Assignation Date in the second case.
Indeed, in many cases the Salesperson is modified for a good reason
(e.g. the first person left the company). From a customer perspective,
that doesn't change anything: he was always in contact with a
salesperson and the lead was handled. Moreover, the reporting becomes
incorrect.
We only change the Assignation Date if no Salesperson was assigned.
opw-2001912
closesodoo/odoo#33640
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a SO for a stockable product
- Validate the SO
- Change the 'Delivery Address'
Nothing warns the user that the address was not changed on the
corresponding pickings.
opw-2002084
closesodoo/odoo#33636
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Usecase to reproduce:
- Install stock, mrp, purchase
- Go on warehouse form view
- Click on Routes button
Either one of the route manufacture or buy is missing.
All implementations/overrides of stock.warehouse._get_all_routes()
call their parent's implementation of get_all_routes_for_wh().
which is a reference to stock.warehouse._get_all_routes() but that means
that the route 'mixin' behavior can be skipped.
(the reference is to the base implementation of _get_all_routes())
Fixes#33286Fixes#33288
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When website_customer is not installed, some endpoints are not handled
by the router, causing the following tests to fail:
- test_10_crawl_public
- test_20_crawl_demo
- test_30_crawl_admin
Those tests were failing due to /customers responding with 404.
Indeed, the route /customers is defined in website_customer, but had
some usage within website_crm_partner_assign, causing tests to fail when
the former module is not installed.
The new behavior can be explained as follows:
- module website_crm_partner_assign on its own will lose the hyperlink.
- module website_customer will now inherit the view definition in order
to wrap the targeted HTML text elements with an anchor tag.
Closes#33344
Signed-off-by: Christophe Simonis <chs@odoo.com>
Purpose: filter product by location of warehouse failed due to the
control panel refactoring (odoo#29106). This commit fix the way the
product quantities are computed when location/warehouse into filter
context.
Task:1941639
Co-Authored-By: Martin Geubelle <mge@odoo.com>
closesodoo/odoo#31316
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Creating a new database with only sale_stock installed will lead the
boot_tests.js test to fail.
That's because commit 033608eb11
introduces an implicit dependency on a sale_management tour. This seems
to be a mistake since sale_stock does not depend on sale_management.
The tour only makes sense if both sale_stock and sale_management are
installed though. That's why the additional steps will be run
conditionally.
After this commit, the extra steps will only be run when sale_management
is installed.
Technically, this is done by checking whether odoo._modules contains
sale_management.
opw-1964469
closes#33275
Signed-off-by: Christophe Simonis <chs@odoo.com>
- specify the correct separators on the language
- add the address format
- add street addres format for croatia
closesodoo/odoo#33205
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
avoid to get journal_entry_ids, to avoid pushing those ids in cache and
having them read uselessly when accessing an account.move.line
recordset.
Use search and search_read instead of ORM __get__
closesodoo/odoo#33192
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Co-authored-by: william-andre <wan@odoo.com>
Commit c7773f9f introduced a duplicated term to the file .pot, which
causes the following error when trying to re-load translations:
```
ON CONFLICT DO UPDATE command cannot affect row a second time
HINT: Ensure that no rows proposed for insertion within the same
command have duplicate constrained values.
```
This commit removes on eof the duplicates, leaving only the valid one.
In addition, field string is modified to match the one defined at the
`website_sale` module, to prevent this from happening again, as had also
in 6af6da5c.
closesodoo/odoo#33223
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Robot Odoo