rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Franklin, Matthew B." <mfrank...@mitre.org>
Subject RE: Self-service application administration...
Date Tue, 04 Oct 2011 11:58:38 GMT
>-----Original Message-----
>From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>Sent: Tuesday, October 04, 2011 5:21 AM
>To: rave-dev@incubator.apache.org
>Subject: Re: Self-service application administration...
>
>On 27 September 2011 14:33, Franklin, Matthew B.
><mfranklin@mitre.org>wrote:
>
>> >-----Original Message-----
>> >From: Jasha Joachimsthal [mailto:j.joachimsthal@onehippo.com]
>> >Sent: Tuesday, September 27, 2011 7:39 AM
>> >To: rave-dev@incubator.apache.org
>> >Subject: Re: Self-service application administration...
>> >
>> >On 27 September 2011 13:26, Franklin, Matthew B.
>> ><mfranklin@mitre.org>wrote:
>> >
>> >> >-----Original Message-----
>> >> >From: Scott Wilson [mailto:scott.bradley.wilson@gmail.com]
>> >> >Sent: Tuesday, September 27, 2011 4:49 AM
>> >> >To: rave-dev@incubator.apache.org
>> >> >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

Mime
View raw message