You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Sean Cooper <se...@apache.org> on 2012/05/30 16:10:48 UTC
Team Pages
Is anyone currently working on team pages, or working on defining a
structure for it?
I'd like to take a crack at defining it this week, but I don't want to
interrupt anyone that might already be working on the problem.
-Sean
Re: Team Pages
Posted by Jasha Joachimsthal <ja...@apache.org>.
On 30 May 2012 16:35, Sean Cooper <se...@gmail.com> wrote:
> On Wed, May 30, 2012 at 10:25 AM, Jasha Joachimsthal <ja...@apache.org>
> wrote:
> > On 30 May 2012 16:10, Sean Cooper <se...@apache.org> wrote:
> >
> >> Is anyone currently working on team pages, or working on defining a
> >> structure for it?
> >>
> >> I'd like to take a crack at defining it this week, but I don't want to
> >> interrupt anyone that might already be working on the problem.
> >>
> >> -Sean
> >>
> >
> > I am planning to work on it, but it's not clear yet when. So if you want
> to
> > start, go ahead :) What I need is a concept of a page that is shared
> with a
> > group of users, but the users cannot edit the page, only the
> administrator
> > of the page. See also [1]
>
> I was looking through the code and saw what appears to be some
> additions into the main page controller for share pages... but that
> doesn't fully cover my use case. - same as yours but shared with
> everyone, not just a group of users.
>
> I think we should have a separate controller for these pages to keep
> the page controller as simple as possible. In my use cases I'm going
> to have a few hundred pages that everyone can read but only the
> administrator(s) will have access to update.
>
> I think we can recycle the methodology for sharing a page with a group
> of people that is used in the shared page model, but I'm going to have
> to add a flag for world-read-only instead of supplying a group for
> read access. If we build in the support for world-read-only then this
> would also cover the idea of public pages.
>
In my case I don't need a "world-read-only", but at most an
"any-authenticated-user-read-only", but probably more
"all-students-read-only". The first would also need an exception in the
Spring security configuration.
I like the idea of separating it from the existing page controller to keep
it readable and modular.
>
>
> >
> > [1] http://markmail.org/thread/5dfecb5gk7qynqdc
> >
> > Jasha
>
Re: Team Pages
Posted by Sean Cooper <se...@apache.org>.
On Wed, May 30, 2012 at 10:43 AM, Scott Wilson
<sc...@gmail.com> wrote:
> On 30 May 2012, at 15:35, Sean Cooper wrote:
>
>> On Wed, May 30, 2012 at 10:25 AM, Jasha Joachimsthal <ja...@apache.org> wrote:
>>> On 30 May 2012 16:10, Sean Cooper <se...@apache.org> wrote:
>>>
>>>> Is anyone currently working on team pages, or working on defining a
>>>> structure for it?
>>>>
>>>> I'd like to take a crack at defining it this week, but I don't want to
>>>> interrupt anyone that might already be working on the problem.
>>>>
>>>> -Sean
>>>>
>>>
>>> I am planning to work on it, but it's not clear yet when. So if you want to
>>> start, go ahead :) What I need is a concept of a page that is shared with a
>>> group of users, but the users cannot edit the page, only the administrator
>>> of the page. See also [1]
>>
>> I was looking through the code and saw what appears to be some
>> additions into the main page controller for share pages... but that
>> doesn't fully cover my use case. - same as yours but shared with
>> everyone, not just a group of users.
>>
>> I think we should have a separate controller for these pages to keep
>> the page controller as simple as possible. In my use cases I'm going
>> to have a few hundred pages that everyone can read but only the
>> administrator(s) will have access to update.
>>
>> I think we can recycle the methodology for sharing a page with a group
>> of people that is used in the shared page model, but I'm going to have
>> to add a flag for world-read-only instead of supplying a group for
>> read access. If we build in the support for world-read-only then this
>> would also cover the idea of public pages.
>
> Could "everyone" be a kind of magic group?
That's why I was thinking of using a flag.. I don't think we have
'groups' defined really... it is more like a giant list of people who
have been granted access to the page. If we want to add the concept
of groups in then we need to add in a way to do group management and
specify groups for access it the UI.
>
>>
>>
>>>
>>> [1] http://markmail.org/thread/5dfecb5gk7qynqdc
>>>
>>> Jasha
>
Re: Team Pages
Posted by Scott Wilson <sc...@gmail.com>.
On 30 May 2012, at 15:35, Sean Cooper wrote:
> On Wed, May 30, 2012 at 10:25 AM, Jasha Joachimsthal <ja...@apache.org> wrote:
>> On 30 May 2012 16:10, Sean Cooper <se...@apache.org> wrote:
>>
>>> Is anyone currently working on team pages, or working on defining a
>>> structure for it?
>>>
>>> I'd like to take a crack at defining it this week, but I don't want to
>>> interrupt anyone that might already be working on the problem.
>>>
>>> -Sean
>>>
>>
>> I am planning to work on it, but it's not clear yet when. So if you want to
>> start, go ahead :) What I need is a concept of a page that is shared with a
>> group of users, but the users cannot edit the page, only the administrator
>> of the page. See also [1]
>
> I was looking through the code and saw what appears to be some
> additions into the main page controller for share pages... but that
> doesn't fully cover my use case. - same as yours but shared with
> everyone, not just a group of users.
>
> I think we should have a separate controller for these pages to keep
> the page controller as simple as possible. In my use cases I'm going
> to have a few hundred pages that everyone can read but only the
> administrator(s) will have access to update.
>
> I think we can recycle the methodology for sharing a page with a group
> of people that is used in the shared page model, but I'm going to have
> to add a flag for world-read-only instead of supplying a group for
> read access. If we build in the support for world-read-only then this
> would also cover the idea of public pages.
Could "everyone" be a kind of magic group?
>
>
>>
>> [1] http://markmail.org/thread/5dfecb5gk7qynqdc
>>
>> Jasha
Re: Team Pages
Posted by Sean Cooper <se...@gmail.com>.
On Wed, May 30, 2012 at 10:25 AM, Jasha Joachimsthal <ja...@apache.org> wrote:
> On 30 May 2012 16:10, Sean Cooper <se...@apache.org> wrote:
>
>> Is anyone currently working on team pages, or working on defining a
>> structure for it?
>>
>> I'd like to take a crack at defining it this week, but I don't want to
>> interrupt anyone that might already be working on the problem.
>>
>> -Sean
>>
>
> I am planning to work on it, but it's not clear yet when. So if you want to
> start, go ahead :) What I need is a concept of a page that is shared with a
> group of users, but the users cannot edit the page, only the administrator
> of the page. See also [1]
I was looking through the code and saw what appears to be some
additions into the main page controller for share pages... but that
doesn't fully cover my use case. - same as yours but shared with
everyone, not just a group of users.
I think we should have a separate controller for these pages to keep
the page controller as simple as possible. In my use cases I'm going
to have a few hundred pages that everyone can read but only the
administrator(s) will have access to update.
I think we can recycle the methodology for sharing a page with a group
of people that is used in the shared page model, but I'm going to have
to add a flag for world-read-only instead of supplying a group for
read access. If we build in the support for world-read-only then this
would also cover the idea of public pages.
>
> [1] http://markmail.org/thread/5dfecb5gk7qynqdc
>
> Jasha
Re: Team Pages
Posted by Ate Douma <at...@douma.nu>.
On 05/30/2012 11:10 PM, Jasha Joachimsthal wrote:
> On 30 May 2012 22:16, Sean Cooper<se...@apache.org> wrote:
>
>> On Wed, May 30, 2012 at 2:41 PM, Paul Sharples<p....@bolton.ac.uk>
>> wrote:
>>> On 30/05/2012 19:18, Jasha Joachimsthal wrote:
>>>>
>>>> On 30 May 2012 19:11, Paul Sharples<p....@bolton.ac.uk> wrote:
>>>>
>>>>> On 30/05/2012 16:52, Jasha Joachimsthal wrote:
>>>>>
>>>>>> On 30 May 2012 17:44, Paul
>>>>>> Sharples<p....@bolton.ac.uk>>
>>>>>> wrote:
>>>>>>
>>>>>> On 30/05/2012 16:08, Franklin, Matthew B. wrote:
>>>>>>>
>>>>>>> Content preview:>
>>>>>>>>
>>>>>>>> Content analysis details: (-10.0 points, 5.0 required)
>>>>>>>>
>>>>>>>> pts rule name description
>>>>>>>> ---- ---------------------- ------------------------------****
>>>>>>>>
>>>>>>>> --------------------
>>>>>>>> -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
>>>>>>>> http://www.dnswl.org/,
>>>>>>>> high
>>>>>>>> trust
>>>>>>>> [140.211.11.3 listed in list.dnswl.org
>> ]
>>>>>>>> -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover
>>>>>>>> relay
>>>>>>>>
>>>>>>>> domain
>>>>>>>> -3.0 RCVD_IN_RP_CERTIFIED RBL: Sender is in Return Path Certified
>>>>>>>> (trusted
>>>>>>>> relay)
>>>>>>>> [Return Path SenderScore Certified
>>>>>>>> (formerly]
>>>>>>>> [Bonded Sender) -<http://www.**
>>>>>>>>
>>>>>>>> senderscorecertified.com<http:**//www.senderscorecertified.com<
>> http://www.senderscorecertified.com>
>>>>>>>> **>>]
>>>>>>>>
>>>>>>>> -2.0 RCVD_IN_RP_SAFE RBL: Sender is in Return Path Safe
>>>>>>>> (trusted
>>>>>>>> relay)
>>>>>>>> [Return Path SenderScore Safe List
>>>>>>>> (formerly]
>>>>>>>> [Habeas Safelist) -<http://www.**
>>>>>>>>
>>>>>>>> senderscorecertified.com<http:**//www.senderscorecertified.com<
>> http://www.senderscorecertified.com>
>>>>>>>> **>>]
>>>>>>>> Return-Path: dev-return-5463-P.Sharples=**bol**
>>>>>>>> ton.ac.uk@rave.apache.org**<bo...@rave.apache.org>
>>>>>>>>
>>>>>>>> X-OriginalArrivalTime: 30 May 2012 15:09:06.0689 (UTC)
>>>>>>>> FILETIME=[284E3710:01CD3E76]
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>>
>>>>>>>>> From: jashaj@gmail.com [mailto:jashaj@gmail.com] On Behalf Of
>> Jasha
>>>>>>>>> Joachimsthal
>>>>>>>>> Sent: Wednesday, May 30, 2012 10:26 AM
>>>>>>>>> To: dev@rave.apache.org
>>>>>>>>> Subject: Re: Team Pages
>>>>>>>>>
>>>>>>>>> On 30 May 2012 16:10, Sean Cooper<se...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>> Is anyone currently working on team pages, or working on defining
>> a
>>>>>>>>>
>>>>>>>>>> structure for it?
>>>>>>>>>>
>>>>>>>>>> I'd like to take a crack at defining it this week, but I don't
>> want
>>>>>>>>>> to
>>>>>>>>>> interrupt anyone that might already be working on the problem.
>>>>>>>>>>
>>>>>>>>>> -Sean
>>>>>>>>>>
>>>>>>>>>> I am planning to work on it, but it's not clear yet when. So if
>> you
>>>>>>>>>>
>>>>>>>>> want to
>>>>>>>>> start, go ahead :) What I need is a concept of a page that is
>> shared
>>>>>>>>> with a
>>>>>>>>> group of users, but the users cannot edit the page, only the
>>>>>>>>> administrator
>>>>>>>>> of the page. See also [1]
>>>>>>>>>
>>>>>>>>> Please add to the proposal http://wiki.apache.org/rave/**
>>>>>>>>
>>>>>>>> ArchitectureTopics/PageModel<h**ttp://wiki.apache.org/rave/**
>>>>>>>>
>>>>>>>> ArchitectureTopics/PageModel<
>> http://wiki.apache.org/rave/ArchitectureTopics/PageModel>
>>>>>>>> I've got some changes&improvements I've made to the page sharing
>>>>>>>
>>>>>>> facility
>>>>>>>
>>>>>>> (RAVE-103), which probably are relevant to this discussion.
>>>>>>> (not team pages yet, but the ability to make shared pages
>> non-editable,
>>>>>>> for instance)
>>>>>>> Is it okay to commit this or are we too near the next build (i.e. is
>>>>>>> there
>>>>>>> a code freeze yet?)
>>>>>>>
>>>>>>> There's no code freeze yet, but if you break something now, you have
>>>>>>
>>>>>> less
>>>>>> than 24 hours to fix it ;)
>>>>>> Luckily some of the basic features are now covered by the integration
>>>>>> tests:
>>>>>> http://rave.apache.org/**integration-tests.html<
>> http://rave.apache.org/integration-tests.html>
>>>>>>
>>>>> Thanks Jasha, I've just comitted the changes. I'd be grateful if some
>>>>> of
>>>>> the other commiters could take a look.
>>>>>
>>>>> Paul
>>>>>
>>>>>
>>>> Good improvements! Without permission to edit the shared page users
>> don't
>>>> get the false hope to move or add widgets. I even tried to mess with the
>>>> widget store url and the referring page id, but then you still cannot
>> add
>>>> widgets :)
>>>>
>>>> In the share page dialog:
>>>> Shouldn't the "Edit preferences" option be disabled for users that don't
>>>> have edit permission? IMO it would be even better to remove the disabled
>>>> options than to show them greyed out.
>>>
>>>
>>> Just looking at the other menus, (the page menu for example) actions I
>> can't
>>> take as a user tend to be greyed out so I took the cue from that UI
>> pattern.
>>> (unless I have missed something :-) ) Its easy enough to change I guess.
>>>
>>> The reason I didn't grey out the "Edit preferences" was so that you can
>>> change something in your session, but it will not be persisted and so
>> will
>>> revert back to the perisisted state when you log in again. This is
>> similar
>>> to how the minimize/maximize widget now works for a non editing user.
>> This
>>> was an assumption and could be completely locked down instead.
>>>
>>>
>>>> The label "Edit permission" is a bit confusing (what permission can this
>>>> person edit?). Maybe "Permission to edit" or "Can edit page" are less
>>>> confusing. It is easy to change the add/remove links into checkboxes?
>>>
>>>
>>> Fair comment& easy enough to change
>>>
>>
>> My vote would be to disable all menus unless you are the owner/editor.
>> It doesn't make sense to allow someone with read-only access to
>> perform any actions on the page or the gadgets themselves. i.e. If I
>> have read-only access to the page I shouldn't be able to edit the
>> preferences or even maximize the gadget.
>>
>
> The view of the gadget (home or canvas) is not stored and defaults to the
> home view. Not allowing to maximize the gadget may mean a loss of
> functionality. See for example the Google translate gadget which has more
> options in the canvas (maximized) view.
>
I agree here with Jasha.
But for me more important is the question how we (Rave developers) deal with
optionality or configuration of such functionalities.
Which user actions are allowed under which circumstances and by whom is a very
fundamental question and something IMO Rave should provide a quite flexible and
pluggable solution for. No matter what specific choice would be made for this
use-case, someone else will have a conflicting or different need for it.
My take on these things typically is: if practically doable these things should
be made configurable and/or optional. That isn't the easy way out of course and
requires more effort and thinking upfront for the developers, but in the end
will pay off many times over. And not just for the others.
Just to be clear, I'm not saying this need or should be done for every possible
feature, that would make this project a drag and is impractical anyway.
But be wary for features and behaviors, especially those related to UI and user
interaction, which you can easily recognize as needing *your* specific use-case
requirements to fulfill.
Good chance someone else then will come up with conflicting requirements or
alternative solutions :)
Ate
>
>
>>
>>>
>>>>
>>>>
>>>>>> Jasha
>>>>>>
>>>>>>
>>>>>> Paul
>>>>>>>
>>>>>>>
>>>>>>> [1]
>>>>>>> http://markmail.org/thread/****5dfecb5gk7qynqdc<
>> http://markmail.org/thread/**5dfecb5gk7qynqdc>
>>>>>>>>
>>>>>>>>
>>>>>>>> <http://**markmail.org/thread/**5dfecb5gk7qynqdc<
>> http://markmail.org/thread/5dfecb5gk7qynqdc>
>>>>>>>> Jasha
>>>>>>>>>
>>>>>>>>> -----
>>>>>>>>
>>>>>>>> No virus found in this message.
>>>>>>>> Checked by AVG - www.avg.com
>>>>>>>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date:
>>>>>>>> 05/28/12
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> -----
>>>>>> No virus found in this message.
>>>>>> Checked by AVG - www.avg.com
>>>>>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date:
>>>>>> 05/28/12
>>>>>>
>>>>>
>>>>
>>>>
>>>> -----
>>>> No virus found in this message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date:
>> 05/28/12
>>>
>>>
>>
>
Re: Team Pages
Posted by Jasha Joachimsthal <ja...@apache.org>.
On 30 May 2012 22:16, Sean Cooper <se...@apache.org> wrote:
> On Wed, May 30, 2012 at 2:41 PM, Paul Sharples <p....@bolton.ac.uk>
> wrote:
> > On 30/05/2012 19:18, Jasha Joachimsthal wrote:
> >>
> >> On 30 May 2012 19:11, Paul Sharples<p....@bolton.ac.uk> wrote:
> >>
> >>> On 30/05/2012 16:52, Jasha Joachimsthal wrote:
> >>>
> >>>> On 30 May 2012 17:44, Paul
> >>>> Sharples<p....@bolton.ac.uk>>
> >>>> wrote:
> >>>>
> >>>> On 30/05/2012 16:08, Franklin, Matthew B. wrote:
> >>>>>
> >>>>> Content preview:>
> >>>>>>
> >>>>>> Content analysis details: (-10.0 points, 5.0 required)
> >>>>>>
> >>>>>> pts rule name description
> >>>>>> ---- ---------------------- ------------------------------****
> >>>>>>
> >>>>>> --------------------
> >>>>>> -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
> >>>>>> http://www.dnswl.org/,
> >>>>>> high
> >>>>>> trust
> >>>>>> [140.211.11.3 listed in list.dnswl.org
> ]
> >>>>>> -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover
> >>>>>> relay
> >>>>>>
> >>>>>> domain
> >>>>>> -3.0 RCVD_IN_RP_CERTIFIED RBL: Sender is in Return Path Certified
> >>>>>> (trusted
> >>>>>> relay)
> >>>>>> [Return Path SenderScore Certified
> >>>>>> (formerly]
> >>>>>> [Bonded Sender) -<http://www.**
> >>>>>>
> >>>>>> senderscorecertified.com<http:**//www.senderscorecertified.com<
> http://www.senderscorecertified.com>
> >>>>>> **>>]
> >>>>>>
> >>>>>> -2.0 RCVD_IN_RP_SAFE RBL: Sender is in Return Path Safe
> >>>>>> (trusted
> >>>>>> relay)
> >>>>>> [Return Path SenderScore Safe List
> >>>>>> (formerly]
> >>>>>> [Habeas Safelist) -<http://www.**
> >>>>>>
> >>>>>> senderscorecertified.com<http:**//www.senderscorecertified.com<
> http://www.senderscorecertified.com>
> >>>>>> **>>]
> >>>>>> Return-Path: dev-return-5463-P.Sharples=**bol**
> >>>>>> ton.ac.uk@rave.apache.org**<bo...@rave.apache.org>
> >>>>>>
> >>>>>> X-OriginalArrivalTime: 30 May 2012 15:09:06.0689 (UTC)
> >>>>>> FILETIME=[284E3710:01CD3E76]
> >>>>>>
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>>
> >>>>>>> From: jashaj@gmail.com [mailto:jashaj@gmail.com] On Behalf Of
> Jasha
> >>>>>>> Joachimsthal
> >>>>>>> Sent: Wednesday, May 30, 2012 10:26 AM
> >>>>>>> To: dev@rave.apache.org
> >>>>>>> Subject: Re: Team Pages
> >>>>>>>
> >>>>>>> On 30 May 2012 16:10, Sean Cooper<se...@apache.org> wrote:
> >>>>>>>
> >>>>>>> Is anyone currently working on team pages, or working on defining
> a
> >>>>>>>
> >>>>>>>> structure for it?
> >>>>>>>>
> >>>>>>>> I'd like to take a crack at defining it this week, but I don't
> want
> >>>>>>>> to
> >>>>>>>> interrupt anyone that might already be working on the problem.
> >>>>>>>>
> >>>>>>>> -Sean
> >>>>>>>>
> >>>>>>>> I am planning to work on it, but it's not clear yet when. So if
> you
> >>>>>>>>
> >>>>>>> want to
> >>>>>>> start, go ahead :) What I need is a concept of a page that is
> shared
> >>>>>>> with a
> >>>>>>> group of users, but the users cannot edit the page, only the
> >>>>>>> administrator
> >>>>>>> of the page. See also [1]
> >>>>>>>
> >>>>>>> Please add to the proposal http://wiki.apache.org/rave/**
> >>>>>>
> >>>>>> ArchitectureTopics/PageModel<h**ttp://wiki.apache.org/rave/**
> >>>>>>
> >>>>>> ArchitectureTopics/PageModel<
> http://wiki.apache.org/rave/ArchitectureTopics/PageModel>
> >>>>>> I've got some changes&improvements I've made to the page sharing
> >>>>>
> >>>>> facility
> >>>>>
> >>>>> (RAVE-103), which probably are relevant to this discussion.
> >>>>> (not team pages yet, but the ability to make shared pages
> non-editable,
> >>>>> for instance)
> >>>>> Is it okay to commit this or are we too near the next build (i.e. is
> >>>>> there
> >>>>> a code freeze yet?)
> >>>>>
> >>>>> There's no code freeze yet, but if you break something now, you have
> >>>>
> >>>> less
> >>>> than 24 hours to fix it ;)
> >>>> Luckily some of the basic features are now covered by the integration
> >>>> tests:
> >>>> http://rave.apache.org/**integration-tests.html<
> http://rave.apache.org/integration-tests.html>
> >>>>
> >>> Thanks Jasha, I've just comitted the changes. I'd be grateful if some
> >>> of
> >>> the other commiters could take a look.
> >>>
> >>> Paul
> >>>
> >>>
> >> Good improvements! Without permission to edit the shared page users
> don't
> >> get the false hope to move or add widgets. I even tried to mess with the
> >> widget store url and the referring page id, but then you still cannot
> add
> >> widgets :)
> >>
> >> In the share page dialog:
> >> Shouldn't the "Edit preferences" option be disabled for users that don't
> >> have edit permission? IMO it would be even better to remove the disabled
> >> options than to show them greyed out.
> >
> >
> > Just looking at the other menus, (the page menu for example) actions I
> can't
> > take as a user tend to be greyed out so I took the cue from that UI
> pattern.
> > (unless I have missed something :-) ) Its easy enough to change I guess.
> >
> > The reason I didn't grey out the "Edit preferences" was so that you can
> > change something in your session, but it will not be persisted and so
> will
> > revert back to the perisisted state when you log in again. This is
> similar
> > to how the minimize/maximize widget now works for a non editing user.
> This
> > was an assumption and could be completely locked down instead.
> >
> >
> >> The label "Edit permission" is a bit confusing (what permission can this
> >> person edit?). Maybe "Permission to edit" or "Can edit page" are less
> >> confusing. It is easy to change the add/remove links into checkboxes?
> >
> >
> > Fair comment & easy enough to change
> >
>
> My vote would be to disable all menus unless you are the owner/editor.
> It doesn't make sense to allow someone with read-only access to
> perform any actions on the page or the gadgets themselves. i.e. If I
> have read-only access to the page I shouldn't be able to edit the
> preferences or even maximize the gadget.
>
The view of the gadget (home or canvas) is not stored and defaults to the
home view. Not allowing to maximize the gadget may mean a loss of
functionality. See for example the Google translate gadget which has more
options in the canvas (maximized) view.
>
> >
> >>
> >>
> >>>> Jasha
> >>>>
> >>>>
> >>>> Paul
> >>>>>
> >>>>>
> >>>>> [1]
> >>>>> http://markmail.org/thread/****5dfecb5gk7qynqdc<
> http://markmail.org/thread/**5dfecb5gk7qynqdc>
> >>>>>>
> >>>>>>
> >>>>>> <http://**markmail.org/thread/**5dfecb5gk7qynqdc<
> http://markmail.org/thread/5dfecb5gk7qynqdc>
> >>>>>> Jasha
> >>>>>>>
> >>>>>>> -----
> >>>>>>
> >>>>>> No virus found in this message.
> >>>>>> Checked by AVG - www.avg.com
> >>>>>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date:
> >>>>>> 05/28/12
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>> -----
> >>>> No virus found in this message.
> >>>> Checked by AVG - www.avg.com
> >>>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date:
> >>>> 05/28/12
> >>>>
> >>>
> >>
> >>
> >> -----
> >> No virus found in this message.
> >> Checked by AVG - www.avg.com
> >> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date:
> 05/28/12
> >
> >
>
Re: Team Pages
Posted by Sean Cooper <se...@apache.org>.
On Wed, May 30, 2012 at 2:41 PM, Paul Sharples <p....@bolton.ac.uk> wrote:
> On 30/05/2012 19:18, Jasha Joachimsthal wrote:
>>
>> On 30 May 2012 19:11, Paul Sharples<p....@bolton.ac.uk> wrote:
>>
>>> On 30/05/2012 16:52, Jasha Joachimsthal wrote:
>>>
>>>> On 30 May 2012 17:44, Paul
>>>> Sharples<p....@bolton.ac.uk>>
>>>> wrote:
>>>>
>>>> On 30/05/2012 16:08, Franklin, Matthew B. wrote:
>>>>>
>>>>> Content preview:>
>>>>>>
>>>>>> Content analysis details: (-10.0 points, 5.0 required)
>>>>>>
>>>>>> pts rule name description
>>>>>> ---- ---------------------- ------------------------------****
>>>>>>
>>>>>> --------------------
>>>>>> -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
>>>>>> http://www.dnswl.org/,
>>>>>> high
>>>>>> trust
>>>>>> [140.211.11.3 listed in list.dnswl.org]
>>>>>> -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover
>>>>>> relay
>>>>>>
>>>>>> domain
>>>>>> -3.0 RCVD_IN_RP_CERTIFIED RBL: Sender is in Return Path Certified
>>>>>> (trusted
>>>>>> relay)
>>>>>> [Return Path SenderScore Certified
>>>>>> (formerly]
>>>>>> [Bonded Sender) -<http://www.**
>>>>>>
>>>>>> senderscorecertified.com<http:**//www.senderscorecertified.com<http://www.senderscorecertified.com>
>>>>>> **>>]
>>>>>>
>>>>>> -2.0 RCVD_IN_RP_SAFE RBL: Sender is in Return Path Safe
>>>>>> (trusted
>>>>>> relay)
>>>>>> [Return Path SenderScore Safe List
>>>>>> (formerly]
>>>>>> [Habeas Safelist) -<http://www.**
>>>>>>
>>>>>> senderscorecertified.com<http:**//www.senderscorecertified.com<http://www.senderscorecertified.com>
>>>>>> **>>]
>>>>>> Return-Path: dev-return-5463-P.Sharples=**bol**
>>>>>> ton.ac.uk@rave.apache.org**<bo...@rave.apache.org>
>>>>>>
>>>>>> X-OriginalArrivalTime: 30 May 2012 15:09:06.0689 (UTC)
>>>>>> FILETIME=[284E3710:01CD3E76]
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>>
>>>>>>> From: jashaj@gmail.com [mailto:jashaj@gmail.com] On Behalf Of Jasha
>>>>>>> Joachimsthal
>>>>>>> Sent: Wednesday, May 30, 2012 10:26 AM
>>>>>>> To: dev@rave.apache.org
>>>>>>> Subject: Re: Team Pages
>>>>>>>
>>>>>>> On 30 May 2012 16:10, Sean Cooper<se...@apache.org> wrote:
>>>>>>>
>>>>>>> Is anyone currently working on team pages, or working on defining a
>>>>>>>
>>>>>>>> structure for it?
>>>>>>>>
>>>>>>>> I'd like to take a crack at defining it this week, but I don't want
>>>>>>>> to
>>>>>>>> interrupt anyone that might already be working on the problem.
>>>>>>>>
>>>>>>>> -Sean
>>>>>>>>
>>>>>>>> I am planning to work on it, but it's not clear yet when. So if you
>>>>>>>>
>>>>>>> want to
>>>>>>> start, go ahead :) What I need is a concept of a page that is shared
>>>>>>> with a
>>>>>>> group of users, but the users cannot edit the page, only the
>>>>>>> administrator
>>>>>>> of the page. See also [1]
>>>>>>>
>>>>>>> Please add to the proposal http://wiki.apache.org/rave/**
>>>>>>
>>>>>> ArchitectureTopics/PageModel<h**ttp://wiki.apache.org/rave/**
>>>>>>
>>>>>> ArchitectureTopics/PageModel<http://wiki.apache.org/rave/ArchitectureTopics/PageModel>
>>>>>> I've got some changes&improvements I've made to the page sharing
>>>>>
>>>>> facility
>>>>>
>>>>> (RAVE-103), which probably are relevant to this discussion.
>>>>> (not team pages yet, but the ability to make shared pages non-editable,
>>>>> for instance)
>>>>> Is it okay to commit this or are we too near the next build (i.e. is
>>>>> there
>>>>> a code freeze yet?)
>>>>>
>>>>> There's no code freeze yet, but if you break something now, you have
>>>>
>>>> less
>>>> than 24 hours to fix it ;)
>>>> Luckily some of the basic features are now covered by the integration
>>>> tests:
>>>> http://rave.apache.org/**integration-tests.html<http://rave.apache.org/integration-tests.html>
>>>>
>>> Thanks Jasha, I've just comitted the changes. I'd be grateful if some
>>> of
>>> the other commiters could take a look.
>>>
>>> Paul
>>>
>>>
>> Good improvements! Without permission to edit the shared page users don't
>> get the false hope to move or add widgets. I even tried to mess with the
>> widget store url and the referring page id, but then you still cannot add
>> widgets :)
>>
>> In the share page dialog:
>> Shouldn't the "Edit preferences" option be disabled for users that don't
>> have edit permission? IMO it would be even better to remove the disabled
>> options than to show them greyed out.
>
>
> Just looking at the other menus, (the page menu for example) actions I can't
> take as a user tend to be greyed out so I took the cue from that UI pattern.
> (unless I have missed something :-) ) Its easy enough to change I guess.
>
> The reason I didn't grey out the "Edit preferences" was so that you can
> change something in your session, but it will not be persisted and so will
> revert back to the perisisted state when you log in again. This is similar
> to how the minimize/maximize widget now works for a non editing user. This
> was an assumption and could be completely locked down instead.
>
>
>> The label "Edit permission" is a bit confusing (what permission can this
>> person edit?). Maybe "Permission to edit" or "Can edit page" are less
>> confusing. It is easy to change the add/remove links into checkboxes?
>
>
> Fair comment & easy enough to change
>
My vote would be to disable all menus unless you are the owner/editor.
It doesn't make sense to allow someone with read-only access to
perform any actions on the page or the gadgets themselves. i.e. If I
have read-only access to the page I shouldn't be able to edit the
preferences or even maximize the gadget.
>
>>
>>
>>>> Jasha
>>>>
>>>>
>>>> Paul
>>>>>
>>>>>
>>>>> [1]
>>>>> http://markmail.org/thread/****5dfecb5gk7qynqdc<http://markmail.org/thread/**5dfecb5gk7qynqdc>
>>>>>>
>>>>>>
>>>>>> <http://**markmail.org/thread/**5dfecb5gk7qynqdc<http://markmail.org/thread/5dfecb5gk7qynqdc>
>>>>>> Jasha
>>>>>>>
>>>>>>> -----
>>>>>>
>>>>>> No virus found in this message.
>>>>>> Checked by AVG - www.avg.com
>>>>>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date:
>>>>>> 05/28/12
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> -----
>>>> No virus found in this message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date:
>>>> 05/28/12
>>>>
>>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date: 05/28/12
>
>
Re: Team Pages
Posted by Jasha Joachimsthal <ja...@apache.org>.
On 30 May 2012 20:41, Paul Sharples <p....@bolton.ac.uk> wrote:
> On 30/05/2012 19:18, Jasha Joachimsthal wrote:
>
>> On 30 May 2012 19:11, Paul Sharples<p....@bolton.ac.uk>>
>> wrote:
>>
>> On 30/05/2012 16:52, Jasha Joachimsthal wrote:
>>>
>>> On 30 May 2012 17:44, Paul Sharples<p.sharples@bolton.ac.****uk<
>>>> p.sharples@bolton.ac.uk>>
>>>>
>>>> wrote:
>>>>
>>>> On 30/05/2012 16:08, Franklin, Matthew B. wrote:
>>>>
>>>>> Content preview:>
>>>>>
>>>>>> Content analysis details: (-10.0 points, 5.0 required)
>>>>>>
>>>>>> pts rule name description
>>>>>> ---- ---------------------- ------------------------------******
>>>>>>
>>>>>>
>>>>>> --------------------
>>>>>> -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
>>>>>> http://www.dnswl.org/,
>>>>>> high
>>>>>> trust
>>>>>> [140.211.11.3 listed in list.dnswl.org]
>>>>>> -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover
>>>>>> relay
>>>>>>
>>>>>> domain
>>>>>> -3.0 RCVD_IN_RP_CERTIFIED RBL: Sender is in Return Path Certified
>>>>>> (trusted
>>>>>> relay)
>>>>>> [Return Path SenderScore Certified
>>>>>> (formerly]
>>>>>> [Bonded Sender) -<http://www.**
>>>>>> senderscorecertified.com<http:****//www.senderscorecertified.**com<http://www.senderscorecertified.com>
>>>>>> <http://www.**senderscorecertified.com<http://www.senderscorecertified.com>
>>>>>> >
>>>>>> **>>]
>>>>>>
>>>>>>
>>>>>> -2.0 RCVD_IN_RP_SAFE RBL: Sender is in Return Path Safe
>>>>>> (trusted
>>>>>> relay)
>>>>>> [Return Path SenderScore Safe List
>>>>>> (formerly]
>>>>>> [Habeas Safelist) -<http://www.**
>>>>>> senderscorecertified.com<http:****//www.senderscorecertified.**com<http://www.senderscorecertified.com>
>>>>>> <http://www.**senderscorecertified.com<http://www.senderscorecertified.com>
>>>>>> >
>>>>>> **>>]
>>>>>> Return-Path: dev-return-5463-P.Sharples=****bol**
>>>>>> ton.ac.uk@rave.apache.org**<bo...@rave.apache.org>
>>>>>> >
>>>>>>
>>>>>>
>>>>>> X-OriginalArrivalTime: 30 May 2012 15:09:06.0689 (UTC)
>>>>>> FILETIME=[284E3710:01CD3E76]
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>>
>>>>>> From: jashaj@gmail.com [mailto:jashaj@gmail.com] On Behalf Of Jasha
>>>>>>> Joachimsthal
>>>>>>> Sent: Wednesday, May 30, 2012 10:26 AM
>>>>>>> To: dev@rave.apache.org
>>>>>>> Subject: Re: Team Pages
>>>>>>>
>>>>>>> On 30 May 2012 16:10, Sean Cooper<se...@apache.org> wrote:
>>>>>>>
>>>>>>> Is anyone currently working on team pages, or working on defining a
>>>>>>>
>>>>>>> structure for it?
>>>>>>>>
>>>>>>>> I'd like to take a crack at defining it this week, but I don't want
>>>>>>>> to
>>>>>>>> interrupt anyone that might already be working on the problem.
>>>>>>>>
>>>>>>>> -Sean
>>>>>>>>
>>>>>>>> I am planning to work on it, but it's not clear yet when. So if you
>>>>>>>>
>>>>>>>> want to
>>>>>>> start, go ahead :) What I need is a concept of a page that is shared
>>>>>>> with a
>>>>>>> group of users, but the users cannot edit the page, only the
>>>>>>> administrator
>>>>>>> of the page. See also [1]
>>>>>>>
>>>>>>> Please add to the proposal http://wiki.apache.org/rave/**
>>>>>>>
>>>>>> ArchitectureTopics/PageModel<**h**ttp://wiki.apache.org/rave/****<http://wiki.apache.org/rave/**>
>>>>>>
>>>>>> ArchitectureTopics/PageModel<h**ttp://wiki.apache.org/rave/**
>>>>>> ArchitectureTopics/PageModel<http://wiki.apache.org/rave/ArchitectureTopics/PageModel>
>>>>>> >
>>>>>> I've got some changes&improvements I've made to the page sharing
>>>>>>
>>>>> facility
>>>>>
>>>>> (RAVE-103), which probably are relevant to this discussion.
>>>>> (not team pages yet, but the ability to make shared pages non-editable,
>>>>> for instance)
>>>>> Is it okay to commit this or are we too near the next build (i.e. is
>>>>> there
>>>>> a code freeze yet?)
>>>>>
>>>>> There's no code freeze yet, but if you break something now, you have
>>>>>
>>>> less
>>>> than 24 hours to fix it ;)
>>>> Luckily some of the basic features are now covered by the integration
>>>> tests: http://rave.apache.org/****integration-tests.html<http://rave.apache.org/**integration-tests.html>
>>>> <http://**rave.apache.org/integration-**tests.html<http://rave.apache.org/integration-tests.html>
>>>> >
>>>>
>>>> Thanks Jasha, I've just comitted the changes. I'd be grateful if
>>> some of
>>> the other commiters could take a look.
>>>
>>> Paul
>>>
>>>
>>> Good improvements! Without permission to edit the shared page users
>> don't
>> get the false hope to move or add widgets. I even tried to mess with the
>> widget store url and the referring page id, but then you still cannot add
>> widgets :)
>>
>> In the share page dialog:
>> Shouldn't the "Edit preferences" option be disabled for users that don't
>> have edit permission? IMO it would be even better to remove the disabled
>> options than to show them greyed out.
>>
>
> Just looking at the other menus, (the page menu for example) actions I
> can't take as a user tend to be greyed out so I took the cue from that UI
> pattern. (unless I have missed something :-) ) Its easy enough to change I
> guess.
>
Yes you were consistent here :) Maybe some other time we can decide about
this.
>
> The reason I didn't grey out the "Edit preferences" was so that you can
> change something in your session, but it will not be persisted and so will
> revert back to the perisisted state when you log in again. This is similar
> to how the minimize/maximize widget now works for a non editing user. This
> was an assumption and could be completely locked down instead.
Fair enough
>
>
> The label "Edit permission" is a bit confusing (what permission can this
>> person edit?). Maybe "Permission to edit" or "Can edit page" are less
>> confusing. It is easy to change the add/remove links into checkboxes?
>>
>
> Fair comment & easy enough to change
>
>
>>
>> Jasha
>>>>
>>>>
>>>> Paul
>>>>
>>>>>
>>>>> [1] http://markmail.org/thread/******5dfecb5gk7qynqdc<http://markmail.org/thread/****5dfecb5gk7qynqdc>
>>>>> <http://**markmail.org/thread/****5dfecb5gk7qynqdc<http://markmail.org/thread/**5dfecb5gk7qynqdc>
>>>>> >
>>>>>
>>>>>> <http://**markmail.org/thread/****5dfecb5gk7qynqdc<http://markmail.org/thread/**5dfecb5gk7qynqdc>
>>>>>> <http://**markmail.org/thread/**5dfecb5gk7qynqdc<http://markmail.org/thread/5dfecb5gk7qynqdc>
>>>>>> >
>>>>>>
>>>>>> Jasha
>>>>>>
>>>>>>> -----
>>>>>>>
>>>>>> No virus found in this message.
>>>>>> Checked by AVG - www.avg.com
>>>>>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date:
>>>>>> 05/28/12
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----
>>>> No virus found in this message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date:
>>>> 05/28/12
>>>>
>>>>
>>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date: 05/28/12
>>
>
>
Re: Team Pages
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 30/05/2012 19:18, Jasha Joachimsthal wrote:
> On 30 May 2012 19:11, Paul Sharples<p....@bolton.ac.uk> wrote:
>
>> On 30/05/2012 16:52, Jasha Joachimsthal wrote:
>>
>>> On 30 May 2012 17:44, Paul Sharples<p....@bolton.ac.uk>>
>>> wrote:
>>>
>>> On 30/05/2012 16:08, Franklin, Matthew B. wrote:
>>>> Content preview:>
>>>>> Content analysis details: (-10.0 points, 5.0 required)
>>>>>
>>>>> pts rule name description
>>>>> ---- ---------------------- ------------------------------****
>>>>>
>>>>> --------------------
>>>>> -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
>>>>> http://www.dnswl.org/,
>>>>> high
>>>>> trust
>>>>> [140.211.11.3 listed in list.dnswl.org]
>>>>> -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover
>>>>> relay
>>>>>
>>>>> domain
>>>>> -3.0 RCVD_IN_RP_CERTIFIED RBL: Sender is in Return Path Certified
>>>>> (trusted
>>>>> relay)
>>>>> [Return Path SenderScore Certified
>>>>> (formerly]
>>>>> [Bonded Sender) -<http://www.**
>>>>> senderscorecertified.com<http:**//www.senderscorecertified.com<http://www.senderscorecertified.com>
>>>>> **>>]
>>>>>
>>>>> -2.0 RCVD_IN_RP_SAFE RBL: Sender is in Return Path Safe (trusted
>>>>> relay)
>>>>> [Return Path SenderScore Safe List
>>>>> (formerly]
>>>>> [Habeas Safelist) -<http://www.**
>>>>> senderscorecertified.com<http:**//www.senderscorecertified.com<http://www.senderscorecertified.com>
>>>>> **>>]
>>>>> Return-Path: dev-return-5463-P.Sharples=**bol**
>>>>> ton.ac.uk@rave.apache.org**<bo...@rave.apache.org>
>>>>>
>>>>> X-OriginalArrivalTime: 30 May 2012 15:09:06.0689 (UTC)
>>>>> FILETIME=[284E3710:01CD3E76]
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>>
>>>>>> From: jashaj@gmail.com [mailto:jashaj@gmail.com] On Behalf Of Jasha
>>>>>> Joachimsthal
>>>>>> Sent: Wednesday, May 30, 2012 10:26 AM
>>>>>> To: dev@rave.apache.org
>>>>>> Subject: Re: Team Pages
>>>>>>
>>>>>> On 30 May 2012 16:10, Sean Cooper<se...@apache.org> wrote:
>>>>>>
>>>>>> Is anyone currently working on team pages, or working on defining a
>>>>>>
>>>>>>> structure for it?
>>>>>>>
>>>>>>> I'd like to take a crack at defining it this week, but I don't want to
>>>>>>> interrupt anyone that might already be working on the problem.
>>>>>>>
>>>>>>> -Sean
>>>>>>>
>>>>>>> I am planning to work on it, but it's not clear yet when. So if you
>>>>>>>
>>>>>> want to
>>>>>> start, go ahead :) What I need is a concept of a page that is shared
>>>>>> with a
>>>>>> group of users, but the users cannot edit the page, only the
>>>>>> administrator
>>>>>> of the page. See also [1]
>>>>>>
>>>>>> Please add to the proposal http://wiki.apache.org/rave/**
>>>>> ArchitectureTopics/PageModel<h**ttp://wiki.apache.org/rave/**
>>>>> ArchitectureTopics/PageModel<http://wiki.apache.org/rave/ArchitectureTopics/PageModel>
>>>>> I've got some changes&improvements I've made to the page sharing
>>>> facility
>>>>
>>>> (RAVE-103), which probably are relevant to this discussion.
>>>> (not team pages yet, but the ability to make shared pages non-editable,
>>>> for instance)
>>>> Is it okay to commit this or are we too near the next build (i.e. is
>>>> there
>>>> a code freeze yet?)
>>>>
>>>> There's no code freeze yet, but if you break something now, you have
>>> less
>>> than 24 hours to fix it ;)
>>> Luckily some of the basic features are now covered by the integration
>>> tests: http://rave.apache.org/**integration-tests.html<http://rave.apache.org/integration-tests.html>
>>>
>> Thanks Jasha, I've just comitted the changes. I'd be grateful if some of
>> the other commiters could take a look.
>>
>> Paul
>>
>>
> Good improvements! Without permission to edit the shared page users don't
> get the false hope to move or add widgets. I even tried to mess with the
> widget store url and the referring page id, but then you still cannot add
> widgets :)
>
> In the share page dialog:
> Shouldn't the "Edit preferences" option be disabled for users that don't
> have edit permission? IMO it would be even better to remove the disabled
> options than to show them greyed out.
Just looking at the other menus, (the page menu for example) actions I
can't take as a user tend to be greyed out so I took the cue from that
UI pattern. (unless I have missed something :-) ) Its easy enough to
change I guess.
The reason I didn't grey out the "Edit preferences" was so that you can
change something in your session, but it will not be persisted and so
will revert back to the perisisted state when you log in again. This is
similar to how the minimize/maximize widget now works for a non editing
user. This was an assumption and could be completely locked down instead.
> The label "Edit permission" is a bit confusing (what permission can this
> person edit?). Maybe "Permission to edit" or "Can edit page" are less
> confusing. It is easy to change the add/remove links into checkboxes?
Fair comment & easy enough to change
>
>
>>> Jasha
>>>
>>>
>>> Paul
>>>>
>>>> [1] http://markmail.org/thread/****5dfecb5gk7qynqdc<http://markmail.org/thread/**5dfecb5gk7qynqdc>
>>>>> <http://**markmail.org/thread/**5dfecb5gk7qynqdc<http://markmail.org/thread/5dfecb5gk7qynqdc>
>>>>> Jasha
>>>>>> -----
>>>>> No virus found in this message.
>>>>> Checked by AVG - www.avg.com
>>>>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date:
>>>>> 05/28/12
>>>>>
>>>>>
>>>>>
>>>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date: 05/28/12
>>>
>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date: 05/28/12
Re: Team Pages
Posted by Jasha Joachimsthal <ja...@apache.org>.
On 30 May 2012 19:11, Paul Sharples <p....@bolton.ac.uk> wrote:
> On 30/05/2012 16:52, Jasha Joachimsthal wrote:
>
>> On 30 May 2012 17:44, Paul Sharples<p....@bolton.ac.uk>>
>> wrote:
>>
>> On 30/05/2012 16:08, Franklin, Matthew B. wrote:
>>>
>>> Content preview:>
>>>>
>>>> Content analysis details: (-10.0 points, 5.0 required)
>>>>
>>>> pts rule name description
>>>> ---- ---------------------- ------------------------------****
>>>>
>>>> --------------------
>>>> -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
>>>> http://www.dnswl.org/,
>>>> high
>>>> trust
>>>> [140.211.11.3 listed in list.dnswl.org]
>>>> -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover
>>>> relay
>>>>
>>>> domain
>>>> -3.0 RCVD_IN_RP_CERTIFIED RBL: Sender is in Return Path Certified
>>>> (trusted
>>>> relay)
>>>> [Return Path SenderScore Certified
>>>> (formerly]
>>>> [Bonded Sender) -<http://www.**
>>>> senderscorecertified.com<http:**//www.senderscorecertified.com<http://www.senderscorecertified.com>
>>>> **>>]
>>>>
>>>> -2.0 RCVD_IN_RP_SAFE RBL: Sender is in Return Path Safe (trusted
>>>> relay)
>>>> [Return Path SenderScore Safe List
>>>> (formerly]
>>>> [Habeas Safelist) -<http://www.**
>>>> senderscorecertified.com<http:**//www.senderscorecertified.com<http://www.senderscorecertified.com>
>>>> **>>]
>>>> Return-Path: dev-return-5463-P.Sharples=**bol**
>>>> ton.ac.uk@rave.apache.org**<bo...@rave.apache.org>
>>>>
>>>> X-OriginalArrivalTime: 30 May 2012 15:09:06.0689 (UTC)
>>>> FILETIME=[284E3710:01CD3E76]
>>>>
>>>>
>>>> -----Original Message-----
>>>>
>>>>> From: jashaj@gmail.com [mailto:jashaj@gmail.com] On Behalf Of Jasha
>>>>> Joachimsthal
>>>>> Sent: Wednesday, May 30, 2012 10:26 AM
>>>>> To: dev@rave.apache.org
>>>>> Subject: Re: Team Pages
>>>>>
>>>>> On 30 May 2012 16:10, Sean Cooper<se...@apache.org> wrote:
>>>>>
>>>>> Is anyone currently working on team pages, or working on defining a
>>>>>
>>>>>> structure for it?
>>>>>>
>>>>>> I'd like to take a crack at defining it this week, but I don't want to
>>>>>> interrupt anyone that might already be working on the problem.
>>>>>>
>>>>>> -Sean
>>>>>>
>>>>>> I am planning to work on it, but it's not clear yet when. So if you
>>>>>>
>>>>> want to
>>>>> start, go ahead :) What I need is a concept of a page that is shared
>>>>> with a
>>>>> group of users, but the users cannot edit the page, only the
>>>>> administrator
>>>>> of the page. See also [1]
>>>>>
>>>>> Please add to the proposal http://wiki.apache.org/rave/**
>>>> ArchitectureTopics/PageModel<h**ttp://wiki.apache.org/rave/**
>>>> ArchitectureTopics/PageModel<http://wiki.apache.org/rave/ArchitectureTopics/PageModel>
>>>> >
>>>>
>>>> I've got some changes&improvements I've made to the page sharing
>>> facility
>>>
>>> (RAVE-103), which probably are relevant to this discussion.
>>> (not team pages yet, but the ability to make shared pages non-editable,
>>> for instance)
>>> Is it okay to commit this or are we too near the next build (i.e. is
>>> there
>>> a code freeze yet?)
>>>
>>> There's no code freeze yet, but if you break something now, you have
>> less
>> than 24 hours to fix it ;)
>> Luckily some of the basic features are now covered by the integration
>> tests: http://rave.apache.org/**integration-tests.html<http://rave.apache.org/integration-tests.html>
>>
>
> Thanks Jasha, I've just comitted the changes. I'd be grateful if some of
> the other commiters could take a look.
>
> Paul
>
>
Good improvements! Without permission to edit the shared page users don't
get the false hope to move or add widgets. I even tried to mess with the
widget store url and the referring page id, but then you still cannot add
widgets :)
In the share page dialog:
Shouldn't the "Edit preferences" option be disabled for users that don't
have edit permission? IMO it would be even better to remove the disabled
options than to show them greyed out.
The label "Edit permission" is a bit confusing (what permission can this
person edit?). Maybe "Permission to edit" or "Can edit page" are less
confusing. It is easy to change the add/remove links into checkboxes?
>
>> Jasha
>>
>>
>> Paul
>>>
>>>
>>> [1] http://markmail.org/thread/****5dfecb5gk7qynqdc<http://markmail.org/thread/**5dfecb5gk7qynqdc>
>>>> <http://**markmail.org/thread/**5dfecb5gk7qynqdc<http://markmail.org/thread/5dfecb5gk7qynqdc>
>>>> >
>>>>
>>>> Jasha
>>>>>
>>>>> -----
>>>> No virus found in this message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date:
>>>> 05/28/12
>>>>
>>>>
>>>>
>>>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date: 05/28/12
>>
>
>
Re: Team Pages
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 30/05/2012 16:52, Jasha Joachimsthal wrote:
> On 30 May 2012 17:44, Paul Sharples<p....@bolton.ac.uk> wrote:
>
>> On 30/05/2012 16:08, Franklin, Matthew B. wrote:
>>
>>> Content preview:>
>>>
>>> Content analysis details: (-10.0 points, 5.0 required)
>>>
>>> pts rule name description
>>> ---- ---------------------- ------------------------------**
>>> --------------------
>>> -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,
>>> high
>>> trust
>>> [140.211.11.3 listed in list.dnswl.org]
>>> -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
>>>
>>> domain
>>> -3.0 RCVD_IN_RP_CERTIFIED RBL: Sender is in Return Path Certified
>>> (trusted
>>> relay)
>>> [Return Path SenderScore Certified (formerly]
>>> [Bonded Sender) -<http://www.**
>>> senderscorecertified.com<http://www.senderscorecertified.com>>]
>>> -2.0 RCVD_IN_RP_SAFE RBL: Sender is in Return Path Safe (trusted
>>> relay)
>>> [Return Path SenderScore Safe List (formerly]
>>> [Habeas Safelist) -<http://www.**
>>> senderscorecertified.com<http://www.senderscorecertified.com>>]
>>> Return-Path: dev-return-5463-P.Sharples=bol**ton.ac.uk@rave.apache.org<bo...@rave.apache.org>
>>> X-OriginalArrivalTime: 30 May 2012 15:09:06.0689 (UTC)
>>> FILETIME=[284E3710:01CD3E76]
>>>
>>>
>>> -----Original Message-----
>>>> From: jashaj@gmail.com [mailto:jashaj@gmail.com] On Behalf Of Jasha
>>>> Joachimsthal
>>>> Sent: Wednesday, May 30, 2012 10:26 AM
>>>> To: dev@rave.apache.org
>>>> Subject: Re: Team Pages
>>>>
>>>> On 30 May 2012 16:10, Sean Cooper<se...@apache.org> wrote:
>>>>
>>>> Is anyone currently working on team pages, or working on defining a
>>>>> structure for it?
>>>>>
>>>>> I'd like to take a crack at defining it this week, but I don't want to
>>>>> interrupt anyone that might already be working on the problem.
>>>>>
>>>>> -Sean
>>>>>
>>>>> I am planning to work on it, but it's not clear yet when. So if you
>>>> want to
>>>> start, go ahead :) What I need is a concept of a page that is shared
>>>> with a
>>>> group of users, but the users cannot edit the page, only the
>>>> administrator
>>>> of the page. See also [1]
>>>>
>>> Please add to the proposal http://wiki.apache.org/rave/**
>>> ArchitectureTopics/PageModel<http://wiki.apache.org/rave/ArchitectureTopics/PageModel>
>>>
>> I've got some changes&improvements I've made to the page sharing facility
>> (RAVE-103), which probably are relevant to this discussion.
>> (not team pages yet, but the ability to make shared pages non-editable,
>> for instance)
>> Is it okay to commit this or are we too near the next build (i.e. is there
>> a code freeze yet?)
>>
> There's no code freeze yet, but if you break something now, you have less
> than 24 hours to fix it ;)
> Luckily some of the basic features are now covered by the integration
> tests: http://rave.apache.org/integration-tests.html
Thanks Jasha, I've just comitted the changes. I'd be grateful if some
of the other commiters could take a look.
Paul
>
> Jasha
>
>
>> Paul
>>
>>
>>> [1] http://markmail.org/thread/**5dfecb5gk7qynqdc<http://markmail.org/thread/5dfecb5gk7qynqdc>
>>>> Jasha
>>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date: 05/28/12
>>>
>>>
>>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date: 05/28/12
Re: Team Pages
Posted by Jasha Joachimsthal <ja...@apache.org>.
On 30 May 2012 17:44, Paul Sharples <p....@bolton.ac.uk> wrote:
> On 30/05/2012 16:08, Franklin, Matthew B. wrote:
>
>> Content preview:>
>>
>> Content analysis details: (-10.0 points, 5.0 required)
>>
>> pts rule name description
>> ---- ---------------------- ------------------------------**
>> --------------------
>> -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/,
>> high
>> trust
>> [140.211.11.3 listed in list.dnswl.org]
>> -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
>>
>> domain
>> -3.0 RCVD_IN_RP_CERTIFIED RBL: Sender is in Return Path Certified
>> (trusted
>> relay)
>> [Return Path SenderScore Certified (formerly]
>> [Bonded Sender) -<http://www.**
>> senderscorecertified.com <http://www.senderscorecertified.com>>]
>> -2.0 RCVD_IN_RP_SAFE RBL: Sender is in Return Path Safe (trusted
>> relay)
>> [Return Path SenderScore Safe List (formerly]
>> [Habeas Safelist) -<http://www.**
>> senderscorecertified.com <http://www.senderscorecertified.com>>]
>> Return-Path: dev-return-5463-P.Sharples=bol**ton.ac.uk@rave.apache.org<bo...@rave.apache.org>
>> X-OriginalArrivalTime: 30 May 2012 15:09:06.0689 (UTC)
>> FILETIME=[284E3710:01CD3E76]
>>
>>
>> -----Original Message-----
>>> From: jashaj@gmail.com [mailto:jashaj@gmail.com] On Behalf Of Jasha
>>> Joachimsthal
>>> Sent: Wednesday, May 30, 2012 10:26 AM
>>> To: dev@rave.apache.org
>>> Subject: Re: Team Pages
>>>
>>> On 30 May 2012 16:10, Sean Cooper<se...@apache.org> wrote:
>>>
>>> Is anyone currently working on team pages, or working on defining a
>>>> structure for it?
>>>>
>>>> I'd like to take a crack at defining it this week, but I don't want to
>>>> interrupt anyone that might already be working on the problem.
>>>>
>>>> -Sean
>>>>
>>>> I am planning to work on it, but it's not clear yet when. So if you
>>> want to
>>> start, go ahead :) What I need is a concept of a page that is shared
>>> with a
>>> group of users, but the users cannot edit the page, only the
>>> administrator
>>> of the page. See also [1]
>>>
>> Please add to the proposal http://wiki.apache.org/rave/**
>> ArchitectureTopics/PageModel<http://wiki.apache.org/rave/ArchitectureTopics/PageModel>
>>
>
> I've got some changes &improvements I've made to the page sharing facility
> (RAVE-103), which probably are relevant to this discussion.
> (not team pages yet, but the ability to make shared pages non-editable,
> for instance)
> Is it okay to commit this or are we too near the next build (i.e. is there
> a code freeze yet?)
>
There's no code freeze yet, but if you break something now, you have less
than 24 hours to fix it ;)
Luckily some of the basic features are now covered by the integration
tests: http://rave.apache.org/integration-tests.html
Jasha
>
> Paul
>
>
>> [1] http://markmail.org/thread/**5dfecb5gk7qynqdc<http://markmail.org/thread/5dfecb5gk7qynqdc>
>>>
>>> Jasha
>>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date: 05/28/12
>>
>>
>>
>
Re: Team Pages
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 30/05/2012 16:08, Franklin, Matthew B. wrote:
> Content preview:>
>
> Content analysis details: (-10.0 points, 5.0 required)
>
> pts rule name description
> ---- ---------------------- --------------------------------------------------
> -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high
> trust
> [140.211.11.3 listed in list.dnswl.org]
> -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
>
> domain
> -3.0 RCVD_IN_RP_CERTIFIED RBL: Sender is in Return Path Certified (trusted
> relay)
> [Return Path SenderScore Certified (formerly]
> [Bonded Sender) -<http://www.senderscorecertified.com>]
> -2.0 RCVD_IN_RP_SAFE RBL: Sender is in Return Path Safe (trusted relay)
> [Return Path SenderScore Safe List (formerly]
> [Habeas Safelist) -<http://www.senderscorecertified.com>]
> Return-Path: dev-return-5463-P.Sharples=bolton.ac.uk@rave.apache.org
> X-OriginalArrivalTime: 30 May 2012 15:09:06.0689 (UTC) FILETIME=[284E3710:01CD3E76]
>
>> -----Original Message-----
>> From: jashaj@gmail.com [mailto:jashaj@gmail.com] On Behalf Of Jasha
>> Joachimsthal
>> Sent: Wednesday, May 30, 2012 10:26 AM
>> To: dev@rave.apache.org
>> Subject: Re: Team Pages
>>
>> On 30 May 2012 16:10, Sean Cooper<se...@apache.org> wrote:
>>
>>> Is anyone currently working on team pages, or working on defining a
>>> structure for it?
>>>
>>> I'd like to take a crack at defining it this week, but I don't want to
>>> interrupt anyone that might already be working on the problem.
>>>
>>> -Sean
>>>
>> I am planning to work on it, but it's not clear yet when. So if you want to
>> start, go ahead :) What I need is a concept of a page that is shared with a
>> group of users, but the users cannot edit the page, only the administrator
>> of the page. See also [1]
> Please add to the proposal http://wiki.apache.org/rave/ArchitectureTopics/PageModel
I've got some changes &improvements I've made to the page sharing
facility (RAVE-103), which probably are relevant to this discussion.
(not team pages yet, but the ability to make shared pages non-editable,
for instance)
Is it okay to commit this or are we too near the next build (i.e. is
there a code freeze yet?)
Paul
>
>> [1] http://markmail.org/thread/5dfecb5gk7qynqdc
>>
>> Jasha
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2178 / Virus Database: 2425/5029 - Release Date: 05/28/12
>
>
RE: Team Pages
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: jashaj@gmail.com [mailto:jashaj@gmail.com] On Behalf Of Jasha
>Joachimsthal
>Sent: Wednesday, May 30, 2012 10:26 AM
>To: dev@rave.apache.org
>Subject: Re: Team Pages
>
>On 30 May 2012 16:10, Sean Cooper <se...@apache.org> wrote:
>
>> Is anyone currently working on team pages, or working on defining a
>> structure for it?
>>
>> I'd like to take a crack at defining it this week, but I don't want to
>> interrupt anyone that might already be working on the problem.
>>
>> -Sean
>>
>
>I am planning to work on it, but it's not clear yet when. So if you want to
>start, go ahead :) What I need is a concept of a page that is shared with a
>group of users, but the users cannot edit the page, only the administrator
>of the page. See also [1]
Please add to the proposal http://wiki.apache.org/rave/ArchitectureTopics/PageModel
>
>[1] http://markmail.org/thread/5dfecb5gk7qynqdc
>
>Jasha
Re: Team Pages
Posted by Jasha Joachimsthal <ja...@apache.org>.
On 30 May 2012 16:10, Sean Cooper <se...@apache.org> wrote:
> Is anyone currently working on team pages, or working on defining a
> structure for it?
>
> I'd like to take a crack at defining it this week, but I don't want to
> interrupt anyone that might already be working on the problem.
>
> -Sean
>
I am planning to work on it, but it's not clear yet when. So if you want to
start, go ahead :) What I need is a concept of a page that is shared with a
group of users, but the users cannot edit the page, only the administrator
of the page. See also [1]
[1] http://markmail.org/thread/5dfecb5gk7qynqdc
Jasha