>-----Original Message----- >From: Jasha Joachimsthal [mailto:[email protected]] >Sent: Tuesday, September 27, 2011 7:39 AM >To: [email protected] >Subject: Re: Self-service application administration... > >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?
We are going to have to add a role table and return the authorities correctly populated. Rather than merge user & person, I would say have User extend person > > >> >> >> >> >> I have added the mockups to epic: >> >> <https://issues.apache.org/jira/browse/RAVE-9> >> > >Nice :) > >Jasha
