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 #39016 closes odoo/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. closes odoo/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. closes odoo/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` closes odoo/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.