Add the currency symbol for the monetary tracking field to better
represent the change of a monetary field.
The currency will be fetch from the currency defined in the
monetary field or on the record's company in case there is not.
For example, if we have a record with a monetary field displaying
"$ 500". If we modify the currency and the value to have "450 €",
the message containing the tracking values will display:
"500 € -> 450 €".
We only use one field to track the currency of a monetary field.
Indeed, in the case where the currency is changed with the value
of a monetary field, only the new currency is tracked. We focus
on the fact that the more important thing is the new value.
Furthermore, when modifying a currency of a monetary field, the
user can already see the new currency before saving the changes.
This allows him to adapt the value of the field if he needs it.
(N.B. we assume that this case will happen very rarely)
Using only one field takes also into account that there are
millions of record for this model and adding a new field would
take a lot of memory.
odoo/odoo#61999odoo/upgrade#2060
task-2387268
Note : Manual forward port recovering from commit ae1e70eba10112170283cfc17fa95d94dd948d2b
Purpose
=======
Let's say that the field 'foo' is tracked and defined with a res.group.
When the field is modified, a mail.tracking.value is generated, but the
reference to the field name is a char field.
When displaying the mail.tracking.values on the chatter, a check is done
according to the field group to decide whether we should display it or not
to the user. See: c7aa8c5#diff-ad8b6db158187579d2208f233d993c3cR43
So if I rename the field, and if the mail.tracking.value is not modified,
the mail.tracking.value magically appears to the users who shouldn't
access it before.
Note: If the migration is correctly handled, this shouldn't be the case.
But manual manipulations on the database could lead to this issue.
Specification
=============
If the field referenced by the mail_tracking_value doesn't seem to exist,
then display its value to system users only, by security.
closes#39016closesodoo/odoo#52348
Taskid: 2088634
X-original-commit: 19bc081e4a71042c3f009e4af641da18fc16bdfe
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The tracked field is now a relation to the corresponding ir.model.field.
This prevents potential privacy issues should the field be deleted or renamed.
closesodoo/odoo#39232
Taskid: 2088634
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Let's say that the field 'foo' is tracked and defined with a res.group.
When the field is modified, a mail.tracking.value is generated, but the
reference to the field name is a char field.
When displaying the mail.tracking.values on the chatter, a check is done
according to the field group to decide whether we should display it or not
to the user. See: odoo/odoo@c7aa8c5#diff-ad8b6db158187579d2208f233d993c3cR43
So if I rename the field, and if the mail.tracking.value is not modified,
the mail.tracking.value magically appears to the users who shouldn't
access it before.
Note: If the migration is correctly handled, this shouldn't be the case.
But manual manipulations on the database could lead to this issue.
Specification
=============
If the field referenced by the mail_tracking_value doesn't seem to exist,
then display its value to system users only, by security.
closesodoo/odoo#39033
Taskid: 2088634
X-original-commit: ae1e70eba10112170283cfc17fa95d94dd948d2b
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
This commit renames the `groups` field into
`field_groups`.
The previous name was impossible to grep as
the word `groups` is everywhere in the code base.
Also the new name better follows the implicit convention
that fields related to the tracked field all start
with `field_`.
Purpose
=======
mail.tracking.values should be deleted when the corresponding
field is deleted (when the module which defined it is uninstalled).
Firstly because we don't want useless data in db.
Secondly because the groups associated with the field can no longer
be checked if it was deleted. As we don't know to whom the value
was restricted, the value should not be displayed anyway.
Note: this case was fixed in saas-12.2 by b9e96b7 but the proper
way to fix it is to delete the tracking values.
Specification
=============
Delete `mail.tracking.value` when the associated
`ir.model.fields` is deleted.
Two alternatives were considered:
1. Change the `field` field of `mail.tracking.value` from Char
to a m2o to `ir.model.fields` which allows to use delete
oncascade. This implies to modify existing code, but more
importantly it adds database queries.
2. Override the unlink method of `ir.model.fields` to
first unlink associated tracking values.
The first method is probably cleaner but the second method
was nonetheless chosen as we don't want to impact
performance in the main tracking flow only to better
support module uninstalls which happens rarely.
Note: when a module is uninstalled, `ir.model.fields`
are unlinked one by one (in a for loop). Tracking values are
therefore also unlinked field by field. Batchifying field
deletion would greatly reduce the amount of queries.
Steps to reproduce:
1. install `hr_contract_salary`
2. create a contract
3. set or update `hr_responsible_id` on the contract
(it creates a `mail.tracking.value`)
4. uninstall `hr_contract_salary`
5. go to the contract form view
=> traceback `hr_responsible_id` does not exist
Before displaying a `mail.tracking.value`, `groups` of the
fields are checked to fitler tracking values according to access
rights of the user.
However if the module that added the field has been uninstalled,
the field does not exists anymore.
Fix:
check if field exists before getting fields groups.
If the field does not exists: set groups to `base.group_system`
closesodoo/odoo#31398
Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>
Purpose
=======
Currently fields with a `groups` attribute can't be tracked.
Otherwise changes would be visible by all in the chatter, including
users which normally don't have the access rights because they are
not members of `groups`.
Specification
=============
Filter tracking field values according to the `groups` attributes.
Users without the access rights should not see them.
If a message is only composed of tracking values and the user doesn't
have the rights to see them, an empty message should not be displayed.
Track_visibility field parameter allows to track field changes in mail. Since
commit https://github.com/odoo/odoo/commit/c99de4551583e801ecc6669ac456c4f7e2eef1da only updated values are tracked. Previously to that commit it
was possible to have field values being tracked whenever any other change
occurred. This feature has been removed to simplify tracking and avoid having
unnecessary values in the tracking table. In this commit we rename the
track_visibility parameter to tracking. Old parameter value is still supported
in mail for backward compatibility.
Commit https://github.com/odoo/odoo/commit/ec35eca7c6b772139c8fa143b388ad1d936bc9ea added sequence on tracking so that display of tracking values
is coherent through various chatter messages. To ease tracking configuration
it is merged with the tracking (old track_visibility) parameter. It means
tracking parameter can either be True (default sequence of 100) or an integer
giving the sequence to apply on the tracking.
Purpose of those changes is to simplify tracking configuration with studio
in mind. That way changing one parameter allow to customize the tracking of
fields in chatter.
Sequence field on mail.tracking.value model is renamed to tracking_sequence to
have a coherent namespace for tracking information. Tracking information on
ir.model.fields is also updated accordingly. To simplify manipulation boolean
value for tracking is automatically transformed into a sequence of 100.
This commit is linked to task ID 1903814 and PR #28430.
Suppose user A creates a sale order S in company X. He then changes to company Y
Sales manager B, in company X, creates the invoice for sale order S.
Bug: the compilation of the report fails because of the user.name in the
template. Then the tracking update fails, making it impossible to validate the
invoice.
opw 1884915
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
Fields in the chatter can be organized with a business logic.
Here fields for CRM and Website E-commerce have a tracking sequence.
For other fields/module just add "track_sequence=x" on model
Add the TZ to the datetime tracking. At the moment, the TZ is fixed: it
is UTC. However, this avoids any ambiguity when the tracking message is
sent by mail, since in this case, the datetime is not converted
automatically to the TZ of the user.
Adding a simple 'Z' makes the datetime compliant with ISO 8601, so it is
supported by the web client as well.
opw-747367
When changing tracking mecanism in v9 'always' tracked fields lost their meaning.
They were managed like 'onchange' fields. This commit sets the old behavior back.
* 'onchange' fields are displayed in tracking every time they change
* 'always' fields are displayed in tracking every time they change or whenever
other tracking exist; those are used to display some contextual
information
This commit introduces a new view type, the timeline view. This view is
intended to display messages like the previous chatter. This is now a view
like the form or list view. Like other views it will be possible to have
custom templates for some specific needs, allowing customization.
[IMP] mail: the value tracking is modified. Previously messages were created
containing the modified values. Those values are now stored, using a new
model mail.tracking.value. The message body is dynamically build based on
the values. Tests have been updated.
This version is temporary. Indeed two main modifications will come in a short
future :
- the new design will improve the display
- the slack mode will change the way the Inbox and notifications are managed
All glory to the Hypnotoad.
Special thanks to Valerie Pirenne (vpi), Jerome Maes (jem) and Richat Mathot
(rim) that did not code but said a lot of things. Martin Trigaux (mat) did
nothing, a bit like for the slides modules, but he is busy sending emails.
Jérémy Hennecart