>-----Original Message----- >From: Scott Wilson [mailto:[email protected]] >Sent: Tuesday, September 27, 2011 4:49 AM >To: [email protected] >Subject: Re: Self-service application administration... > >On 27 Sep 2011, at 08:40, Paul van Dijk wrote: > >> Hi all, >> >> Please let me introduce myself. My name is Paul van Dijk product >> manager at SURFnet. In the months to come we would like to put some >> more effort in our co-development of Rave. >> >> One of the first topics we would like to cover is the development of >> an admin interface. Attached you will find a number of mockups of >> functionality we would like to include. >> >> I am curious if these ideas fit with yours (?) > > >I think this is a great starting point for the admin interface.
+1 >Certainly using tabs makes sense for organising the screens as we can then add >more tabs for >configuring extensions - I guess the only question there is how many tabs >could be supported. > >(An alternative would be the Wordpress style of admin interface using >expanding left-hand menus, but that would require more development, >whereas the tabbed interface is already implemented in Rave.) > >Would it also make sense for the admin features themselves to be developed >as widgets, connecting to the Rave REST API to perform their functions? This >would then make the admin interface easily customisable like any other portal >page. Interesting idea. I think making them widgets adds some new challenges, but it is obviously possible. The benefit is that administrators could have the option of adding them to their own portal pages. This would be especially useful for monitoring & statistics widgets. The only concern I have is that it overcomplicates the administration of Rave. Specifically, if we made admin functions widgets, you MUST have whatever widget provider installed that the widgets are built on. So if they were W3C widgets, the Rave instance must have Wookie running in order to render the admin interface. At the moment, there is nothing forcing any particular widget provider to be installed in the environment. > >We could also re-use some of the admin widgets for limited admin functions >available to most portal users - e.g. editing their own profile, viewing their >own groups, viewing stats for their own pages. > >> >> One of the things we initially need to address is how to provide >> administrator access to the admin interface in a safe way. There are some tickets in JIRA for adding Role-based security. This is pretty simple w/ Spring Security and would allow us to designate users as administrators and only allow access to the admin interface if they are administrators. Of course, this assumes we don't use the widget based model. If we went with widget-based, we could use the widget audience feature to restrict who can add widgets and use the security annotations on service methods to determine if someone has the correct permissions. >> >> I have added the mockups to epic: >> <https://issues.apache.org/jira/browse/RAVE-9> >> >> Best regards, >> >> Paul >> SURFnet >> >> >> >>
