The idea is to use the Dynamic Toolbox Filtering function to provide every user with some flexibility to change their own tool panel. The available filters can be defined by an admin. For example one filter for 'genome annotation tools', one NGS filter and another one for cheminformatics.
Modules from lib/galaxy/tools/filters/ can be specified in universe_wsgi.ini.
tool_ filters will be applied for all users and can not be changed by them.
user_tool_ filters will be shown under user preferences and can be toogled on and off by runtime.
I am going to play devil's advocate for a second. There is a central use case here that is so important but yet simple that perhaps augmenting the toolbox XML and taking care of it automatically so that institutions wouldn't need to write custom code is a better way to go. That use case is the one you outlined of providing different tool 'profiles'. I guess I am envisioning adding a new <profile name="x" description="y" enabled_by_default="true" /> element to the toolbox XML and allowing something like if_profile="a" and if_not_profile="b" to each element of the toolbox XML (section, label, tool). Galaxy could then parse out the profiles, add the preferences, and implement this using a standard tool filter that is enabled by default.
If there are other use cases, I think adding these is a great idea. But if we all just want to do that one thing (enabling/disabling certain tool profiles, and trust me you are not the only one who wants that functionality) perhaps a simpler to maintain approach is better.
Let me just clarify that I meant simpler to maintain for the deployer, I think your approach is actually simpler to maintain for the core Galaxy developers.
thanks for your comments. The problem I see with the toolbox XML file is that it is hard to maintain manually. The toolshed writes to it, merging of several files into integrated_tool_panel.xml and so on.
But you are completely right, the filters should be easier to maintain for the admins. My ideas was to introduces something like 'tags' to tools. Tags, if I understood your right, should be similar to your profile idea. But you can assign arbitrary tags to a tool. These tags can be filtered by a default enabled filter and as bonus they can also be searched. Sometimes I feel like the search could be better.
Yes, tags is a better word for what I was attempting to describe than profiles.
I understand that the tool shed complicates things, but somehow, somewhere the section of the tool is getting stored (perhaps in shed_tools.xml or maybe in the database) across deletions of intergrated_tool_panel.xml. A similar mechanism could be used to interface and store tags for tools and sections. Ultimately, I assume it would all land up in integrated_tool_panel.xml in a consistent way and it would be comparable to having edited the XML manually. Though I understand that this would take some time to implement - that is why I had said your implementation is definitely easier for the Galaxy team to maintain :).
Ultimately, I was just interested in clarifying the use case. This is cool stuff and I hope it gets merged.
Maybe we can talk a little bit at GCC about that.
@natefoo @guerler is it worth to update that pull request now, or should I wait for initial comments.
This came up in passing in a conversation at the GCC and there was some push back (I think from @natefoo) about the database performance. Hopefully he can clarify (though he is swamped with the TACC transition).
To address this concern, can you answer the following questions:
- Are you running this in production and if so at what scale?
- Do you think it could be reworked to to only load user.preferences from the database if filters are actually potentially enabled (so this wouldn't affect main negatively where no filters at all are specified)?
I don't remember the specific conversation, but I think the only comments I made about this topic were related to tool tagging that I and some others created at an NBIC hackathon a few years ago. That implementation does some crude things at server startup and would need to be enhanced to be used. But I don't think it related to this pull request.
@natefoo Didn't mean to throw you under the bus. But I am very sorry, it was a loud room and I misunderstood your comments.
@jmchilton Not at all, I have a terrible memory and it's entirely possible that I said something completely different than what I just typed above.
We do not run it in production, sorry. I can test it further if we you want and also can try to avoid that db call, not sure if its possible, but I guess so. Is it needed to get it accepted? It would be really nice for me to have one Galaxy instance with CTB and GalaxyP and give the user the ability to switch the default tools.
I am a firm believer in not optimizing before there is a known problem, so I wouldn't rewrite anything necessarily. I also think this is important functionality which should be added. Let me think about it some more and get back to you.
Let's just get it merged and included (optional); it's obvious that folks want this. If it has performance issues in certain environments, we'll find them fast enough and work around it.