Community
Participate
Working Groups
Investigate a data model for the tasks which could be used to store the INCOMING_REVIEW flag.
I changed the summary because we can just store this as a property on the ITask. The interesting part will be updating the guaranteed visibility rules. See the attached context.
Created attachment 256850 [details] mylyn/context/zip
I'd like to work on this.
*** Bug 479597 has been marked as a duplicate of this bug. ***
Thanks for the context Sam. It got me on the right track for the filtering aspect, which I think I have the barebones skeleton in place for. The task updating workflow is a little vauge to me -- there's not a lot of comments so I've been relying on the context browser to guide me around (super handy, by the way!) For setting the attributes, this is my current plan of attack: * I took a look at the SynchronizationJob's and their factory for generaring them. * Eventually, this leads me to a lot of `updateTaskData` statements and I've discovered a TaskDataManager which eventually delegates to a connector. For "Tasks", or at least a Task as I know it, I believe I should be setting the attributes here, and looking up any particular mappings and setting them. * Blaine could be doing this and we could store the data as mappings in here? It's possible. A few questions spring to mind... 1) Why does a "BugzillaConnector" have an updateTaskData method? It doesn't manager "Tasks", right? 2) At what point does it make sense to set this indiciator? Maybe it should be done when a "review" changes? 3) If the above, any suggestions on where to hook in a listener? Thanks!
New Gerrit change created: https://git.eclipse.org/r/58293
Vaughan, I don't think your question is related to guaranteed visibility, so I am going to respond on the parent bug.
New Gerrit change created: https://git.eclipse.org/r/58768
