Self-service application administration...

[Paul van Dijk <pa...@surfnet.nl>]

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 (?)

One of the things we initially need to address is how to provide
administrator access to the admin interface in a safe way.

I have added the mockups to epic:
<https://issues.apache.org/jira/browse/RAVE-9>

Best regards,

Paul
SURFnet

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

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, 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

>
>
>>
>> >>
>> >> I have added the mockups to epic:
>> >> <https://issues.apache.org/jira/browse/RAVE-9>
>>
>
>Nice :)
>
>Jasha

Re: Self-service application administration...

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

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?


>
> >>
> >> I have added the mockups to epic:
> >> <https://issues.apache.org/jira/browse/RAVE-9>
>

Nice :)

Jasha

RE: Self-service application administration...

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

>-----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

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

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

>>
>> I have added the mockups to epic:
>> <https://issues.apache.org/jira/browse/RAVE-9>
>>
>> Best regards,
>>
>> Paul
>> SURFnet
>>
>>
>>
>>

Re: Self-service application administration...

[Scott Wilson <sc...@gmail.com>]

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

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.
> 
> I have added the mockups to epic:
> <https://issues.apache.org/jira/browse/RAVE-9>
> 
> Best regards,
> 
> Paul
> SURFnet
> 
> 
> 
>