A workspace will have one or more owners* who get to decide who can:
- edit the workspace (i.e., join the ranks of administrators)
- access the workspace (i.e., join the ranks of users)
---
* (from implementation perspective, that could equal "one owner - who can be a
group")
The concept of ownership is key. Who owns the content that you create in a
workspace? In just about every collaboration-support system I've seen, the
author retains ownership. However, that creates problems - when the user leaves
the workspace (or the environment), what happens to the content? I'd like to
explore the concept of content being owned by the workspace... and if the user
is not comfortable with that, they have their own (personal) workspace to work
with.
Stan Drozdetski
MITRE
-----Original Message-----
From: Franklin, Matthew B. [mailto:[email protected]]
Sent: Tuesday, March 20, 2012 10:42 AM
To: [email protected]
Subject: RE: [jira] [Commented] (RAVE-103) Support shared spaces
-----Original Message-----
From: Scott Wilson [mailto:[email protected]]
Sent: Monday, March 19, 2012 5:36 PM
To: [email protected]
Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces
On 19 Mar 2012, at 13:51, Ate Douma wrote:
On 03/17/2012 04:37 PM, Scott Wilson (Commented) (JIRA) wrote:
[ https://issues.apache.org/jira/browse/RAVE-
103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel&focusedCommentId=13231993#comment-13231993 ]
Scott Wilson commented on RAVE-103:
-----------------------------------
I think there are two models we can look at:
1. Page Sharing
In this model, a user creates a new page, and from the tab context menu
selects "Share this page...". A dialog opens, and the user can add people (e.g.
using a search/filter view), or select an existing group (e.g. friends, family,
co-
workers...). The user chooses OK, and each user is notified when they log into
Rave of the invitation to add the shared Page. The user who created the Page
is the Owner; each user they share with is by default a Viewer (read-only).
However, it should be possible for the Owner to grant other users a "Can Edit"
role allowing them to add, remove and move widgets.
2. Workspace Sharing
In this model, there is a higher-level entity comprising a collection of
multiple pages managed by a group. New shared pages can be added as sub-
pages of the top-level workspace. I'm a bit less clear on the workflow for this
one, whether its the same as (1) but with sub-pages, or something
conceptually quite different
IMO we should (eventually) strive to merge both these models into one
logical model from Rave perspective.
For one, we already have a 'shared' page right now: the profile page. With
sub pages...
IMO the current separate/special handling of the profile page should
technically or model wise not be special at all. What difference is there
between sharing 'a' page to the public with sharing 'the' profile page(s) to the
public?
To me this seems like just a matter of security configuration, with the profile
page 'just' representing a common default 'share'.
Right - that could be handled by "magic" Users like AnyAuthenticatedUser and
Anyone that you could add as a member of your page, or some user-less
permissions attached to the page.
+1 for modeling them the same. We just have to make sure that we have the
right information available when the page is created to apply the right
permission scheme; but this could be accomplished by re-working the Page
Template to include a default permission set. There is one small OpenSocial
concern we need to make sure we have a strategy for supporting: The default
view name for profile isn't HOME, it's PROFILE.
Interestingly, the current profile page also now has 'sub' pages, which in a
minimalistic sense maybe could be regarded as a shared 'workspace' already
(with a single owner).
Indeed - every page is sort of a workspace in that regard, though that isn't
currently exposed through the UI.
I could definitely see a scenario where we have the concept of a workspace with "pages" attached to it.
The workspace would represent the context and could come in the form of a portal, profile, team site,
peer-to-peer shared workspace, and any other scenario. The changes in context would allow us to create
implementations that have different "UI" for each workspace. This way, each workspace can lay out the
entire web page however works best for their use case. We can then create a new construct of "Workspace
Template" that is responsible for the overall look, feel& layout of the web page and use the
PageTemplates to manage the regions and corresponding widgets.
I'm interested in how adding a shared page to the users view of pages will
work out.
That looks to be the bigger challenge - making the model make sense to users.
IMO, we need to have a smooth navigation in the header to move between various
workspaces.
Right now we do not have yet a navigational representation of pages.
Will sharing the canonical 'Main' page with john.doe result in two 'Main'
pages to be shown? As the name of a page (currently) is only stored in the
page itself, to prevent 'namespace' clashes, you either need to:
- 'expose' the owner /owner/canonical/ as prefix, (e.g. something like:
/person/canonical/pages/Main), or
- allow the viewer to *locally* rename that page (ugh: Main1, Main2,
Main3), or
- introduce a mounting or shortcut like feature where the viewer can
structure its own 'site' and 'inject' shared pages at any desired location, or
- ...?
Perhaps the "mounted" pages look in some way different to the normal tabs
stylistically (e.g. aligned to the right and a different colour, with a tooltip
along
the lines of "Shared with you by Bob"). Or maybe you have to have a separate
page navigation UI to organise pages - "My pages", "Pages shared with me",
"Public pages" (etc)
I think what approach we take depends on what is sharable. Assuming we go with the
"Workspace" concept, would your users want to share entire workspaces or just
individual groups of regions that we now call pages, or both?
Note: in the above options I'm not referring to page IDs anymore. While
each page can/should still be addressable by ID (too), if you're going to share
pages you'll need *also* a logical naming representation to be able for the
viewer to navigate its own 'site' or even more so a public/anonymous view of
'the' site. Meaning: we'll need to come up with a navigational structure for
pages which can be rendered through menu's, site maps, etc. These IMO
should be accessible and represented as REST resources like the web itself.
Thus hierarchically structured.
Once we get there, I think the workspace vs page discussion becomes easier
and more 'structured'. A workspace then can simply represent a parent (or
root) page resource with optional children which happens to be shared,
somehow.
Important this IMO is a discussion on ownership of a shared page or
workspace, something which was also discussed, but IMO not concluded,
recently on the OpenSocial 3.0 kickoff concerning the Spaces proposal.
I think each page/space/workspace or whatever (Rave) 'social' web
resource should have a canonical owner. Meaning only one. And if you want
to 'share' ownership, then a separate and standalone entity like Group should
be used. Because that will then allow providing both a canonical location (url).
+1 I like the idea of a single owner of any page, even if that owner is a Group:
This is in alignment with the discussions from the OpenSocial 3.0 kickoff.
/portal/app/group/trekkies/profile
/portal/app/group/trekkies/spock
Consider for instance searching (public web or from within the portal) and
finding an entry matching a page or workspace: what or who's canonical url
should be linked to if you would have multiple owners?
There are many different ways to represent a site structure and also many
different ways to logically blend or merge/share/overlay logical structures on
top of it, but I think it would be useful to start with something which as a
minimum provides a canonical representation of the Rave site, and leverage
that as a start for sharing purposes, without any need to 'OK' a shared page
before it becomes 'visible'.
Agreed - a predictable and user-readable URL scheme will help with
understanding how the pages fit together.
At the moment, if you try and access a page without permission, you just get
an error message - this could instead have a dialog to send a message to the
owner that you'd like to be added or otherwise start a flow that could lead to
being added as a page member.
So for example canonical could have the following 'pages':
/portal/app/my/profile
/portal/app/my/profile/about
/portal/app/my/profile/activities
/portal/app/my/pages/main
/portal/app/my/pages/social
I am all for intuitive URL structure and think addressable sub-components could
make sense. For at least one of our use cases, we would want
/portal/app/my/profile/about and /portal/app/my/profile have the same overall
structure with user image etc at the top of the page. Maybe in /about the about
tab could be active?
and have its /profile, /profile/about and /pages/social pages shared with
john.doe
Then, john.doe might be able to see (and have menu/links) to:
/portal/app/my/profile
/portal/app/my/profile/about
/portal/app/my/profile/activities
/portal/app/my/pages/main
/portal/app/my/pages/social
/portal/app/person/canonical/profile
/portal/app/person/canonical/profile/about
/portal/app/person/canonical/pages/social
Of course the above url structure is just an example.
As soon as I have a bit more time I can try to better explain it, but hopefully
it makes sense somewhat.
I did some hacking on the model, controller, and permission evaluator code
today to get the backend of page sharing working, and have passed the baton
to Paul as I don't think I'm going to get any coding time for the next two days.
So we should (I hope) have some working page-sharing to play with by the
end of the week.
Ate
====
Paul and I are really interested in seeing if we can develop something along
the lines of model (1) in a sprint next week as it would be a good fit for a
project we're working on. This wouldn't include the OpenSocial Spaces
extension (I'm sure someone else could implement it later) but would include
the basic functionality of sharing pages, selecting users, and extending the
relevant PermissionEvaluator classes for non-Owner roles.
Support shared spaces
---------------------
Key: RAVE-103
URL: https://issues.apache.org/jira/browse/RAVE-103
Project: Rave
Issue Type: Epic
Reporter: Matt Franklin
Support shared, or common, spaces with group managed pages, widgets,
and security
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira
