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.
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 email@example.com).
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>firstname.lastname@example.org</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 Group.java, XmlGroupManager.java, XmlGroupDatabase.java, and an AbstractGroupManager.java. This is where I seem to be missing something. It seems that you bind everything together with the ScmServletModule.java, and it that somewhere in the lifecycle everything is picked up by JAXBStore.java (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.