Community
Participate
Working Groups
There is no way to deprecate a patch in our UI, so people are either relying on the web UI to do this or not doing it.
Any UI suggestions for this? We could add another wizard page for attachment creation, but that makes 4 with the preview page. (Though this one and the preview are both optional) An alternative would be to add a table to the attachment details page where users could select attachments which are depricated. This would make the whole dialog larger.
How about just adding a context menu action to attachments called "Mark Obsolete"? It varies from the Bugzilla interaction, but I think that it is more obvious, easier to implement, and needs to be there anyway. Then if enough people complain we can add a table to the wizard page.
Please alo add "unmark obsolette" too. I suppose it would submit change right away?
We could make it immediate to be in line with the way that uploading attachments work. However we should establish what is immediate and what is not or users might start getting confused. If I change the priority and bug ownership, its not updated until I hit submit. If I add an attachment or mark one obsolete, it updates immediately... There is a natural reason why w.r.t bugzilla (each of those is its own transaction) but that isn't necessarily obvious to the user. Un-obsolete is doable as well.
Excellent point, we need to draw a clear line and I'm probably blurring it too much. Our current or example, we may want to enable priority setting for repository tasks via the task list, and those should take place immediately. For now I'm tempted to keep with the eclipse.org convention that everything in the editor does not take effect until it is 'saved', which in our case is a combo of save and submit (e.g. direct actions can only be done via the task list or via a wizard, which is in line with conventions). So maybe the best thing for you to do for now is to create a page for deprecating patches, and pop up that single page if "Mark Obsolete" is clicked??
Hmm. On a second though, wouldn't it make sense to make all the changes without submission and submit everything at once when user hit Submit button? That should include attachments as well. But attachments should immediately appear in the attachments table once they added. It may also make sense to add an "Obsolete" column with checkboxes that user can uncheck to mark attachments obsolete...
We'll have to discuss this further before deciding, and should wait for Rob since he has spent a lot of time thinking about the editor interaction. Jeff: for now just stick with the current interaction and put the deprecation functionality into the wizard, since it will most likely always be needed there.
(In reply to comment #7) > Jeff: for now just stick with the current interaction and put the deprecation > functionality into the wizard, since it will most likely always be needed > there. Heh. It would of saved time if that would be done in the attachment table right in the editor. Even if those changes are not submitted immediately... Note that it would also allowed to obsolete existing patches without submitting a new one.
The IAttachmentHandler API doesn't support a way to depricate patches. How should we handle this? I've implemented everything to be generic in the tasks namespace so far, maybe this should be bugzilla specific? The RepositoryAttachment class has an isObsolete() method so it seems the concept of obsolete attachments is generic to all repo types, perhaps an obsoleteAttachment() method should be added to the IAttachmentHandler instead of making this bugzilla specific. thoughts?
Since other attributes may change, perhaps we need a more generic method like updateAttachment(...)? That way we don't have methods for each attribute that may change.
Just a thought: we are now discussing about the applicability of the "attachment deprecation" on connectors other than bugzilla. In fact, there may be other capabilities who are applicable to bugzilla but not in other connector(s), and vice-versa. The problem here is to define a stable interface not tied to any specific repository connector. I didn't take a look on the connector architecture used in Mylar, but I presume it is actually based on a interface hierarchy implemented by concrete connectors. Have you considered adopting a adapter-based architecture like in ECF Container's model? This way there can be a number of interfaces defining "capabilities" that a connector can have, and each connector implements the interfaces for the capabilities it supports. In this model, if you want to know if a connector X supports a capability Y, all you have to do is ask it for the corresponding interface via IAdapterManager. Of course, maybe this can be a complex solution to this specific issue, but it is something that we can face when considering how to evolve the connector architecture in a flexible way. Just my 0,02 cents...
The UI components are in place in the wizard (it will be easy enough to add operations to the context menu of the attachment table too if needed). I've filed bug 153788 to track the issue of creating generic API to allow depricating (and other generic operations) on repository attachments.
*** Bug 165075 has been marked as a duplicate of this bug. ***
Jeff: I'm assuming that you won't be able to get to this soon. Would definitely be nice to have, but need to mark as "helpwanted" for now.
By the way, Mik, were you able to finish applying patches trough new 3.3 API?
(In reply to comment #14) > Would definitely be nice to have, but need to mark as "helpwanted" for now. Mik, do you confirm if the "core" functionality is fully implemented and only the UI is left? (I'm assuming that fixing bug#153788 was sufficient for this).
No, it is not currently implemented for Bugzilla (see BugzillaAttachmentHandler).
Btw, for what it's worth Rob says it shouldn't be that hard to do, because it's just a post with the right ID inserted.
Mik, was it reply to Willian's question or mine? (comment #15) > By the way, Mik, were you able to finish applying patches trough new 3.3 API?
(In reply to comment #19) > Mik, was it reply to Willian's question or mine? He forgot to use the new, fancy, reply button from bug#161479 :) Sorry, I couldn't resist the joke...
(In reply to comment #20) > (In reply to comment #19) > > Mik, was it reply to Willian's question or mine? > He forgot to use the new, fancy, reply button from bug#161479 :) I guess he just couldn't see that button on his big screen. It is so small. :-)
:)
Hey, it's not that hard to see because we kept the saturated version ;) (In reply to comment #15) > By the way, Mik, were you able to finish applying patches trough new 3.3 API? He he. OK, so I got 90% through this (bug 103932) but couldn't make the Apply Patch wizard read in the patch when it was written to a temporary file outside of the workspace. I may be able to give it a little more time this week but not much. I pinged Jeff to see if he was interested in helping out on it but no reply.
Hmm. Don't they have resource-based way to get to the patch content? Or something like ISource used for editors...
I really would like to see that feature. At the moment I use the web ui for it which is not what I really want to do.
Unfortunately we can't add this to our 2.0 list right now, so it won't make it in without a patch and I'll leave it as helpwanted for now. Agreed that going to the Web UI for this is a pain right now.
*** Bug 152676 has been marked as a duplicate of this bug. ***
A context would be nice for this one.
I think "deprecate" action need to be added to the popup menu for the attachment table created in AbstractRepositoryTaskEditor.createAttachmentLayout(). Action would call AbstractAttachmentHandler.updateAttachment() which should delegate to new method in BugzillaCleint which would update attachment status. New test case could go into BugzillaRepositoryConnectorTest, which already have one testcase for attachment reading or into the new test class for BugzillaAttachmentHandler.
Created attachment 78110 [details] mylyn/context/zip
Thanks Eugene, no commitments yet :) This is irritating me quite a bit so in the spirit of open-source, I may be irritated enough to contribute :)
(In reply to comment #29) > I think "deprecate" action need to be added to the popup menu for the attachment > table created in AbstractRepositoryTaskEditor.createAttachmentLayout(). Action > would call AbstractAttachmentHandler.updateAttachment() which should delegate to > new method in BugzillaCleint which would update attachment status. I've done the first few things but got stuck trying to write a method to update the attachment status in the Bugzilla Client. Any pointers as to how this can be done? Do I have to look at the bugzilla documentation or check out similar functionality somewhere in Mylyn?
It looks like you'll need to do a HttpPost to attachment.cgi similar to the attachment edit page does. There isn't any support for this in the BugzillaClient but shouldn't be too hard to add. <form method="post" action="attachment.cgi" onsubmit="normalizeComments();"> <input type="hidden" name="id" value="78110"> <input type="hidden" name="action" value="update"> ... <input type="checkbox" id="ispatch" name="ispatch" value="1"> <label for="ispatch">patch</label> <input type="checkbox" id="isobsolete" name="isobsolete" value="1"> <label for="isobsolete">obsolete</label>
On this point of deprecating attachments, maybe this should be made more generic to allow for deletion as well. Many repositories allow for deletion of attachments, where I see deprecation as more of a bugzilla-centric operation. Is this feasible to add? 209880: add support for deleting attachments https://bugs.eclipse.org/bugs/show_bug.cgi?id=209880
+1 for being able to mark patches obsoleted/deprecated by subsequent patches w/o having to hit the website.
It would be great to have this. We don't currently have the cycles to put it on the 3.1 plan. Is anyone interested in contributing it?
Frank, would you be interested in adding this functionality? See comment#33 for a pointer.
Created attachment 117720 [details] patch first try, please verify. An jUnit test is included but must changed to an MylynTest Repository.
Created attachment 117721 [details] mylyn/context/zip
Good stuff! One suggestion for refactoring: I would like to avoid any changes in the tasks framework for this since deprecating patches is a Bugzilla specific feature. Frank, it should be possible to only contribute the action for Bugzilla attachments (e.g. look at how RetrieveContextAttachmentHandler works). It would also be great if the action supported selection of more than one attachment.
(In reply to comment #40) > Good stuff! One suggestion for refactoring: I would like to avoid any changes > in the tasks framework for this since deprecating patches is a Bugzilla > specific feature. Frank, it should be possible to only contribute the action > for Bugzilla attachments (e.g. look at how RetrieveContextAttachmentHandler > works). I looked at comment#34 and was under the impression that update of attachments is not Bugzilla specific. That was the reason for the change of the task framwork. > > It would also be great if the action supported selection of more than one > attachment. > OK I think I have to create an Job to do this with user feedback.
Created attachment 117959 [details] new patch (In reply to comment #40) > Good stuff! One suggestion for refactoring: I would like to avoid any changes in > the tasks framework for this since deprecating patches is a Bugzilla specific > feature. Frank, it should be possible to only contribute the action for Bugzilla > attachments (e.g. look at how RetrieveContextAttachmentHandler works). Hope that this patch include the things that you want to have. > It would also be great if the action supported selection of more than one > attachment. This is now part of the patch.
Created attachment 117960 [details] mylyn/context/zip
Rob, the patch looks good to me. The only changes I would suggest is to not modify ReposonseKind but use a Bugzilla specific return type in postUpdateAttachment instead and to generalize the editor refresh in UpdateAttachmentJob (see SynchronizeEditorAction).
Created attachment 119082 [details] updated patch (In reply to comment #44) > Rob, the patch looks good to me. The only changes I would suggest is to not > modify ReposonseKind but use a Bugzilla specific return type in > postUpdateAttachment instead and to generalize the editor refresh in > UpdateAttachmentJob (see SynchronizeEditorAction). > This is now included.
Created attachment 119083 [details] mylyn/context/zip
Filed CQ: 2867
(In reply to comment #47) > Filed CQ: 2867 > All changes in the patch submitted in comment#45 were authored by me and I have the right to contribute this code to Eclipse.
The CQ was approved. Patch applied, ip log updated. Further refinements to this feature will take place on bug#258717.
