>-----Original Message----- >From: Jasha Joachimsthal [mailto:[email protected]] >Sent: Tuesday, October 04, 2011 5:21 AM >To: [email protected] >Subject: Re: Self-service application administration... > >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
+1. Can't hurt to have one less join. > >Jasha
