Custom and Global Filtered Views

Issue #72 resolved
Chuck Rolek
created an issue

Sebastian and everyone else,

The current issue my users and I are running into is the amount of repositories we see when we log in. As an admin/owner of all the repositories I see every single one of them when I log in. Some of my users are seeing pages of repositories when they log in and that's only the repositories that they have access to. My long-term goal is that individual users could create their own “Custom Filtered Views” (as I’ve been calling it), so when they log in they can switch to that view and only see what they want.

Design Discussion:

Global Filtered Views vs Custom Filtered Views

My initial attempt at this is to create a set of hard-coded Global Filtered Views that no one could change unless they had access to the xml file on the server (me or another admin). (These could later be edited by an appropriate configuration tab/panel inside SCM-Manager, but right now I’m trying to keep it simple.) These views would be something simple like the letters of the alphabet, and when you clicked on one (letter B for example) you’d only see repositories that start with the letter B (upper and lower cased Bs). These views would be the default views that every single user has access to.

My end-game hopes are that users would have access to a Create Filtered Views tab or Z-Index based popup/overlay (just like your Change Password overlay if you’re logged in as an XML based user). With this page they would have a slew of options to create a Custom Filtered View. Some options could be a view based off REGEX, pick/choose the repositories they want from a list, select groups of repositories based off contact/description-phrase/repository-type, or even “complex” views where more than one condition is evaluated (All repositories that start with B and have a contact of

Should the Filtered Views be listed on the default Repositories tab? If no, should the Filtered Views tab pop up on start up like the Repositories tab? If yes or no, should the user be allowed to specify a default view that the page/pages would open up to instead of showing all repositories.

Storage of the Filtered Views. I think for organization purposes the views should probably be stored in their own file. I hacked together a very simple and crude example of how I might put in a Global Filtered View.



<global-views> <creationTime>1319662711599</creationTime> <lastModified>1319663648958</lastModified> <views> <view> <label>A</label> <restriction> <name>A</name> </restriction> </view> <view> <label>H</label> <restriction> <name>H</name> </restriction> </view> <view> <label>Test</label> <restriction> <email></email> </restriction> </view> </views> </global-views>

}}} 6. I’ve been debating on a proper way to store user’s individual Custom Filtered Views. The only reason I haven’t finalized my xml is because (and I don’t know if this is a bug that I should report), but if a user logs in with their AD credentials it will create one account for if they are using upper case and another for lower case. That would mean that every user would potentially have to create their views twice if we stored their settings based off their user name. I don’t know which is the best solution. We could bind user names together with something like an UUID (that would have to be done somehow by the user/admin), or to fix what could potentially be the bug that is causing this issue.

I’ve been digging through this part of your project for a few days now, and I must say it’s rather impressive. However, I think I might be missing something important to help me complete even the Global Filtered Views section of this.

What I know/What I need help with:

I think the Filtered Views could be piggy-backed ontop of the filterStore function in Sonia.repository.grid.js, but a little bit of re-coding might be needed to accept the filter based on contact.

I’ve been able to replicate the Repositories panel and adjust it to what I want (IE, I kind of have the Sencha part figured out).

One part I haven’t completely figured out is when in the start-up lifecycle you are taking the .xml files and turning them into objects. From what I’ve currently gathered is that each item (take Groups for example) will have a,,, and an This is where I seem to be missing something. It seems that you bind everything together with the, and it that somewhere in the lifecycle everything is picked up by (which my current guess is where the conversion seems to be happening). Currently I’m having difficulties trying to get my file views.xml to be picked up and transformed into an object.

Since I’m having difficulties trying to find out where my xml is being transformed into object; I haven’t been able to figure out the handshaking point between Java and Sencha.

Any input you can provide to help me move forward on this would be greatly appreciated. My personal concern is that even if I complete this (and get approval to submit it to you) I’ll have done it in a manner that would require a lot of re-work for you to accept it. If you feel this would be worth your time to work on and add to SCM-Manager please feel free to. I will be attempting this until I get pulled off of this project and put on another.



Comments (5)

  1. Sebastian Sebastian repo owner

    Hi Haster, Please check #47. It brings a repository structure to SCM-Manager, this can make the repository overview lot clearer. I think it would be a better solution to put this functions in a plugin, because i want to keep the ui as simple as possible. With a plugin every admin can decide to use the function or not.

    First section:

    6. This sounds like a bug, i will test it.

    Second section:

    3 and 4. Short explanation of the data store and transport mechanism in SCM-Manager:

    public class View {
      /** getter and setter **/
      private String label;
    public class GlobalView {
      /** getter and setter **/
      @XmlElementWrapper(name = "views")
      private List<View> views;
      private long creationTime;
      private long lastModified;
    public class GlobalViewResource {
      private Store<GlobalView> viewStore;
      public GlobalViewResource( StoreFactory storeFactory ){
        this.viewStore = storeFactory.getStore(GlobalView.class, "global-views");
      public GlobalView getGlobalView(){
        return viewStore.get();

    The example above creates a restful webservice endpoint at /contextpath/api/rest/views/global.(xml|json) (f.e. /scm/api/rest/views/global.json). The webservice can be called with a get request. The service reads the content of the file config/global-views.xml and transforms it in a GlobalView object, than transforms the service the GlobalView object in an xml or json result and send it back to the user. The xml output should look like your example.

    I hope this helps.

  2. Chuck Rolek reporter


    I'm going to be putting issue 47 on my test server and see how it works out. I don't think it'll be a complete fix for the view system I was describing above, but I don't think it'll hurt anything.

    You'll clearly know your program a lot more than I will, but can all of this be achieved through a plugin?

    First Section

    If you want me to test a bug solution I can give it a try on our test server. Just an FYI, our main server is running the 1.7 release of SCM.

    Section Two

    Thank you for taking a moment to explain that. I think I was actually able to pick up a few parts of what I was missing.

    Thanks Again,


  3. Sebastian Sebastian repo owner

    Yes this should all work as a plugin. If you create a public repository (on bitbucket, github, ...) for the plugin, i could help you. If you like i can create the basic structure of the plugin for you.

  4. Log in to comment