if product have taxes and taxes_id field is empty
then it will fill the 'taxes_id', so price_total field
have taxed Total.
Task- 2093205
closes- #41681
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
purpose of this commit is when we import po with po lines
system expects from user to import all those requried fields manually.
Using sale's hack 'prepare_add_missing_fields' fix this issue.
Now we can import po lines in purchase too.
Task- 2093205
closes- #41681
Before this commit, there was a discrepancy between
many2many_tags widget and regular many2many list
That is, in tag mode, when someone had read access alone on the comodel
he could modify the members of the m2m relation on the current model
Which couldn't be done in m2m list
After this commit, it is possible in a m2m list to add
records to a relation, even if we don't have CRUD access on the comodel
Task 44074
closesodoo/odoo#40194
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Because the tax closing entry is created (empty) at the creation of the
CoA, it is not possible anymore to change it later, even if the user
didn't create any journal entry.
By checking that there are no account.move.line instead of account.move,
and also there are no entries with a name different from '/' (to ensure
that the sequences are untouched) we can change the CoA if needed.
closesodoo/odoo#44659
X-original-commit: 8928dfe70867da3e40fa47f50bffa5dfd1976090
Signed-off-by: wan <william-andre@users.noreply.github.com>
Since commit 92737f2 (finetuning of 7b49f58) field website_id, website_tag_ids
are missing from form view of res partner.
Now we use a more precise xpath, hardcoding the group name into the xpath to
be sure that fields are correctly added below the company_id field from a
visible tab.
closesodoo/odoo#44644
X-original-commit: f830bf49013201aadd3feb113596d1534f800fd8
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Task 2093179
Today, there is nothing that reminds a salesperson that an invoice
becomes overdue.
I propose that activities get created automatically on an invoice based
on the ‘due date’ of the journal items as soon as an invoice gets
validated.
This would greatly help the collection effort and be proactive rather
than reactive.
closesodoo/odoo#44129
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this fix, an empty sale order produced a traceback when the invoice was created.
closesodoo/odoo#42750
Taskid: 1997415
Related: odoo/enterprise#7540
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
*: theme_bootswatch
Previously, theme customization was done through a modal dialog in the
website module, this was not very user friendly since the rest of the
customization for the website design was done from edit mode, meaning
the user had to exit edit mode to customize things such as theme colors
or fonts. It was also rather confusing to have these seemingly related
things in completely unrelated places.
This commit moves all of the options that used to be in the theme
customization modal into a new tab in the editor's left panel.
Instead of having an entirely dedicated system for theme options,
those theme options are now simple snippet options.
See the customizeWebsite generic method.
This allows to make any option available in the third tab or on any
meaningful element like the header or the footer. This also allows to
take advantage of all the features of the left panel: dependencies,
visibility update, etc.
Note: same as before, those changes do apply the color/size/layout
immediately on the website, even if not saved. Changing that behavior
is complex and might be the job of another task.
See sub-commits for details
task-2088298
closesodoo/odoo#41166
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* web_editor, theme_bootswatch
Instead of having an entirely dedicated system for theme options in a
third tab of the left panel, those theme options are now simple snippet
options. See the customizeWebsite generic method.
This allows to make any option available in the third tab or on any
meaningful element like the header or the footer. This also allows to
take advantage of all the features of the left panel: dependencies,
visibility update, etc.
Note: same as before, those changes do apply the color/size/layout
immediately on the website, even if not saved. Changing that behavior
is complex and might be the job of another task.
Part of https://github.com/odoo/odoo/pull/41166
task-2088298
Previously, theme customization was done through a modal dialog in the
website module, this was not very user friendly since the rest of the
customization for the website design was done from edit mode, meaning
the user had to exit edit mode to customize things such as theme colors
or fonts. It was also rather confusing to have these seemingly related
things in completely unrelated places.
This commit moves all of the options that used to be in the theme
customization modal into a new tab in the editor's left panel.
This commit is mainly just about rendering the old modal as a third left
panel content. See next commit for deeper changes.
Note: same as before, those changes do apply the color/size/layout
immediately on the website, even if not saved. Changing that behavior
is complex and might be the job of another task.
Part of https://github.com/odoo/odoo/pull/41166
task-2088298
A negative value, even if legit, was not understood by the editor and
induced empty inputs in the left panel.
closesodoo/odoo#44683
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
1/ timer: New mixin to record time on models
Purpose
The timer mechanism is already existing on timesheet.
We would like to introduce it on helpdesk.ticket too, and
probably on other models afterward.
On the other hand, only one timer can be launched on a single
timesheet currently, shared amongst the different users.
This commit introduced a new mixin on which
- Each user can launch a timer on each record of the models
inheriting the mixin.
- Launching a new timer on a record pauses the timer of the
user that could be already running.
- The mixin brings methods to start/stop/pause/resume the
timer, that could be overridden to implement a specific
behavior for the related model, for example create a
timesheet entry.
2/ test_timer: Add test module for the timer mixin
Purpose
As testing the mixin requires to create a new model,
we prefered to create another module.
3/ hr_timesheet: Adapt timer with new timer mixin
Purpose
Now that we have a new timer mixin that offers more possibilities
than what was currently implemented, we can reuse it in the timesheet
management module.
4/ timesheet_grid: Adapt timer buttons to new mixin
Purpose
The timesheets now uses an improved version of the timer,
using a new mixin.
Adapt the code accordingly.
5/ helpdesk_timesheet: Use timer mixin on helpdesk tickets
Purpose
Now that we have a new timer mixin that offers more possibilities
than what was currently implemented, we can reuse it in the helpdesk
management module.
closesodoo/odoo#43778
Taskid: 2149450
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
*: web_editor, website_crm, website_form_project,
website_hr_recruitment, website_sale
The form builder is now using the left panel option system. Many new
options are introduced to build better forms more quickly.
The tests are now running with the new website_form implementation.
Part of: https://github.com/odoo/odoo/pull/42189
task-2092425
closesodoo/odoo#42189
Related: odoo/enterprise#7365
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- add a filter "production locations" on stock location
- add an action returning the production stock locations
- display a link to this action in the product category views in stock
account so users can easily set the correct accounts on these
locations
- set valuation journal an account before the others in the product
category form
Task-2161057
closesodoo/odoo#43762
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose
=======
Now that we have a new timer mixin that offers more possibilities
than what was currently implemented, we can reuse it in the timesheet
management module.
TaskID: 2149450
Purpose
=======
The timer mechanism is already existing on timesheet.
We would like to introduce it on helpdesk.ticket too, and
probably on other models afterward.
On the other hand, only one timer can be launched on a single
timesheet currently, shared amongst the different users.
This commit introduced a new mixin on which
- Each user can launch a timer on each record of the models
inheriting the mixin.
- Launching a new timer on a record pauses the timer of the
user that could be already running.
- The mixin brings methods to start/stop/pause/resume the
timer, that could be overridden to implement a specific
behavior for the related model, for example create a
timesheet entry.
TaskID: 2149450
Purpose
======
Our current integration between FSM and Stock works well for basic flows, but quickly shows limitations. We don't handle warehouse by employee. Use-case: each worker has a dedicated van with a dedicated stock. I want to track the material used for each intervention to make sure that nothing is stolen.
+ This is also useful in usecases outside of FSM. Example: I have 3 shops (= 3 warehouses), each employee works in a different shop, the default warehouse set on the Sales Order should be the default warehouse of the salesperson. So this should be done sale_stock (and not in FSM)
Specifications
===========
Add a 'Default Warehouse' field on the user only visible if :
- sale_stock is installed
- the 'multi-warehouses' feature is enabled
- domain should only include warehouses which belong to a company the user has access to
- not required
The field should be editable by a user on his own profile and by the admin on all users.
When creating a FSM task from scratch, adding some products creates a SO, the warehouse on the SO should be the default warehouse of the user set on the FSM task.
On SO creation, set the 'default warehouse' selected on the user assigned to the SO. If there isn't any 'default warehouse' set on the user, fallback on the current behavior (warehouse with
lowest sequence)
The field on the res.user should be a property field to allow multicompany usage.
Task : 2166382
closesodoo/odoo#44257
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently when creating an SO without any products and creating
down payment for that creates a traceback.
so Fix traceback when creating an invoice for sale order with an empty
product. when there is no orderline then do not get the sequence in down
payment line to make down payment line at last in sales order.
Task-2181464
closes odoo/odoo#44645
Closes: #44491
X-original-commit: 5e3e127187130a3d6dac98920564598a05d9c627
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce the bug:
- Give 'Administrator' rights for the Sales app and no rights for the Point of Sales app to the demo user
- Try to access CRM > Sales > Team Pipelines as Marc Demo
Bug:
Access Rights error on pos.session
opw:2184032
closesodoo/odoo#44637
X-original-commit: 77f0d6280e64074a3188dfb85d688ab758400128
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Task 2146469
Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool
This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.
The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.
The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.
** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002
closesodoo/odoo#41485
Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
*: web
Before this commit, when a widget declared assets to lazy load through
the assetLibs key, the asset was loaded through a context-less call to
the server through the base `rpc` function. This caused problems in
website: the website ID was not given to the called route and the loaded
assets were then stripped of their specific-website parts.
This commit solves the problem by allowing the `loadLibs` and
`loadAsset` functions to receive an extra argument: an extra `context`
to use for the actual call to the server. The method is now available
in the ajax service, so that website can add its custom context
automatically, the same way it does it for normal `_rpc` calls.
Part of https://github.com/odoo/odoo/pull/44596closesodoo/odoo#44596
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: partner_autocomplete
Those cannot be properly lazy loaded by test widgets, so they are loaded
directly through test assets. Testing lazy loading should be part of
a dedicated test system.
Part of https://github.com/odoo/odoo/pull/44596
We had a default warehouse_id on the users to allow
a better stock managment based on the sale person.
The warehouse_id on a sales order is now computed from
the property_warehouse_id field on a user.
If the user doesn't have a property_warehouse_id set
the warehouse_id on the sales order is the one with the
smallest sequence number in the company of the SO.
Task-2166382
It very rarely happens that the test is failing due to the following error:
`Tour shop_list_view_b2c failed at step
.oe_product_cart .oe_currency_value:contains("825.00")`
The value found in that case is 750 instead of 825, which indicates that the b2c
setting was not correctly activated.
To exclude the RPC themselves from the equation, it is decided here to move the
setting change directly in the Python.
closesodoo/odoo#44599
X-original-commit: 735807cefb7ccf3232f7492b825ce8c42bacbed4
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
@Julien00859 already made a pass on this at some point but there's a bunch of warnings either dynamic or from not the stdlib left over.
Some of them can't really be fixed in-code and have been explicitly ignored instead:
* `setuptools` uses the deprecated `imp` module until v41.6.0
* `zeep` uses defusedxml.lxml which was never intended to be a public / production API, not sure what to do there (cf mvantellingen/python-zeep#956)
* there are a ton of invalid escapes in non-raw string literals, they're unlikely to ever be relevant so ignore them
closesodoo/odoo#44164
Related: odoo/enterprise#8130
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Replace an assertRaises(StopIteration) by a next() with a default
value.
Following PEP 479, *any* StopIteration reaching the toplevel of a
generator triggers a DeprecationWarning. And while the assertRaises
looks innocuous, both _assertRaises and the underlying
clear_upon_failure are implemented with functools.contextmanager,
which wraps a generator.
As a result, exceptions raised in the assertRaises "body" get
reinjected inside the wrapped context manager[0] and if the exception
is a StopIteration it triggers the warning.
By not using assertRaises we side-step the issue.
[0] https://github.com/python/cpython/blob/b6999e5690c7006b0ba4049cfd638513c982a90c/Lib/contextlib.py#L131
In 0.15 accessing werkzeug.urls functions directly through werkzeug
is deprecated, the shortcut will be removed in the eventual werkzeug
1.0.
Fix existing uses of these shortcuts. Also cleanup some imports when
they're not far from a werkzeug* import being altered.
assertDictContainsSubset has been deprecated since 3.2 and is not
documented anymore, apparently because the order of its parameters is
less than obvious.
Consequently, remove the call to said dict & replace it with
assertions on item sets.
Note: the odd formatting is because these bits are literal-include-ed
in the documentation as sub-slices (just the relevant code lines), so
ideally they shouldn't be moved around and no additional content
should be added to those specific lines.
nje-odoo