Hey,
The Java API library is now near complete functionality (as it stands in 1.0-alpha4), with nearly all of the administration commands added (i.e. deletes, renames, modifies etc). This paves the way for the Mylyn plugin to make use of those features bringing it closer to the those offered in the official client.
However, to make it 100% complete, I have a few questions :)
1) Read Status
Could you give a quick overview of how this works? I have implemented setIssueRead and setFolderRead, but cannot quite work out how to correctly query if an issue is read via the protocl.
There is also another quirk with read status. Mylyn also has a concept of read/unread tasks and I was hoping to integrate this. The problem appears to be, that the *server* marks the issue as read as soon the issue details are retrieved. To make full use of Mylyn, access to some attributes that are *not* returned on LIST ISSUES is required for the initial list query. So for each GET ISSUE DETAILS must be called (marking the issue as read). Most of the attributes are not actually displayed yet, so from the user's perspective the task is not "read".
Perhaps a new command (or an option to an existing one) indicating you don't want to set the read status when retrieving issue details. Alternatively, the root problem could be dealt with by having a way of getting additional attributes when using "LIST ISSUES ". This way Mylyn would be alot more efficient as it wont have to run GET ISSUE DETAILS until the task editor is actually opened.
2) Alerts
I could do with a quick overview of how alerts work as well.
3) Views
I would like to add view support so instead of building their own Mylyn query, users may select a view from a drop down box. Are there plans to allow the server to execute the view (including filtering). As far I can tell at the moment it is all done client side.
Alternatively, I could implement parsing of the view definitions generated by the official client. However, I dont think the semantics quite match up. and haven't given it much thought yet.
Another alternative is to allow saving of a Mylyn query in the view using a different definition format. The problem with this approach would be views that are Mylyn specific (will the offical client handle that OK?).
Apologies for the length of this post :)
Brett
1. Each issue has a "stamp" which is increased every time the issue is modified. The read status is the stamp when the issue was last read, so when it is 0, the issue is new, when it is less than the current stamp, the issue is modified, and when it is equal to the stamp, the issue is read.
What information is not returned by LIST ISSUES? GET DETAILS only return history of changes, comments and attachments in addition to what is returned by LIST ISSUES.
2. Alerts are used for two purposes. First is to send email notifications about issues matching certain criteria in certain folders (this happens on server side). Second is to display information in the projects tree. The content of folders which have alerts should be periodically updated and the number of unread issues is calculated (on the client side).
3. That's right, views are calculated on the client side. It would be best if the Mylyn user could use the standard WebIssues views (picked from a drop down box as you said) and in addition they could define their own queries in whatever format Mylyn uses. I don't know exactly how it looks and how much it is different from what WI uses; I wonder how other Mylyn plugins solve this problem?
Regards,
Michał
Excellent, thanks for the info.
1. Ok. That makes sense. I don't think I will end up using this functionality anyway. It appears Mylyn stores its own state as to whether the task is read or not (based on whether there are incoming changes). Incoming change state is determined by the last modified date, which is stored locally and "Read" is stored locally with no easy way of getting at it.
And yes, there is nothing missing in GET DETAILS. My confusion was partially caused by misunderstanding my own code, and partially a bug in the Mylyn plugin code ;)
2. Understood. I have added the feature to the API, but again I am not sure I should do anything with it in the Mylyn plugin, as it already refreshes all queries under it's own schedule (or when user initiated). For the sake of completeness though I will still add the ability to create and set alerts from with Mylyn.
3. Ok, thats the route I will go. Mylyn has no specific storage format for query parameters, it is down to the connector so there is no problem there. Where things differ is there is no concept of "columns" really as there is no 'table' style view of issues. Each query (view) contains a list of 'tasks' that consist of some basic information.
ID - Displayed in query view. Absolutely required.
Title - Displayed in query view. Absolutely required.
Priority - Display in query view on hovering over issue. Affects ordering.
Assigned to - Displayed in query view on hovering over issue. Information.
Due Date - Displayed in query view on hovering over issue. Used by scheduling feature.
Closed Date - Determines if bug is 'complete'. Currently uses Status Attribute/Last modified
To get the best out of Mylyn, this is the minimum you need. Everything else is only loaded in the 'task editor' where all the above plus all other issue attributes are visible.
While views without those columns will work, I will display a warning message saying some functionality will not work - maybe even give the option of automatically amending the view.
To be fully compatible with the official client, the API and Mylyn connector will also need to support all the same query conditions. Currently only something like "contains" is supported. I will add this support.
Also, the Mylyn query currently allows filtering based on lists of possible attribute values. E.g. Status may be one of "New,Accept,In Progress". Going by the official client, it appears that is not supported? I have found this invaluable in the queries I use.
Finally, Mylyn queries have filters on project and folder (multiple values allowed) and folder type (single value allowed). The reason for this is there is no tree view of projects / folders in the Mylyn UI, so you create queries for particular projects.
Can I stuff arbitrary values into the view definition and not make the official clients choke?
Thanks,
Brett
I see now. In that case the connector could simply ignore columns and just take filter conditions from the selected view. I think that the connector should store queries in a local configuration file; storing them as view definitions would cause problems - you could put additional info which the clients would ignore, but while editing the view that extra information would be lost. So the connector can provide the ability to build queries from the selected view (plus project, folder, etc.), but not to modify or create views.
I agree that the "in list" operator would be very useful for filters and I will include it in version 1.0, especially that there is no "OR" operator.
Regards,
Michał
Excellent, I will add support for "In list" in readiness.
Something I have just noticed about views, the attribute ID of each column seems a bit odd.
Am I right in saying that when dealing with views, the attribute ID is not the actual ID. The numbers 0-5 seem to be used to the "built in" types, whereas user defined attributes are ID + 1000?
Yes, that's correct. These values are defined in system/api/column.inc.php.
Regards,
Michał