Community
Participate
Working Groups
It would be nice to have a new query wizard similar to the one in the Bugzilla support and JIRA dashboard.
Eugene, I realize that you would prefer opening a query to take you to the query selection dialog, but I'd like to explore this first before doing that, since it would require a (minor) hack around our architecture.
Well, maybe there is some use in opening query results as a web page. So, you could provide both options (the same also true for Bugzilla). Another option would be to have special editor for altering query parameters like one opened for local groups. Then one of tabs could open web view.
*** Bug 131064 has been marked as a duplicate of this bug. ***
Created attachment 35968 [details] Custom query support Sorry, forgot to turn my brain on and search for existing issues first. Here is a patch that adds support for custom queries. A few problems: - Doesn't support editing queries - Queries aren't persisted - Removes the Named filter issue wizard - Probably heaps more...
Thanks Brock! I can't apply this in it's current form because it breaks mylar.jira.tests, and because it removes the support for existing filters from the UI. Those turn out to be an important part of the story for making it easy for existing Web UI users to easily move to Mylar (and that's going to be prominent in the EclipseCon presentation :) In terms of proceeding on this though, if you have time to preserve the current behavior, and to have us support the custom filters, than I should be able to add that before EclipseCon. If not I can put it on my list, but it's not that likely that I'll be able to get to it before EclipseCon.
Created attachment 39630 [details] Custom query support Reworked Brock's patch. Now support both server and custom queries. UI reworked to better use screen estate. Outstanding issues: xml serializer, editor for existing queries, some cosmetic UI glitches.
Nice!! What do you mean "xml serializer"? The queries were stored and restored correctly for me. I've fixed up the patch to match our code conventions, fixed warnings (should be none). The following need doing before I can apply: 1) Fix type safety warnings in FilterSummaryPage and IssueAttributesPage 2) Those two classes need to have a compatible copyright attribution. I changed it to the following. Brock: you need to aggree to this before I can apply the patch. Technically you asserted that this code was all your original code and copyright you when attaching the patch, but we need to keep the copyright notices straight. But if you like I can look into changing the "and others" to you or JIRA Dashboard project since my understanding is that you retain the copyright to this code. Let me know. * Copyright (c) 2006 - 2006 Mylar eclipse.org project and others. ... * Contributors: * Brock Janiczak - initial API and implementation Eugene: do you want to shoot for having this in tomorrow's release?
Created attachment 39731 [details] Mik's updates
Created attachment 39732 [details] Fixed warnings from comment comment #7 (In reply to comment #7) > Nice!! What do you mean "xml serializer"? The queries were stored and > restored correctly for me. Thing is that query params actually not saved right now. So, you can't edit query without it. > I've fixed up the patch to match our code > conventions, fixed warnings (should be none). The following need doing before > I can apply: > 1) Fix type safety warnings in FilterSummaryPage and IssueAttributesPage Fixed that in the attached patch. BTW, can you put all the warning and other configurations on the project level? > 2) Those two classes need to have a compatible copyright attribution. I > changed it to the following. ... > Eugene: do you want to shoot for having this in tomorrow's release? I'd pretty much love to! Actually I was doing all that only to be able to quickly change filter for fields such as due date... Then realized that those fields are not in the Brock's implementation. :-) Anyways, this is a step in the right direction.
Can do what we do with Bugzilla: just store the query as its HTML representation. If it changes, simply regenerate the HTML? The only trick is that to re-populate the fields you need to be able to parse the HTML string you create. But this approach is nice and flexible and all the saving would be done for you. And as of yesterday you can click Open in External Browser on any Bugzilla query, which can be useful.
(In reply to comment #10) > Can do what we do with Bugzilla: just store the query as its HTML > representation. If it changes, simply regenerate the HTML? The only trick is > that to re-populate the fields you need to be able to parse the HTML string you > create. But this approach is nice and flexible and all the saving would be > done for you. I have to look at this. I think Brock is doing something fancy with custom filter. It is saved under choosen name somewhere in prefs of jira core. Anyways, can we do it after you apply this patch? > And as of yesterday you can click Open in External Browser on > any Bugzilla query, which can be useful. BTW, why external? Please make it to respect settings from General / Web browser.
So I assume that you're getting query param persistence from JIRA Core Services then? In that case it seems OK for it to go out in the current state for 0.5.1 (marked Experimental)? I should wait for Brock's answer to comment#7 before applying.
wrt comment 7, i thought that as soon as a patch is added to bugzilla it became property of eclipse.org. The headers mention jira dashboard because i copied them across without modification just to get the thing going. I have no problems with you treating this as new code and putting the standard mylar header on it. It really doesn't need to be copyright mylar and others, but I am not a lawyer :)
Yes, that's correct Brock regarding it becoming eclipse.org's, although copyright gets retained by author(s), but I'm also not a lawyer :) I just want the copyright notices to be straight, and you answered my question so we're ready to attach :) I'll figure out what the right top of the copyright statement is for this kind of thing since I can't find an example on eclipse.org off-hand. But great, looks like we can go ahead :) Eugene, just answer comment#12 and I'll apply.
(In reply to comment #14) > Yes, that's correct Brock regarding it becoming eclipse.org's, although > copyright gets retained by author(s), but I'm also not a lawyer :) I just want > the copyright notices to be straight, and you answered my question so we're > ready to attach :) I'll figure out what the right top of the copyright > statement is for this kind of thing since I can't find an example on > eclipse.org off-hand. But great, looks like we can go ahead :) > > Eugene, just answer comment#12 and I'll apply. I think that is the case. Though I haven't changed that code. Its been in Brock's original patch. So, please apply this stuff and we can work on fixes. PS: Brock, I hope you don't mind me messing with your patches. I just really wanted this in, and got seek from that dropdown thing in current integration.
Will be back online in a bit... can't apply this yet becaue it's not fully functional, the following breaks (as you probably realize) - create query - synch - exit workbench - synch query (fails, no matches, no way to edit)
Created attachment 39758 [details] fix for query persistence (In reply to comment #16) > can't apply this yet becaue it's not fully > functional, the following breaks (as you probably realize) > - create query > - synch > - exit workbench > - synch query (fails, no matches, no way to edit) Ok. I've made a quick hack to resolve this issue (using Java serialization and storing encoded FilterDefinition). Proper fix would require changes in Jira core services - encode/decode (perhaps in form of http params) In addition I made some tweaks in new query wizard and added editor for existoing queries. Things that not working yet: -- Open in External browser does not work (would need Jira core to expose query url somehow) -- Editor wizard can't go to the next page if custom filter is selected. I wasn't been able to find why. I think this can be resolved later. Though we may have incompatible data structures when Jira core will provide own encoding methods. But personally I would be ok with loosing query data if format changes.
This change caused me to lose all my JIRA queries becuase the filter definition was null, so some extra exception handling needs to happen there to ensure it can't happen to users: FilterDefinition filter = decodeFilter(custom); Also, it breaks the filter save test, and perhaps that's related to my losing queries (is it passing for you?). If you can get that fixed we may still be able to get this in to 0.5.1 (freeze early aft PST), since this is a reasonable hack until the URL-based saving can be done. We will have to mark Experimental since people could lose query settings after the format is changed). junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNotNull(Assert.java:220) at junit.framework.Assert.assertNotNull(Assert.java:213) at org.eclipse.mylar.jira.tests.JiraTaskExternalizationTest.testJiraFilterHitSave(JiraTaskExternalizationTest.java:144)
Created attachment 39794 [details] fix for deserializing broken queries (In reply to comment #18) > This change caused me to lose all my JIRA queries becuase the filter definition > was null, so some extra exception handling needs to happen there to ensure it > can't happen to users: > > FilterDefinition filter = decodeFilter(custom); > > Also, it breaks the filter save test, and perhaps that's related to my losing > queries (is it passing for you?). I've added couple additional checks. And have verified that other tasks are staying there if custom filter can't be deserialized. > If you can get that fixed we may still be > able to get this in to 0.5.1 (freeze early aft PST), since this is a reasonable > hack until the URL-based saving can be done. We will have to mark Experimental > since people could lose query settings after the format is changed). Makes sense.
Patch applied! This is a really great contribution. And the timing is great because soon I'd like to pull a bit more common query and wizard into tasklist. Please check out the minor UI changes I made (just to the labels) to make it more consistent with the Bugzilla connector. So I think that this task is done. It looks like we have two things left to do, do you want to make them seperate reports? - URL-based storage for custom JIRA queries - editing custom query properties (currently opens dialog, but can't click "finish") Since this isn't completely covered by unit tests I'm going to add some coverage to "tests-manual.html" where we have the Bugzilla coverage. I'll be making a dev build available shortly so that you can work with this support before we release.
Dev build is available.
Created attachment 39840 [details] Tall dialog Very nice Eugene. The only problem i have is the excessive amount of vertical space whed when there are a lot of projects (see screenshot). One thing that may be worth trying is moving the versions and components under the project, shortening the project list and displaying a text box (or browser) on the right displaying the description. When there is support for getting categories from the server, there could be an option to display the projects as a tree or a list.
(In reply to comment #20) > Patch applied! This is a really great contribution. And the timing is great > because soon I'd like to pull a bit more common query and wizard into tasklist. Thanks Mik. Current query code definetely need a good refactoring. > So I think that this task is done. It looks like we have two things left to > do, do you want to make them seperate reports? > - URL-based storage for custom JIRA queries https://bugs.eclipse.org/bugs/show_bug.cgi?id=139312 > - editing custom query properties (currently opens dialog, but can't click > "finish") https://bugs.eclipse.org/bugs/show_bug.cgi?id=139314 I've looked at this quickly, but wasn't been able to find what the issue is. It seems like life cycle for editor and wizard dialogs are somehow different. Same about dialog size on details page Brock reported. I actually cheated and used WindowBuilder to drag components around. :-) So, I am not sure why and how, but it seems like vertical grabbing space is set to something too agressive. > Since this isn't completely covered by unit tests I'm going to add some > coverage to "tests-manual.html" where we have the Bugzilla coverage. I'll be > making a dev build available shortly so that you can work with this support > before we release. I didn't want to spend time on tests, because persistence stuff will change...
(In reply to comment #22) > Very nice Eugene. The only problem i have is the excessive amount of vertical > space whed when there are a lot of projects (see screenshot). Problem is that dialog is resize automatically, and I can't figure out why. > One thing that may be worth trying is moving the versions and > components under the project, shortening the project list and > displaying a text box (or browser) on the right displaying the description. Not sure what you mean by this. Can you make a screen mockup or something? > When there is support for getting categories from the server, > there could be an option to display the projects as a tree or a list. Not sure if that would be a good idea. Right now you can jump to the project hitting first letter. So, maybe quickfilter would be better.
Marking resolved since this is now functional (yay!). There is still the formatting issues, and those can be attached to this or to another report as you see fit. (It's funny, I never bothered to make a filter for just Mylar-related JIRA dashboard issues, but with this did it right away :)
(In reply to comment #25) > Marking resolved since this is now functional (yay!). There is still the > formatting issues, and those can be attached to this or to another report as > you see fit. What Eclipse build can I use with latest dev? > (It's funny, I never bothered to make a filter for just > Mylar-related JIRA dashboard issues, but with this did it right away :) One thing probably would make sense to change for both Jira and Bugzilla editors is to allow to specify custom name. Then put that name field on top 1st wizard page for both jira and bugzilla. So, it will allow to use custom name even for server side filters.
Any post-RC1 non nightly should work with the latest dev. But I'm about to put up a new dev build.
(In reply to comment #27) > Any post-RC1 non nightly should work with the latest dev. But I'm about to put > up a new dev build. What are you using? Recent integration builds all red. :-(
I know <sigh>. Just use the following: http://download.eclipse.org/eclipse/downloads/drops/I20060428-1315/index.php Mylar build with 1600 will be available within minutes too.
