PURPOSE
=======
Simplify the way to activate currencies
SPECIFICATION
=============
On res.company :
Currency_id: options={‘no_open’: True}
oe_edit_only on “Activate more currencies”
In the list view of the currencies, replace the checkbox active by a boolean_toogle widger
There is normally a default filter on the currencies list view to only show the active currencies : this filter should be kept except if you arrive on this screen by clicking on "Activate more currencies" from the res.company and from the settings. Only the menuitem Currencies should only show the active ones
Purpose
=======
Currently, it's not possible to activate a boolean on a non-editable list view without adding 2 buttons linked to a python method. These buttons aren't aligned and the result is not pretty.
This commit adds a new widget that allows to toggle a boolean record by record by clicking on the slider.
Purpose
=======
No way to fully set up a bank account from current form
Must go to journal form to simply apply bank sync, etc. Users cannot figure this out themselves, this is too much complicated
Also the meaning of Manual, Electronic, etc is not clear. What does it do? Field and options to rename or to explain very clearly in tooltip
Specification
=============
- Add some useful fields on the bank accounts form view to configure it completely
- Add tooltips on some selection fields to explain the meaning of each selection
- Reorganize fields in groups to be more structured
- Improve the field display for account journals that are used in pos
There is a bit of magic in the kanban with many2many: the widget many2many_tags
is automatically set on many2many fields.
Since the previous commit, the `color_field` needs to be explicitly stated
in the options for the tags to be colored.
In kanban views where tags were previously colored, we thus have specified the
widget and the color option.
Since the previous commit, the `color_field` needs to be explicitly stated
in the options for the tags to be colored.
The previous behaviour (always read the field `color`) was leading to server
warnings if the field was not present on the comodel.
Thìs commit set the `color_field´ for every many2many_tags on fields that have
a `color` field on the comodel.
Before this fix, the field 'color' was hardcoded in the m2m_tags widget,
which means that:
- one couldn't specify another field (problem for custom models, with x_...)
- if the related model didn't have the field 'color', a warning was raised
by the server
Now, the color attribute needs to be specified on the widget options if one
wants to display colored tags.
If the color is not specified, the tags will be displayed in grey.
Purpose
=======
When a new sales user is created, user is not in any team. The dashboard doesn't make any sense and he wouldn't know how to start working
Specification
=============
On salesman creation, the user should be assign to a Sales channel IF there is only one sales team of this type.
When an invisible x2many field is modified by an onchange, we had a
crash because the reset function did not return a deferred in that case.
This happens because the signature of _render in AbstractField allow for
an undefined return value, but the reset method should return a
deferred.
This was an issue for example in stock: editing the
pack_operation_product_ids one2many field in a stock.picking could
trigger an onchange on another invisible one2many (with no inline views).
There was a lost promise which made website_form loaded before the
languages informations (such as date format) was loaded.
The server expect the format of the client thus that could lead to wrong
or invalid dates.
opw-749544
closes#18074
We make the breadcrumbs of the portal uniform and remove them when we
access the document with an access token without being logged in
(for sales orders).
* allow new signup on invalid token
* relabel signup buttons
* send a welcome email upon signup with a signup token.
This way, should the token somehow be usurped by someone else,
the original partner's email address will be notified.
(before the usurper can change the email)
Mail now can handles a generic access_token in /mail/view route. Mail does
not do anything with it. Addons can override the controller and add their
specific management of this token according to some specific business
logic.
Sale order emails now contains the access token to grant access from the
notification email url without logging in. Sale portal now allow customers
to log in using an access token without having to use Online Quote. If
the user doesn't have an account yet and signup is allowed (B2C) an extra
parameter is added to the url to link the correct partner to the user upon
signup. If the user already has an account an extra parameter is added to
auto-fill the user's login if he wants to login from that session.
Account is also updated to prepare accepting access tokens. However the
complete implementation of accounting customer portal will be done in
another task coming soon.
In order to be able to identify what action to return based on the
access_user.
Typically portal users will need to be redirected to the front-end,
while internal users will need to be redirected to the back-end.
When you receive an url with parameters
* auth_signup_token: uuid
* auth_login: login
those will be stored in the session and used
* when the user will want to sign up in order to be linked to the right
partner;
* when he logs in so he's sure to log in with the right account +
autofill is nice
This commit only adds the support, future commits will support its use.
Since 5425316eff errors when signing up will only display two
messages:
* "Another user is already registered using this email address." or
* "Could not create a new account."
While Odoo creates a multitude of other comprehensible error messages
such as
* "Passwords do not match; please retype them."
* "Signup token '%s' is no longer valid"
This commit now separate UserError and AssertionError from SignupErrors.
Those are still hidden in a general message (see 5425316eff for reasons) while
the other ones are fully displayed.
This commit also improves translations of messages.
This commit duplicates the General settings' User Signup options in
the Website configuration, with a clear description of the options.
We also remove the unnecessary usage of safe_eval in auth_signup's
res_config.py. As stored values are repr values of a boolean field
just comparing the string values is sufficient. There is no need to
use safe_eval as it should be used only when necessary.
In some situations, it would be desirable to be able to attempt a drag
and drop, without actually triggering the dropping action. As an
example, we would like to see whether dragging a new field in studio
ensures that a class 'o_web_studio_nearest_hook' be assigned. This can
only be tested *before* the new field is dropped.
This commit adds an optional argument 'disableDrop' to the
dragAndDrop method, and sets it by default to false. The dropping action
will then only be triggered if the aforementioned parameter is set to
false.
It is for example useful in the form builder with date-kind form field,
the translation of momentjs is done in french.
opw-707986
opw-749544
closes#17103
The wizard to change the produced quantity of a manufacturing order was not
using the current produced quantity as the default value.
This was because the field mo_id was not present in the view (and not in
`fields` in default_get).
Adding the field as invisible to compute the default value for mo_id.
Correct typo in dictory lookup (using `[` instead of `(`)
Closes#17937
opw-749725
Before this revision, if the user did not re-order
the sequence of its attribute values manually,
the attributes in the variant name were ordered
randomly.
e.g. On the ipod, one time it could be the color before
the GB, one time the other way around.
Besides, this could lead to an issue in the pivot table,
as mentioned in the revision
834b38a84d.
However, on the contrary on what is done in the above revision,
these attributes must not be ordered on their value name,
but rather on their sequence, and if they have the same,
on their attribute, so the order is always deterministic.
Steps to reproduce the bug:
-Create a product tracked by LN
-Create an inventory adjustment to add 10 products with LN A
-Validate it
-Then go in inventory > inventory control > lots/serial numbers > open LN A
-Change the product
Bug:
The LN A tells you you have 10 products X
While in your inventory you see you have 10 products Y
opw:750735
This commit improves the use of activities through various applications
by adding a counter of activities displaying next activities grouped by
application. For each application activities are divided into late, today
and future activities in order to achieve a better management.
This commit also merges Inbox and Messaging icons in topbar to keep only
one displaying All / Chat / Channels messages.
Ankit Sathvara