Community
Participate
Working Groups
Jira custom queries now stored as serialized blob. URL-based storage for custom JIRA queries is needed to make it implementation neutral and allow to open query in a browser. So, the following features should be provided by Jira core services: -- encode FilerDefinition/NamedFilter unto the url -- decode url back to FilterDefinition or NamedFilter, based on params -- allow to obtain url for opening external browser (maybe same as encode above)
Eugene, Brock, it would be great if one of you could take this on by 0.6.
It has to be fixed in jira core services, so means new public API. Brock would be the right person for that. Change on Mylar side should be minimal (replace serialization with that new API).
Eugene, the FilterDefinition and NamedFilter classes exist to decouple the representation of a filter from its implementation. Although you can use a url to execute both of these filters, in the future Jira will offer RPC services to run filters without having to parse the results. I think there is already one to run named filters. also, the human readable url is different than the machine parsed one. The URL can also change between Jira versions. Instead of adding API to the filter objects, would a helper class that converts from a filter to a URL be ok? It might also be nice to have a utility to create a human readable description for a filter as well.
(In reply to comment #3) > Eugene, the FilterDefinition and NamedFilter classes exist to decouple the > representation of a filter from its implementation. Although you can use a url > to execute both of these filters, in the future Jira will offer RPC services to > run filters without having to parse the results. I think there is already one > to run named filters. > > also, the human readable url is different than the machine parsed one. The URL > can also change between Jira versions. > > Instead of adding API to the filter objects, would a helper class that converts > from a filter to a URL be ok? It might also be nice to have a utility to > create a human readable description for a filter as well. I suppose, either way should be ok. Though it would be nice if we can generalize named and custom filters, so one won't have to check instanceof every time. Note that there is also a need to open filter results in a browser (in other words, create link to the web UI), so we need to get that from core services too.
Brock, will you be able to add this?
I don't really understand why you need the URL of the filter. You could quite easliy store the filter as a favourite on the JiraServer instance and have core services look after the persistence. All you would then need to do is store the name of the filter in mylar. I also don't understand why you would need to open a query in a browser. Mylar is meant to replace the web interface. alternatively, since mylar created teh filter in the first place, it should know how to recreate one that has persisted in another form.
(In reply to comment #6) > I don't really understand why you need the URL of the filter. You could quite > easliy store the filter as a favourite on the JiraServer instance and have core > services look after the persistence. All you would then need to do is store > the name of the filter in mylar. I don't think it will be a good idea because Mylar has its own achiving mehanisms, so it won't be possible to restore queries saved externally. Basically we have two options: -- use custom xml format and manually recreate filter definition (lot of code and duplication) -- use url encoding and let Jira services to decode it back to the filter definition I agree with Mik that second option is more flexible and introduce less coupling with jira services. > I also don't understand why you would need to > open a query in a browser. Mylar is meant to replace the web interface. I guess there is some value in easy access to the web UI. First of all because not all operations are avaialable in Mylar and there is a good chance that they all will never be avaialable. Even to send a link to someone such feature would be really handy. > alternatively, since mylar created teh filter in the first place, it should > know how to recreate one that has persisted in another form. That will be arounf 1-2 screens of code in my rough estimate and since most of that code is already in jira core service it does not make any sense to create another wrapper to hide such complexity.
Brock, any chance to get this resolved?
I have added a URL field to Issue, but i am still reluctant to add another filter serialization format. The main problem i have with URLs is that they are not the same between Jira versions, so if you save a query in a version and the server upgrades, we won't know how to recreate the query. It also seems silly to go from URL to object back to URL (especially if the URL is encoded in the same way). The reason I used objects to represent queries is because it makes query composition easier and also allows you to easily move a query from one server to another (the server location is not stored in the query). Take a look at some of the code in ProjectSummaryBlock to see how much nicer it is to work with an object model instead of a string. Where in the Mylar UI do you plan on using the URL to display query results? Isn't this what the task list is for? If you *really* need this persistence option, take a look at Jira33RSSFilterConverter (and the subclass) to see if it is what you need. It is internal, so i don't know if you can access it.
There are two cases when we need URL. -- "Show in browser" that should work for both issues and the query itself. Query part is currently not working. -- Serialization of query configuration within Mylar storage. Current hack with base64 encoding of serialized object is working, but I think it is quite fragile and can be lost once jira objects changes. Perhaps we can have some externalized form here, which not necessary has to be an URL, but something that can be parsed back into jira objects.
Brock, in my opinion URLs are a great format for storing query hits, and in the long-run much more portable than any object serialization because they're one of the most concise represntations of a query. Providing a facility to change the server URL is easy and already provided by TaskListManager.refactorRepositoryUrl(..). Supporting multiple versions is also straightforward because you just need a method to encode/decode the URL for each server version. However, I'm willing to bet that JIRA will make it's URLs stable or forwards compatible because of the likelyhood that people are already linking to them. On the flipside, if we continue with a filter object serialization approach, as soon as the filter object changes all of the queries someone has in their tasklist will break. Which brings up the question of an XML format, but using an URL is both more concise, more stable, and more flexible.
(In reply to comment #11) > Brock, in my opinion URLs are a great format for storing query hits, and in the > long-run much more portable than any object serialization because they're one > of the most concise represntations of a query. Providing a facility to change > the server URL is easy and already provided by > TaskListManager.refactorRepositoryUrl(..). Supporting multiple versions is > also straightforward because you just need a method to encode/decode the URL > for each server version. However, I'm willing to bet that JIRA will make it's > URLs stable or forwards compatible because of the likelyhood that people are > already linking to them. See: http://confluence.atlassian.com/display/JIRA/Parameter+changes+in+Issue+Navigator The format has already changed once. The old ones still work (apart from a message being logged everytime one is used), but may be removed at any time. > > On the flipside, if we continue with a filter object serialization approach, as > soon as the filter object changes all of the queries someone has in their > tasklist will break. Which brings up the question of an XML format, but using > an URL is both more concise, more stable, and more flexible. > That is what the serialversionUID is for. If you make a change that requires 'upgrading' and object to a new version, you need to create a custom read method for it. So far all changes have been non breaking (the Server object has changed several times and no one has even noticed). Even with a URL or XML format you still need to handle the case of loading an older version of the object. I will look into how much effort it will be to change all of my stuff to persist filters as URLs (and upgrade them as needed)
Brock, any luck with this issue?
We really do need this: the current serialized objects are bloating the task list, and I'm concerned with how brittle they are.
Tentatively scheduling for 1.0. Brock: will you be able to provide the URL-based externalization in JIRA Core Services?
Created attachment 53123 [details] First cut of the url-based representation of Jira query This patch fixes open query with browser as well as Jira externalizer And I had to fix broken query name in the wizard page...
Created attachment 53124 [details] mylar/context/zip
Great stuff Eugene. But could you please re-cut the patch, there is a conflict with JiraTaskExternalizer due to some query hit related changes I made recently. It should be a straightforward merge on your end.
Created attachment 53151 [details] Updated patch with resolved merge conflicts
Applying gave me a build error in JiraTaskExternalizer, since a TaskRepository parameter is now needed. Could you please double-check your patch? Also, please make sure to hit Ctrl+Shift+F on the file before submitting the patch. We have no test coverage for this so it will be hard to maintain. Will you be able to write a few tests that give JiraCustomQuery a filter and make sure that the URL is reasonable? Even just a couple of coarse grained tests will help if something changes about filter definitions.
Created attachment 53161 [details] Updating patch again It seems one of the resources had been dropped from the Mylar's changeset and didn't went into the patch. I have two really heavy patches in my workspace and it would really help to eliminate at least one of them. Then I could work on the test cases and any broken functionality. Can we do that?
Yup, I feel your pain and would like to get this applied for you asap and can do a first pass without the tests as long as it works (note that we have the 3.3M3 dev build go out tomorrow). There is a bug though: create a query on Atlassian JIRA that has a few matches, synchronize it, close workbench, open workbench, and now the query parameters will be forgotten so it will be populated with tons of hits. JiraTaskExternalizationTest should be easy to extend to duplicate the failure. Note that JiraTaskExternalizer.encodeFilter(..) was not used in the patch, perhaps that is the problem?
Eugene: can you have a new patch for this tomorrow aft?
(In reply to comment #23) > Eugene: can you have a new patch for this tomorrow aft? Very unlikely. Tomorrow night might, or Wed morning is more realistic.
OK. I just want to make sure that we get this solid for 0.9 since we should only ask JIRA users to re-create their queries once.
(In reply to comment #25) > OK. I just want to make sure that we get this solid for 0.9 since we should > only ask JIRA users to re-create their queries once. I think my patch is backward compatible. So, it will read old format and will always save into the new one.
Excellent. That's what we've always tried to do with all such migrations, to avoid punishing the oldest users.
Created attachment 53438 [details] Updated patch and added roundtrip test
Patch applied. Great stuff Eugene, this will make queries more robust going forward, and Open with Browser is working very nicely. Note that I moved the test to ..mylar.jira.tests to match our convention, and added it to AllJiraTests, and put you as the author.
