ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
Make it possible to filter the upper-right Projects menu (Feature #1180)
Description
One minor annoyance I encounter on a daily basis, as a heavy ChiliProject user, is the Projects menu in the upper right. Our configuration at work is relatively large and growing weekly. Because we use ChiliProject as a support helpdesk system as well as our project management tool, we've amassed a large number of projects. This coupled with the fact that most of our development team is a member of almost all of these projects renders this menu difficult to use for effective navigation; there are just too many items in the list for us to find the ones we need.
To solve the problem, I'd like to propose adding a text box to the top of this .drop-down menu which would allow users to filter the list of projects presented to them. By default, we'd assume the current behaviour of displaying all entries. As the user types, we'd do a "fuzzy" search on the project name and remove any non-matching entries. When the field is cleared, we'd mark all of the projects in the list visible again.
I've begun work on this on a branch of my fork. As stated in the commit message on GitHub, it's merely a seed of the envisioned implementation:
- Searching is case sensitive and very primitive; it'll only match a single substring within the project name. Ideally, I believe it should be a "fuzzy" match.
- To ensure optimal performance I've hackily added some classes to the drop down menu with JS. I plan on moving this into the views/helpers involved in generating the menu.
- I've only tested in WebKit, so it probably won't work too well in other browsers.
Feedback is welcome -- is anybody else interested in this feature?
Associated revisions
Fixed: Check All / Uncheck All in Email Settings doesn't work (#1180).
git-svn-id: http://redmine.rubyforge.org/svn/trunk@1429 e93f8b46-1217-0410-a6f0-8f06a7374b81
History
Updated by Felix Schäfer at 2012-12-09 04:26 pm
Luke, we've been looking at improving many of the fields used to select an element or elements out of a possibly big set (the projects menu, picking watchers, choosing members, …) by enhancing them with something like chosen or select2. I think Andrew might even have started some work on that.
The bigger problem here is the licenses which are not always compatible with the "GPLv2 or later" ChiliProject currently is under. We're looking into how to fix this in #1105 though.
Updated by Luke Carrier at 2013-01-05 12:26 pm
Hi Felix,
Apologies for not following up sooner, I took advantage of the Christmas break this year for some much needed relaxation!
Would Impromptu 's dual licencing (under the MIT and GPL licences) be appropriate? The GPL licence file on his website is version 2.
If so, I'm happy to adapt my code and set about implementing it across all of ChiliProject?
Updated by Felix Schäfer at 2013-01-05 12:59 pm
Luke Carrier wrote:
Apologies for not following up sooner, I took advantage of the Christmas break this year for some much needed relaxation!
No problems, we too had other things to take care of in the last few months :-)
Would Impromptu 's dual licencing (under the MIT and GPL licences) be appropriate? The GPL licence file on his website is version 2.
If so, I'm happy to adapt my code and set about implementing it across all of ChiliProject?
I think we'd be happy with Select2 for example, and we're planning on changing the license as stated in #1105. Until we have officially changed the license, I think you can start working nonetheless as long as the what you do is marked as being for "your own consumption", the incompatibility between the licenses is only a problem once you want to release/distribute it.
I've had a quick look at impromptu nonetheless, but I don't think it fits our use-case as well as Select 2 remote data loading for example http://ivaynberg.github.com/select2/#data
Updated by Luke Carrier at 2013-01-05 08:16 pm
Felix Schäfer wrote:
I think we'd be happy with Select2 for example, and we're planning on changing the license as stated in #1105. Until we have officially changed the license, I think you can start working nonetheless as long as the what you do is marked as being for "your own consumption", the incompatibility between the licenses is only a problem once you want to release/distribute it.
Since changing the licence is already planned, I'll gladly proceed with Select2!
The only ticket I found that contained references to Select2 was #1060. Would you like to mark this a duplicate or follow up here? I'll keep all work to my fork on GitHub and am happy to post with progress as time permits.
Updated by Luke Carrier at 2013-01-13 05:07 pm
Okay, I've begun work on an implementation of this feature on a fresh branch. For the most part, the changes made there seem to be working well, but I'm finding that some of the more dynamic pages are a little trickier to get right. A good example is the repository settings page within a project; once selecting a value for the SCM field and the content of the page is updated, we'll need to call jQuery(elem).select2() again.
I'll likely rebase that feature branch periodically, I tend to commit frequently as I work and squash later.