In v10, a `Float` field with `widget="monetary"` option uses the decimal
precision of the field. In v11, however, it uses the decimal precision
of the currency. However, in many cases `widget="monetary"` is used in
the sole purpose of displaying the currency symbol. The precision of the
field sould be kept.
This commit introduces the support of the decimal precision of the field
for this specific use case thanks to the `field_digits` option:
```
<field name="pouet" widget="monetary" options="{'field_digits': True}" />
```
If such an option is used, the field precision will prevail over the
currency precision.
Related to #21686
opw-800279
Allow to alter the behavior by introducing preparation methods that can be overwritten.
Partial merge of PR #16093, from an original idea and commit of David Arnold (XOE Solutions)
Before this commit, all tooltip users was showing website and parent_name from
the Main company and not the current focsed partner.
This commits closes#18430
@kangol: fwd-port company_name
If you set 200 kamra to allow to flag a post and 300 to edit all post, you was
not able to flag the post before this commit.
This commit closes#21274
@kangol: warning, fwd port need to add tag_ids into trusted_keys
The report 'Leaves by Department' only counts full days-off, instead of
taking into account the actual number of days.
This commit fixes the total number of days per employee. However, there
is still a limitation on the display: a day is either fully colored or
not at all.
opw-801061
Previous to this commit, we try to load as many fields as possible
during module installation, however sometimes some fields are not ready
to be loaded, which is the case for custom monetary fields, thus when
trying to find the current model's currency_id field it would not find
it at all, generating an assertion error.
This commit changes this by completely skipping monetary fields if they
are not ready to be loaded.
OPW 787223
In the module website, the relational field website_id is defined twice,
once for ir_ui_view and a second time for res_config_settings, for the
former we perform an ondelete='cascade', which means that when the
website model is unlinked, the field is unlinked as well.
This is not done for the website_id field in res_config_settings, which
instead defaults to setting the field to NULL, which violates a not-null
constraint and therefore causes issues when trying to modify/save
settings.
To solve this, a hard delete of the ir_model_field website_id is
performed during the uninstall process of the website module.
Fixes#21905
OPW 803018
Before this commit, in the event that the admin user has set the language
to english, but the COA's target company had a different language,
the admin user's language had been taken instead of the copany's one
for the translation of journals and other coa intialization stuff.
This is wrong as the CoA is more connected to the company, than to the
user, which could be a functional support user that just happens to prefer
the english version over the local one.
Now, we ensure in two neuralgic places, that the company's language is passed
to the context and therefore picked up by the translation's GetTextAlias.
Signed-off-by: David Arnold <dar@xoe.solutions>
In many2many lists, the remove record from the widget is a trash bin.
It is confusing, as people feel they are deleting it when they are
only unlinking it.
So in many2many, we propose to change the trash icon by a 'X'.
This icon appears in many2many relations and in many2many widgets:
even though hr.expense.sheet defines the expense lines as a one2many,
it uses a many2many widget, so we use a 'X' instead of the trash bin.
To avoid ambiguity, we decided to rename 'delete' to 'remove'.
Purpose
=======
Currently, only single people are considered as isolated people.
Specification
=============
Widows and divorced people should also be considered as isolated people.
When there are too many labels to display on the x-axis, they overlap
and it simply becomes unreadable. By slightly rotating them, this can be
avoided in most cases.
Back-port of this commit 388e258ce8
opw:802925
The new settings model loads by default all settings. In the case of
non-admin user having the 'Settings' access rights this can lead to
access errors.
This commit deals with the multi-company issues on a standard
installation. If the admin is in Company A and the other user in Company
B, accessing the settings is pretty much impossible because of records
rules.
This fixes the master or demo data to avoid setting a company by
default. Note that it only fixes a standard installation: if the
settings are later customized, there is no guarantee that it will still
work.
Problematic fields:
`auth_signup_template_user_id`
`crm_default_team_id`
`leave_timesheet_task_id`
opw-801210
Previous to this commit, if a user hadn't properly set up his
Authorize.net credentials, when getting a response from Authorize.net's
servers, we would expect some attributes to be in the response's body,
but this is not the case if the credentials are wrong, thus we would
have an unexpected error like "NoneType object has no attribute text"
which is only a sympton of the real error (bad credentials and no
error-checking).
This is fixed by checking if the response body contains an error
message, if it is the case we raise an UserError with the error code and
the error message (which is only shown if debug mode is activated).
OPW 788261
[FIX] web: Fix column_invisible issue
This commit fixes an issue with the column_invisible attribute.
When we choose product variant for BOM for any particular product,
at that time from the BOM Lines column "Apply on Variants" is hidden,
but when we unset product variant from BOM Form,
at that time the column 'Variants" set to visible. but in this case, it is set to hidden always.
PR 21693, OPW 779555
[FIX] web: Fix column_invisible issue
This commit fixes an issue with the column_invisible attribute.
When we choose product variant for BOM for any particular product,
at that time from the BOM Lines column "Apply on Variants" is hidden,
but when we unset product variant from BOM Form,
at that time the column 'Variants" set to visible. but in this case, it is set to hidden always.
PR 21693, OPW 779555
Routes created when creating companie were not set to the correct company.
Steps to reproduce:
- Go to Settings > General settings: Activate Manage Multiple companies.
- Go in Inventory > Configuration>Settings: Click "Manage several Warehouses,
each one composed by several stock location". Click "Advanced routing
of products using rules".
- Go in Settings > Users > Companies: Create new companie "ThisNewCompanie"
- Go in Inventory > Configuration>Routes: Open Routes named ThisNewCompanie.
Bug:
All the routes created automatically by creating the company "ThisNewCompanie" are
not set to the company "ThisNewCompanie". They are set to the company of the logged
user when "ThisNewCompanie" was created
opw:787229
When
- a user A had set 'notifications handled by Odoo'
- a user B sent a @userA message
Before this commit, the user wasn't notified in the inbox needaction
After this commit, he is
OPW 801315
When confirming a quotation for an MTO product, the state of the
delivery order goes from draft to waiting another operation to waiting
while it should stays in waiting another operation.
If procurement_jit is enabled, confirming a sale order line will
unreserve and rereserve the pickings associated (see
`action_launch_procurement_rule` override). Unreserving a picking will
always set its state to "confirmed", which is wrong if it should be in
"waiting another operation". Not writing on state (which is a computed
field) and let the depends call _compute_state fixes the issue.
The unreserve/rereserve thing is probably useless and is a remain of the
previous stock implementation where it was not possible to complete the
reservation of a move without wiping all its current reservation.
Another commit will improve this part of the code.
opw-801588
Nicolas Martinelli