On 05/30/2012 11:10 PM, Jasha Joachimsthal wrote:
On 30 May 2012 22:16, Sean Cooper<[email protected]> wrote:
On Wed, May 30, 2012 at 2:41 PM, Paul Sharples<[email protected]>
wrote:
On 30/05/2012 19:18, Jasha Joachimsthal wrote:
On 30 May 2012 19:11, Paul Sharples<[email protected]> wrote:
On 30/05/2012 16:52, Jasha Joachimsthal wrote:
On 30 May 2012 17:44, Paul
Sharples<[email protected].**uk<[email protected]>>
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**
[email protected]**<[email protected]>
X-OriginalArrivalTime: 30 May 2012 15:09:06.0689 (UTC)
FILETIME=[284E3710:01CD3E76]
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Jasha
Joachimsthal
Sent: Wednesday, May 30, 2012 10:26 AM
To: [email protected]
Subject: Re: Team Pages
On 30 May 2012 16:10, Sean Cooper<[email protected]> 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
