On 27 September 2011 13:26, Franklin, Matthew B. <[email protected]>wrote:
> >-----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 > +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. > It should be possible to create administrative widgets but then we are facing multiple challenges at the same time. First create "regular" administration pages so we have the basic functionality. Then we can modify the views to let them also render in an iframe gadget. Eventually we can copy or move the administration pages to inline gadgets. > > > > >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. > At the moment User#getAuthorities returns null (RAVE-232). Now how do we decide the role of a User within the portal? We can use the groups for that and assign portal privileges to members of a certain group. That may require to merge User and Person. Any opinions? > > >> > >> I have added the mockups to epic: > >> <https://issues.apache.org/jira/browse/RAVE-9> > Nice :) Jasha
