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. > > 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'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. > > 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) > > 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: /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 > > 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 >> >> >
