Community
Participate
Working Groups
A connector may wish to report the status of a task submission. For example, the Bugzilla Web UI reports who was notified of the change to the bug (bug 165072). Rob: AbstractRepositoryConnector may not be structured right for this, but is there another place in the API where we can report this status?
AbstractTaskDataHandler.postTaskData() could return data structure that in some what wraps: * error status (if any) * reference to new bug id in case of new bug submission * connector specific key, value pairs
(In reply to comment #1) > AbstractTaskDataHandler.postTaskData() could return data structure that in some > what wraps: > * error status (if any) > * reference to new bug id in case of new bug submission > * connector specific key, value pairs Is it OK that I now start with this? Is it OK to now change the resulttype of AbstractTaskDataHandler.postTaskData()
Created attachment 84813 [details] Proof of concept for bugzilla Please check if this can be the way how to implement this.
Created attachment 84814 [details] mylyn/context/zip
Created attachment 85769 [details] New Patch This Patch is the base implementation for bug168204. This demostrate how to use this for Bugzilla.
Created attachment 85770 [details] mylyn/context/zip
Frank, we need to work out a general solution for post task submission work flow, which ties directly into what you have done here. This needs to be taken into account along with the other work being done on bug#179254. Steffen and I will need to review this together so are unfortunately blocking on this at the moment while other work is completed. Once this is done we can integrate your patch.
Rob, Frank: we are at the 2.3 freeze, so this will need to wait until 3.0.
I have changed the API in AbstractTaskDataHandler2 to return an object of type RepositoryResponse (see bug 194570). Connectors can extend that type to return a custom response from the repository. This response object will be available to the editor. Frank, this is similar to the proposed change in your patch. Please check if the new API is suitable for your requirements. Please note that the new API is not used at the moment and will require porting of the Bugzilla connector to the new task data / editor architecture
(In reply to comment #9) > I have changed the API in AbstractTaskDataHandler2 to return an object of type > RepositoryResponse (see bug 194570). Connectors can extend that type to return a > custom response from the repository. This response object will be available to > the editor. Did you think that a Connector like Bugzilla should subclass RepositoryResponse. If so I think it is better to rename this class to AbstractRepositoryResponse . > > Frank, this is similar to the proposed change in your patch. Please check if the > new API is suitable for your requirements. I think that this is a good base for doing the extensions that we need for email addresses or Content proposals. > Please note that the new API is not > used at the moment and will require porting of the Bugzilla connector to the new > task data / editor architecture Is there an other bug that I can watch so that I know when I can start. Or do you think that we do this within this bug. Is this your task or do you think that I should take this?
> Did you think that a Connector like Bugzilla should subclass RepositoryResponse. > If so I think it is better to rename this class to AbstractRepositoryResponse . My sense is that most connector won't have a need to extend the class. The framework currently only uses two different responses: "task created" and "task updated". This will be sufficient for JIRA and Trac as other cases are error cases and will be indicated by an exception. > > > > Frank, this is similar to the proposed change in your patch. Please check if > the > > new API is suitable for your requirements. > I think that this is a good base for doing the extensions that we need for email > addresses or Content proposals. Great. We can still extend / change the API based on requirements for Bugzilla. > > Please note that the new API is not > > used at the moment and will require porting of the Bugzilla connector to the > new > > task data / editor architecture > Is there an other bug that I can watch so that I know when I can start. > Or do you think that we do this within this bug. > Is this your task or do you think that I should take this? I am not sure if there is a bug, yet. Rob as the maintainer of the Bugzilla component will be managing any porting. I am currently using the JIRA connector as the driver for the API refactorings. To track progress it is best to create a query for all bugs that contain"[api]" in the summary and that are scheduled for the "3.0" milestone. Getting these bugs fixed is currently our highest priority and all api changes/enhancements are tracked on those bugs. Frank, I am reassigning this bug to you since there is still an open patch attached that extends Bugzilla's error handling.
Need to defer applying: http://wiki.eclipse.org/index.php/Mylyn/3.0_Plan#Deferred_Items
Is there a driver or open bug for incorporating the code from the patch on this bug?
Part of me it seems relevant for the sake of completeness, since it is something that the Web UI offers, and is useful for know when someone is watching bugs. However, it partly goes against the normal mode of working in Mylyn, which does not rely on email notifications. In terms of UI, one thing I can imagine us doing with it is having an Info message that says "Submitted..." and then a tooltip that shows all the email addresses notified of the change.
Frank, could you port your patch to the current head and change your implementation to extend RepositoryResponse in a Bugzilla specific way, i.e. create a subclass in the Bugzilla core plug-in that has additional fields? We can then discuss ways to make the result of the task submit job available to the task editor.
Disregard my last comment, I just realized that this has already been implemented on bug 168204. How about this: We add a new method to the task editor page which is invoked after a submit, e.g.: protected void taskSubmitted(SubmitJobEvent event); The event object would provide access to the details, i.e. the status of the submit job and RepositoryResponse object. The Bugzilla task editor page could override the method and handle the result accordingly. Frank, would that suffice to implement bug 165072 and bug 168204?
(In reply to comment #16) > Disregard my last comment, I just realized that this has already been > implemented on bug 168204. > > How about this: We add a new method to the task editor page which is invoked > after a submit, e.g.: > > protected void taskSubmitted(SubmitJobEvent event); > > The event object would provide access to the details, i.e. the status of the > submit job and RepositoryResponse object. The Bugzilla task editor page could > override the method and handle the result accordingly. > > Frank, would that suffice to implement bug 165072 and bug 168204? Steffen, is it OK that I do this in the following way 1) update the patch for bug 168204 and create the SubmitJobEvent 2) do this bug 3) go to create a patch for 165072 What is the timeframe to get this done and reach the 3.2 version? If time is to short can you take over one or more steps?
Created attachment 134890 [details] patch
Created attachment 134891 [details] mylyn/context/zip
> 1) update the patch for bug 168204 and create the SubmitJobEvent > 2) do this bug > 3) go to create a patch for 165072 That sounds good. I have attached a patch to this bug with the proposed API. When working on the other bugs you can assume that this API exists but I don't want to commit it until we know it is sufficient. Note that there is one outstanding problem that needs to be fixed when a new bug is submitted: The handleTaskSubmitted() method should be invoked on the newly created editor in that case. > What is the timeframe to get this done and reach the 3.2 version? If time is to > short can you take over one or more steps? My list for 3.2 is already overloaded so I probably won't have time. It would be great if we had a first working version of the user match mode support by 3.2M2 (May 15th) which would give us some time to review and work out any problems. In case that is not enough time you could consider prioritizing bug 165072 which is less valuable but might be simpler to tackle.
Patch comitted.
