Re: Self-service application administration...

[Jasha Joachimsthal <j....@onehippo.com>]

On 27 September 2011 14:33, Franklin, Matthew B. <mf...@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.
> ><mf...@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

RE: Self-service application administration...

["Franklin, Matthew B." <mf...@mitre.org>]

>-----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.
><mf...@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.
>> ><mf...@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