On 03/23/2012 07:59 PM, Cooper, Sean D. wrote:
-----Original Message----- From: Ate Douma [mailto:[email protected]] Sent: Monday, March 19, 2012 9:52 AM To: [email protected] Subject: Re: [jira] [Commented] (RAVE-103) Support shared spaces 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 menuselects "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 multiplepages 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 differentIMO 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'. 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). I'm interested in how adding a shared page to the users view of pages will work out. 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 - ...? 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). 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?-1
Right :) IMO you're a bit too quick to throw in a -1. Typically it is better to first express your concern, like as you do below, and discuss the matter a bit more to see if there really are conflicting goals and if so how we can resolve them in a way satisfactory for all. And I this case, if I understand your concerns below correctly, I think its more likely we have a misunderstanding than conflicting goals.
I have a use case where I don't want a canonical user to own the workspace.
> If I create a workspace page which should live on for 4+ years I cannot
guarantee that the individual who first created it will still be responsible for the workspace or even an employee for the life of that workspace.
That make sense, and I agree it should be possible for a workspace to 'survive' its original creator/owner if so needed.
I would like the ability to create workspace pages in a non-owner/group way, e.g. /portal/app/workspace/## where ## is the id of the workspace that you are working with.
Here I think or POVs are deviating :)
Permissions should be attached to the page and updatable by an admin in case the original set of people change work focuses and or positions in the company.
OK, so lets see if this can be solved in a way which hopefully fits your use-case as well.
In my proposal there should always only be one canonical 'owner' of a page or space. That is: at a certain time. However, that doesn't (have to) mean this ownership isn't transferable. So, if for instance an 'employee' owner leaves the company, this ownership could very well be transferred to someone else, by an admin, or at least 'control' be taken over by an admin (becoming the new owner).
Alternatively, the ownership could be assigned to a specific group (which is *not* an OpenSocial group in the current model for sure), and individuals can be added/removed from this group as desired (by the group itself or an admin). Such a group is 'owned' by the organization (controlled by an admin) and probably functionally related to this page/workspace. If people change work focuses and/or position should not affect the 'role' of this group IMO. And if it does, it always remains possible to 'reassign' the ownership to another group or even another individual.
IMO none of the above should conflict with your requirements but it does allow maintaining a single canonical 'owner' at any time. And that is IMO critical because otherwise it is impossible to maintain a single point of responsibility. And from application and end-user perspective, it means every page/space will have a single/canonical address space (URL if you want).
Also note that I only gave an example of an url namespace which for convenience and simplicity references a Rave user, that doesn't imply any restriction or limitation to use a completely different url naming scheme for your custom portal. So a /portal/app/workspace/## can very well be 'owned' by an admin, a group or a specific user, however you'd like to configure that. And if you only want an admin to be able to maintain such workspaces, simply make the admin the owner or better yet: define a separate 'admin' group for that purpose.
If the above doesn't satisfy your requirements, then please explain where it doesn't fit.
Our goal here is to provide a solution generic enough for all practical use-cases so if it doesn't yet cover that we'll need to figure out a way to make that possible.
Regards, Ate
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'. 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 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. Ate==== Paul and I are really interested in seeing if we can develop something alongthe 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, andsecurity-- 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.jspaFor more information on JIRA, see: http://www.atlassian.com/software/jira
