GUI: expand and flip group repositories

[gitblit]

Originally reported on Google Code with ID 231

What steps will reproduce the problem?
1. Have multiple repository which are grouped
2. All repositories and repository groups are rendered in one table
3. When showing huge amounts of repositories the table gets confusing.

What is the expected output? What do you see instead?
I would like to have the possibility to flip and expand the grouped repositories (table
rows). It would be nice to have a application property to set a default value for the
grouped view (expanded / flipped).

What version of the product are you using? On what operating system?
v1.2.1 GitBlit WAR on Apache Tomcat 7 on Debian 4.6

Please provide any additional information below.
see the screenshots:
current_view.png -> this is the current dashboard view with grouped repositories
new_view.png -> this is a possible resolution for the requirement; using [+] and [-]
in front of the group name to switch between expanded and flipped in view.

link:
howto for flipping table rows: http://snippets.fiae.ws/show/11/

Reported by stephan.krull.ecg on 2013-04-15 09:20:51

---

• Attachment: current_view.png
  
• Attachment: new_view.png
  

[gitblit]

Obviously this issue is an enhancement ticket rather than a defect. I havn't been able
to configure this.

Reported by stephan.krull.ecg on 2013-04-15 09:28:38

[gitblit]

I agree, that would be convenient.

It would take some re-architecting to implement but shouldn't be too difficult.  I'll
put it on the wishlist for 1.3.0.

Reported by James.Moger on 2013-04-15 13:15:34

• Labels added: Milestone-1.3.0

[gitblit]

Reported by James.Moger on 2013-07-03 14:27:45

• Labels removed: Milestone-1.3.0

[gitblit]

Hi, I've started implementing this feature. I now have the groups toggling, my work-in-progress
can be found here...

https://github.com/alexmob/gitblit/commits/issue-231-dev

I've tackled this with the minimum amount of change as I didn't want to tackle the
"re-architecting" :) So it might not be the correct way to do this but hopefully it's
a step in the right direction.

Questions are:
  * Is what I'm doing ok or should this be done via the re-architecting?
  * Is the "+/-" the desired way to visualise a collapsed/expanded group or is there
another preferred approach?

My WIP doesn't have a default collapsed/expanded configuration item yet either.

Reported by alex.lewis001 on 2013-12-04 14:08:34

[gitblit]

Hi. Just to add an update, I've now got the repository/description/owner/etc. banner
toggling all repository groups. 

I've still not implemented a configuration item; however, I did have some thoughts
on what the configuration would be...

# Specify the behaviour of the Repository groups on the "Repositories"
# page, specifically whether they can be collapsed and expanded, and
# their default state on loading the page.
#
# Values (case-insensitive): 
#   disabled - Repository groups cannot collapsed; maintains behaviour
#              from previous versions of GitBlit.
#   expanded - On loading the page all repository groups are expanded.
#   collapsed - On loading the page all repository groups are collapsed.
#
web.collapsibleRepositoryGroups = disabled

Reported by alex.lewis001 on 2013-12-11 08:52:11

[gitblit]

I've now got the default load behaviour implemented, I.e. when the page is loaded, depending
on configuration, all the groups are collapsed or expanded.

So all that's left is what the visual cue should be (if any) that a group can be collapsed/expanded.

James, if possible please could you take a look at my branch to see if what I've done
is reasonable so far? If you have any comments please let me know.

Reported by alex.lewis001 on 2013-12-23 14:28:27

[gitblit]

This is looking good.  Things todo before opening a pull request...

1. Expand/collapse is not working with user repositories, possibly because of ~ prefix
2. Visual cue.
3. Squash & rebase.

Sometime late this week I will merge in some commits from my tickets branch - one of
which is adding FontAwesome which offers a ton of great font icons, one of which we
can use for a visual cue.

Squash & Rebase.  I get nervous when merging a pull request that itself has multiple
merges with master.  It's better for a pull request to be a linear progression of commits
(or even just one commit - if the feature is small like this one) in development of
the feature.  Merge commits cloud that.  GitHub allows you to rebase pull requests
- which is very convenient for when you want to pre-merge or build on the latest upstream
master.

Reported by James.Moger on 2013-12-23 16:21:22

[gitblit]

Thanks James! 

1. Ok I'll look into that now.
2. I'll wait for your input on what you want the visual cues to look like when you're
ready.
3. Yes most definitely. I did it this way this time as I wanted to make my work-in-progress
(I tend to put "-dev" on the end of the branch name) publically visible and wanted
to avoid rebasing those public commits. My intention was to create a new branch from
issue-231-dev (I.e. issue-231) once the feature was ready, interactive rebase it into
a sensible history (in this case a single commit) and raise the PR from issue-231.
Does that sound ok or is that going to cause problems? 

Thanks again for getting back to me James.

Cheers,
Alex

Reported by alex.lewis001 on 2013-12-23 16:35:53

[gitblit]

Perfect.

Reported by James.Moger on 2013-12-23 16:37:17

[gitblit]

Ok I've fixed the problem with the user repositories not folding, you were right, it
was because of the tilde. 

I've opted to generate an ID instead of using the group names. That way I didn't have
to worry about substituting invalid characters, ensuring the resulting substituted
value was still unique, etc. 

I've pushed this change to my branch.

Reported by alex.lewis001 on 2013-12-24 11:16:31

[gitblit]

Hello Alex, James,

I didn't expect implementation of that request; it's a lucky surprise after the christmas
/ new year break for me.

Thank you for the commitment. I have one question: When repository groups are collapsed
is it still possible to find a repository in that group (via browser search function)?


Because in GitBlit 1.3.1/2 to find a repository one is mostly using the repository
view and searches a key word. if, after implementing the collapsing groups, a user
is not able to search for a repository name then he is forced to uncollapse all repo
groups until he finds the repo in question -> not a good solution.

Reported by stephan.krull.ecg on 2014-01-02 15:57:08