Since e9734f4975 assignation is now a notification sent in the
inbox or by email to the newly-assigned responsible. It is therefore
considered as not necessary to link a subtype to the assignation itself.
Indeed having it logged in the discussion history as a classic tracking
in addition to the notification is considered as sufficient.
In project module the task opened subtype was linked to task creation and
task assignation. This subtype is now used only for task creation. It also
fixes a strange behavior. Changing assigned user in an ongoing task was
trigerring the task opened subtype which was strange. This is not the case
anymore.
This commit is related to task ID 60790. Closes#23244 .
For objects inherting from rating.mixin, when their parent model change
(e.i.: task from a project to another), the "Parent document name" does
not change. The rating is still considered belonging to the old parent
object (rating stat of project is not correct).
Change the rating API. In rating mixin, instead of having 2 methods
returning parent id and parent model (rating_get_parent_id and
rating_get_parent_model_name), we should have one method returning the
'parent relation field' (inevitably m2o field). Then we can deduce its
parent_res_id/parent_res_model, and check this parent field is in values
of write to trigger the recompute of parent_res_name.
Also, add "ondelete=cascade" on parent_res_model_id
Impacted modules: project, rating, helpdesk, livechat
This commit improves subtask mecanism, on several points:
1) Drop the project constraint: before this commit, creating
subtask in non parent project was not possible. Now you can move
subtask to any project.
The default project of a subtask is the one from the parent.
2) When setting a parent task, we want to force some field to have
the same value as its parent, like `partner_id` or the `sale_line_id`.
The idea is here, we work for the same client; a subtask count for the
same goal (SO line or customer). Those fields should be readonly on the
view.
3) Refactor some methods
Task: 38498
Followers can now be partners or channels. Partners following a document
will receive needaction, as previously. However people can follow documents
through channels. Members of a channel are able to listen to a stream
of messages using the channel. Those messages do not create needaction
messages. It is therefore possible to follow documents without receiving
too much notifications. For interesting documents subscribing with its
partner will create notification.
message_follower_ids fields is udpated. It is now a many2many to
mail.followers, not to res.partner anymore. A subscription can be either
a partner (partner_id) or a channel (channel_id).
Some access rules have been updated accordingly.
code in resource and project.
This library was once used to perfom resource allocation: scheduling
tasks and things like that. However this feature cannot be accessed
through the interface since a long time.
The feature is now removed from the project code. The library has been
removed. Some code in resource used only in the project code
has also been removed, as well as a test linked to this code.
Some tests (e.g. mail) have expensive and significant DB setup for a
number of small and cheap tests. Using a TransactionCase, the DB setup
far dominates the tests themselves, by up to 10x (mail unit tests take
~130s on my machine, the tests themselves take ~15s).
The SavepointCase introduced here is an hybrid of SingleTransactionCase
and TransactionCase: it uses a single transaction for all tests in a
class, but each test case is isolated by a rollbacked savepoint. This
allows a common DB setup (via setUpClass) while keeping independent
tests.
TransactionCase should remain the primary test case superclass, but
SavepointCase can be a fair optimisation when setup costs far dominate.
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
- remove unnecessary copy() method from project/res_partner.py
- remove old methods on project.project
- progress is not used anymore on project.project
- use clickable statusbar for project states
- remove _resolve_project_id_from_context
- rename project.category becomes project.tag to be more explicit
- remove old methods on tasks
- issues: remove option fetchmail_issue
Tests have been migrated to the new api to prepare the migration of the
mail module itself. Moreover tests have been cleaned: redundant tests
and unnecessary tests have been removed.
As the base test class in mail is used in other addons, other addons
have been updated :
- portal
- project
- portal_project
- website_project_issue
- sale
- purchase
Future commits will come with somes fixes for issues detected when cleaning
the tests.
_track is now a method that returns the subtype to trigger in a given
tracking context. A tracking will now lead to only one subtype
being trigerred, instead of having multiple possible subtypes.
Now, one tracking leads to one message with one subtype, or without subtype
if there is none matching. This simplifies the model for future evolution of
chatter and mail.
[IMP] project, project_issue: cleaned task and issue subtypes, now having
opened for created / assigned.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
Thibault Delavallée