On 27 September 2011 14:33, Franklin, Matthew B. <[email protected]>wrote:
> >-----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 > One table to define the roles (user, admin, ...) and one table to link a user to the roles? Should we store User in the Person in the same table? See http://openjpa.apache.org/builds/1.0.2/apache-openjpa-1.0.2/docs/manual/jpa_overview_mapping_inher.htmlfor inheritance Jasha
