rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jasha Joachimsthal <j.joachimst...@onehippo.com>
Subject Re: Self-service application administration...
Date Tue, 04 Oct 2011 09:20:33 GMT
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

Jasha

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message