[#1] - Sorting and Filtering options
- Closed
- 9 Nov 2013
- Medium
- Build: master
- # 1
First of all: Congrats for starting this baby.
OK, so here comes the first issue. I would like to point this out es early as possible because I feel it's quite important.
One of the things a tracker needs very badly is the ability of sorting and filtering - extensive..
Example: I need to filter the issues of a given priority and a given status and whatever.
I don't think the approach with a single select for filtering will work here (nor in the CMS..)
So i believe in the Magento approach - which is putting the filter fields inside the headers of the table columns. Works pretty well for extensive filtering in extensive tables..
Now let me repeat my congrats, installation and retrieval of the issues from github worked good after figuring out how to set it up ;) I am forking this thingy right now and hope to contribute some code in the future.
hF,
Nikolai
@elkuku : this kind of filter could make you happy
http://www.redmine.org/projects/redmine/issues
It allow us to build custom filter rule and save it for later use, for example: My closed issues or My pending issues etc
I've just pushed a "Quick Filter" to my template branch, the idea is to have 2 types of filter:
Quick Filter: allows user to select issues based on some predefined queries
Advanced Filter: allows user to build their own queries
I'm honestly mildly tempted to merge the template branch onto master and go forward with this base for the filtering (just looking at the code, it looks promising, but I haven't pulled in the branch to test it yet). Between the filter work and the fact the template is a lot closer to what the product used on the j.org sites will be, makes it worth it to me.
After pulling in the branch, I like where those quick filters are going. The one thing that needs to change (IMO) is that you should be able to enable multiple filters at once (right now, if you click one, it resets the other filters). Otherwise, it's looking pretty good.
This looks pretty good :)
Do we want personal filters in v1.0 or just generic filters? These personal filters will take time to implement.
Let's just get the generic filters in place first. It's annoying at most to have to reset my filters each time I log in, but at least the filtering capability is there.
Ok will look into it :)
Talking about personal ones - how to remember them? Cookies or some setting in the profile?
Hmm... That's actually a good question.
So on Joomlacode, you can have saved filters and typically the last filter
you applied remains what is active for that tracker. Which does mean you
can have different settings per tracker. So my initial thought is the
personal queries and state data get stored with the user.
On Saturday, November 2, 2013, Dmitry Rekun wrote:
Ok will look into it :)
Talking about personal ones - how to remember them? Cookies or some
setting in the profile?—
Reply to this email directly or view it on GitHub#1 (comment)
.
Can I ask - what do you mean by personal queries? Can you explaine more, I do not totally understand this :(
There's queries individuals can save that are specific to their account on
Joomlacode. Then there's queries that can be saved that everyone can use
(basically a predefined set of filters).
On Saturday, November 2, 2013, Dmitry Rekun wrote:
Can I ask - what do you mean by personal queries? Can you explaine more, I
do not totally understand this :(—
Reply to this email directly or view it on GitHub#1 (comment)
.
So basically we can store that info in let's say users_filters table in some form of JSON format like {status:open, priority: 3} ?
That should work.
Agree with this. I'd say personal filters are a cool, "would like to have"
feature that probably only power users use. Frankly, I had no idea
Joomlacode could so that.
That said, they'd be an awesome feature. Maybe as a future enhancement?
Best,
Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain
Sent from mobile. Please excuse any typos and brevity.
On Nov 2, 2013 2:02 PM, "Michael Babker" notifications@github.com wrote:
Let's just get the generic filters in place first. It's annoying at most
to have to reset my filters each time I log in, but at least the filtering
capability is there.—
Reply to this email directly or view it on GitHub#1 (comment)
.
Personal filters are definitely something for the future. For now, we just need to get the basic filtering in place that way folks can quickly filter on the different columns (shouldn't need anything fancier than the admin filters in most CMS components).
Ok I got it ;) So I am starting to implement basic ones.
Just have pushed 59c0721 to the filtering branch. What do you think about the approach? Basically that's a start of using reusable html elements (currently form fields) across the project.
BTW use of search filter leads to Call to undefined function Joomla\String\jimport() :) Need to update our vendors ;)
And one more thing. This was taken from here. It's under GPL, but do we need to left reference to the author somehow?
I'd say go ahead and make a CREDITS file or something where we can list all third party inspirations.
And I'll update the upstreams at some point today. In the middle of killing my system resources running a Windows VM to redo the SQL Server sample data for the CMS.
Well, that's one way to clear the issue tracker 
:) The priority select is too long of an inputbox for having single digit numbers. It's taking up way too much space, should be inputbox-small or even mini.
We could have label filtering. Honestly, it'd be good to just look at the GitHub filters and do what they do.
Additionally, if we have open status selected then the table should not have a "closed" column showing.
Additionally, if we have open status selected then the table should not have a "closed" column showing.
Agree.
I found a bug - pagination resets the filters... Need to investigate, but tomorrow :) It's midnight in Rīga and I am going to sleep :) Feel free to update filtering branch ;)
OK thinking back about storing a personal filters silently I just realized that it could lead to heavy load on the DB if we will store them every time a user change these filters' state. So I currently see to options here:
- Store/update them in the user's session and update DB after session will expire.
- Make an option (i.e. some button) which will allow to store/update current filters' set/state. Potentially the user could have different sets under some personal name.
What do you think?
So basic filtering is in place now. I also temporarily removed String usage to test filter. May be we can leave it removed? Does utf8_strtolower and strtolower produce different results?
I think we can use String now ? Not sure if we really have to....
The method in String uses a library which is supposed to have better UTF-8 support, I think that's the only difference.
The method in String uses a library which is supposed to have better UTF-8 support, I think that's the only difference.
Yeap, it's only a wrapper to utf8_strtolower. Googled a little bit, seems that we should left the String usage.
-
I'm all for any ideas that make things better. Just to get basic things working, I started borrowing code out of the CMS that I know already works. So, mostly proof of concept right now, but helps validate the model code too.
Looking forward to seeing what you come up with.