Community
Participate
Working Groups
There are scenarios where changes that take place on a task may be of little interest to the user yet result in awareness queues (incoming arrows and highlighting in the editor, notification popups). Examples of such cases could include: * when the CC list on a bug changes * notification of changes made by myself * some custom fields It would be great to have a facility in Mylyn where the user could denote which fields to disregard.
It could be difficult to come up with a static set of deltas to ignore. User have different needs for monitoring changes to bugs but a configuration UI could get very complex. What I have encountered frequently is that if a mass change has taken place, e.g. bugs are reassigned or move from one milestone to another I want to ignore all similar notifications once I have seen the first couple changes. I could imagine an affordance that would allow me to mark all tasks read that have the same delta and to optionally persist that, e.g. to never see changes to the CC field or changes that I have made (or changes a particular user makes).
I like it! +1 for this sort of mechanism.
Created attachment 185012 [details] patch v1 here is a first shot on this. The added command will mark similar changes (same repo, exactly the same changed attributes, but ignoring old/new values) as read I dare everybody to find a better name for it :)
Created attachment 185013 [details] mylyn/context/zip
well, for some reason I dont have permission to change the summary to [patch]..., so consider it tagged
Great stuff! Could you add a test case? > The added command will mark similar changes (same repo, exactly the same changed > attributes, but ignoring old/new values) as read Would it make sense to also scope this by working set?
Very cool. We should keep in mind fixes to the underlying problem, but until then a UI-level solution could be the best way to go. Also, there could always be a case for having a UI-based solution around, such as the need to deal with repositories that issue too many irrelevant task changes, such as stock Bugzilla.
Created attachment 185479 [details] patch v2 minor edit, checking comments as well. Although I am unsure on what comment-similarity should be - just any nr of new comments, or the same number, or the same comment text...what are other people's thought on this? Regarding test case: steffen, can you point me towards how to get the right data setup, I am pondering how to get it right so the TasklistNotifier can create the diff I want
Related to this, it would be nice to be able to say "never show me incomings for this task."
(In reply to comment #9) > Related to this, it would be nice to be able to say "never show me incomings for > this task." Interesting. Why would you have the task in your task list then?
Because it's a subtask of a task that is matched by a query, but it's a subtask that doesn't concern me at all.
(In reply to comment #11) > Because it's a subtask of a task that is matched by a query, but it's a subtask > that doesn't concern me at all. Yes, that's a problem that needs to be addressed. I can't find a bug for this. Can you open one?
Done. 334962: Support ignoring incoming notifications on subtasks of tasks matched by queries https://bugs.eclipse.org/bugs/show_bug.cgi?id=334962
I had a chance to look at the SynchronizationParticipant and have some comments: # Can ITaskDataDiff have access to the new comments? The existing MarkPlanningTaskHandler looks to see if there are new comments when determining if incomings pass the filter. # The extension point declares that extensions should extend TaskSynchronizationParticipant, but that class doesn't exist (I extended SynchronizationParticipant and it still seems to work). # Can ITaskAttributeDiff have access to the old and new values of the attribute? Not strictly necessary for what we want to do here but might be nice to have for other kinds of filters. # I implemented a SynchronizationParticipant and it prevents tasks from being decorated as unread, but they still appear in the incomings folder.
Thanks for the feedback! > # Can ITaskDataDiff have access to the new comments? The existing > MarkPlanningTaskHandler looks to see if there are new comments when determining > if incomings pass the filter. I have added a method to obtain comments. > # The extension point declares that extensions should extend > TaskSynchronizationParticipant, but that class doesn't exist (I extended > SynchronizationParticipant and it still seems to work). Thanks. Fixed. > # Can ITaskAttributeDiff have access to the old and new values of the attribute? > Not strictly necessary for what we want to do here but might be nice to have for > other kinds of filters. I don't want to expose that as API at this point but you can cast to TaskAttributeDiff to get the underlying attributes. > # I implemented a SynchronizationParticipant and it prevents tasks from being > decorated as unread, but they still appear in the incomings folder. Good point. I'll fix that. I extended the extension point to support specifying attributes that should be ignored directly, e.g.: <suppressIncoming attributeId="version" connectorKind="trac"> </suppressIncoming> I would strongly recommended to use that unless an actual SynchronizationParticipant is required for implementing more complex logic.
In org.eclipse.mylyn.tasks.core.sync.SynchronizationParticipant.setId(String), it looks like Assert.isNotNull(this.id); will fail.
Thanks for the review Sam. Good that the id did not get set :). Fixed now. Doug, can you please sync up and let me know if the latest changes work for you?
Looks great Steffen, thanks! I've ported the attributeId checks from MarkPlanningTaskHandler to supressIncomngs extensions for the bugzilla connector. Seems to be working as expected.
I have committed a round of fixes for focused mode and other places where the suppress attribute was not being checked properly.
I'll mark this as resolved as we now have basic support for ignoring incomings for specific fields. The extension point can be used in two different ways. 1. Define attributes that should not cause incoming notifications through the extension point (recommended): <extension point="org.eclipse.mylyn.tasks.core.synchronizationParticipants"> <suppressIncoming attributeId="version" connectorKind="trac"> </suppressIncoming> </extension> 2. Provide a class that processes ITaskDataDiff objects to determine the incoming status: <extension point="org.eclipse.mylyn.tasks.core.synchronizationParticipants"> <participant class="org.eclipse.mylyn.internal.CustomSynchronizationParticipant" id="org.eclipse.mylyn.tasks.tests.participant"> </participant> </extension>
Created attachment 190222 [details] mylyn/context/zip
