Before this commit, each picking type had its `show_operation` field on
true if user actived multi locations, packaging or tracking.
Now, it still the case except for picking type for receipt.
Also, modifies onchange to reflect that when creating new picking type.
Task #2031313
Those 2 methods are used in enterprise (for now) in order to get employee
unavailabilities. This is used for planning and forecast gantt view. As we
didn't want to create a bridge module for those 2 methods, we place them
here as 'hr' is the only one common dependency between forecast and planning.
Task-2024216
closesodoo/odoo#34638
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
For now the sales team is only used on the pos.config and now on the invoices generated.
When you open the sale report, you'll see the sales team of the pos.order, but in reality it is the one of the related pos config.
That means that if you change the pos team on a config. It will change the pos team of all existing order.
We should store sales team on pos order, like on invoice and sale order
TASK-ID: 2011460
closesodoo/odoo#34246
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
reply_to field is not used (and not available) anywhere. Its use is completely replaced by
aliases you can set on teams. Let us therefore remove this field.
Related to task 1985539
Closes#33497
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to remove of the legend_priority field in the crm
and project addons since they are not used anywhere.
Those were initially introduced at dd343c8633 . Purpose was to be able
to customize displayed label of priority field used in kanban view in
replacement of standard string. However kanban view does not support it
anymore since whatever web refactoring and this feature will not be
reintroduced. Let us therefore remove the fields.
Linked to task ID 1935620
closesodoo/odoo#33444
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
1/ base: use new avatar for administrator
As the current icon is white, we cannot see anything when
put on a white background, as this is the case on the chatter.
2/ mail: Remove the 'Bell' icon to edit subtypes
There are 2 different manners to edit the subtypes:
- The bell above the chatter
- The pencil next to your avatar on the followers dropdown.
It's better to have only one way to edit these subtypes.
As this is an advanced configuration that is not part of the
onboarding process, remove the most obvious way to edit it.
3/ mail: Move the attachment icon on the left
This is much better.
4/ mail: Display some tour popups on a better side
5/ mail: do not log note if note is empty
Because a note could be only False, not at least
"<p></br></p>"
TaskID: 2026295
closesodoo/odoo#34615
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
There are 2 different manners to edit the subtypes:
- The bell above the chatter
- The pencil next to your avatar on the followers dropdown.
It's better to have only one way to edit these subtypes.
As this is an advanced configuration that is not part of the
onboarding process, remove the most obvious way to edit it.
`api.one` has been deprecated since v9 because it often makes the code
less clear and behaves in ways developers and readers may not expect
since functions decorated with it usually expect a `list` of record(s)
instead of the recordset, whereas most modern Odoo code expects `self`
to be a recordset.
The function `aggregate` was solely being used by `api.one` thus it has
also been removed since there doesn't seem to be any other use for it
thus far.
closesodoo/odoo#34555
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Impacted modules: project, sale, sale_timesheet and project_timesheet_holidays.
Since a5b6f31cf2, the multi company environment is contextualized,
allowing people to see several company documents at the same time. This reveals
some problem in such env.
To solve this, we need to force the "company_id" field as required on some business
model, and to correctly propagate the company when a document generate another one.
The guidelines is to stop using company of current user, but the one of the document
itself.
See subcommits for more details.
Task-1999686
closesodoo/odoo#33739
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
In a multi company environment, some adjustment must be done:
- the company of an internal project of a company should be in that company
- the generate timesheet on holidays validation must be in the company the
task (or internal project)
The company should be correctly propagate to timesheets.
Task-1999686
When allowing timesheet on a project, the project generate
an analytic account if not given. When creating that account,
the company should be the one of the project (origin document)
rather than the one of the current user.
Task-1999686
On Sales order confirmation, a project can be create. The project
company is not correctly propagated: the created project should
be in the same company as the SO.
To stay consistent, during the sold quantity conversion into the
planned hours of a task, we need to use the SO company instead of
the one of current user.
Task-1999686
As task can be billed, it became a important business model. To avoid mistakes in a multi company
environment, we need to make the company_id field required. Indeed shared task can be problematic
with access rights when a employee will log timesheet from another company in a task that is not in
the same company as its project.
To populate this field, we recommend to take the company of task's project, or to fallback on
the company of the user that created one.
Task-1999686
The sales order is a important model. Since it generates invoices and other business
documents, the company_id field should be required as the company must be propagate
to generated documents.
Moreover, a sales order without a company raises a error, and we need a company to
compute the multi currency rate.
This commit fixes that bug, by setting the company_id field required on sales order
and sale order line.
Note: we only simplify the ir.rule of sale.order, and not the one of
sale.order.line. Indeed, when creating an SOL, the creation is done
in 2 times by the ORM: first insert, then UPDATE with computed stored
fields. As company_id of SOL is a stored related, the check access rules
raises during the inconsistent state (between INSERT and UPDATE,
company_id is False).
Maybe this will be clean after the big refactoring of the ORM.
Task-1999686
The following trick used to work, because `sudo()` was actually making
an environment for the superuser to operate upon:
request.env[...].sudo().method(...)
It no longer works in general, since `sudo()` now makes an environment
in superuser mode but with `uid=None`! It may still work by accident
for operations that never use `env.uid`, but is broken in general.
Using `auth='public'` fixes the problem by using the public user when no
user is available.
closesodoo/odoo#34297
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Before the fix, it was possible to validate a bank statement of a POS without validating the entire POS session.
After the fix it's impossible to validate the bank statement of an opened POS session. We now have an error message if we try to do it from accounting app and can't see the validate button anymore from the POS app.
TASK-ID: 2001551
closesodoo/odoo#33986
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Steps to reproduce:
Open a POS session and add an order with a few items on it, but
don't submit a payment for that order.
Exit, close and validate/post the POS session
Open another POS session
Current behavior:
The unpaid order vanished into Never Never Land, never to be
found again.
Expected behavior:
Either an error should be displayed when trying to close a
session with outstanding orders, or any open orders should
be automatically moved to the next open session. If I had
the choice, I would much prefer the second option, plus a
warning message when closing the session.
Closes https://github.com/odoo/odoo/issues/16151
TAK-ID: 1918354
closesodoo/odoo#33395
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Since changes made on decimal precision access rights in rev: a1eb000c93
the pos user doesn't have access anymore to decimal precision model in
read access.
So we've added the read right on this model for the pos user.
This commit introduces a small helper to return
a timedelta given a quantity and a time unit (day, hour,
month, ...)
Task-2024216
closesodoo/odoo#34576
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
In some module, we gonna need to display time part in name_get. So,
it is interesting to have a helper doing that for us. Time part label
depends on the language, format, and timezone.
This commit introduces this tool, based on `babel` lib like the
other helpers. Tests are provided.
Task-2024216
In fiscal position, fields from 'ZIP range' were not supporting the ZIP range with 'char' field and only support 'integer'. It was a problem in some countries like Canada.
task 1948120
closesodoo/odoo#31910
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Also make a base performance class for some context and users in order
to lessen a big file size.
closesodoo/odoo#34547
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this task, when a customer bought a course, he was directly
redirect to the checkout process.
After this task, the customer can either Add to Cart or Buy Now
(if the Buy Now option is activated)
This commit also updated the redirection regex in website_sale_product_
configurator. When a product has an optional product, you have the possibility
to add in your cart the optional product thanks to a modal. Before, the button
"Add to Cart" was only available in the shop (/shop/), but now it is also
available on a course (/slides/). So to be redirected on the cart when we
click on the button "Proceed to Checkout" for a course, we needed to apply the
redirection also for the course.
Linked to task 1974929
Related to PR #34224
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Now we can have eCommerce and eLearning without automatically willing to
sell courses. The auto_install in the manifest was also blocking the
possibility to uninstall the module. When we tried to uncheck the option for
selling course, it reinstalled it just after we had saved the change in the
settings.
Linked to task 1974929
Related to PR #34224
Before this commit when you set a partner image whose height was greater
than it's width, it used to get squeezed into a square. After this commit
we prevented partner image from being squeezed into a square.
Task ID: #1982082closesodoo/odoo#33134
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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
Simon Lejeune