Details

    • Type: Epic Epic
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Support shared, or common, spaces with group managed pages, widgets, and security

        Issue Links

          Issues in Epic

          There are no issues in this epic.

            Activity

            Hide
            Anthony Carlucci added a comment -

            Paul, one thought I had is that we could make the "args" parameter object in the rave.toggleCollapseAction(args) function take an additional "persist" boolean property to control whether or not we should persist the action. For example something like:

            var args = {};
            args.data = {};
            args.data.id = 1;
            args.persist = false;
            toggleCollapseAction(args);

            then at line 472 of rave.js you could change the if to something like:
            if (rave.isMobile() || args.persist == false)

            { rave.doWidgetUiCollapse(functionArgs); }

            else

            { // the persist code }
            Show
            Anthony Carlucci added a comment - Paul, one thought I had is that we could make the "args" parameter object in the rave.toggleCollapseAction(args) function take an additional "persist" boolean property to control whether or not we should persist the action. For example something like: var args = {}; args.data = {}; args.data.id = 1; args.persist = false; toggleCollapseAction(args); then at line 472 of rave.js you could change the if to something like: if (rave.isMobile() || args.persist == false) { rave.doWidgetUiCollapse(functionArgs); } else { // the persist code }
            Hide
            Paul Sharples added a comment -

            I've been thinking about point #1 above. In some cases a shared user will have access to persist the collapsed state. (this could eventually be one of the things the 'canEdit' field will allow, when implemented). In other cases a shared user who cannot persist the state, should still be able to min/restore the gadget in his/her own view, but the state would not be persisted. (also without seeing a browser alert message) I think as the action causes an 'info' type message in 'AbstractRestApi', perhaps it might be better to make it less verbose and look less like an error message with full stack trace. I have attached a simple patch to illustrate what I have in mind.

            Show
            Paul Sharples added a comment - I've been thinking about point #1 above. In some cases a shared user will have access to persist the collapsed state. (this could eventually be one of the things the 'canEdit' field will allow, when implemented). In other cases a shared user who cannot persist the state, should still be able to min/restore the gadget in his/her own view, but the state would not be persisted. (also without seeing a browser alert message) I think as the action causes an 'info' type message in 'AbstractRestApi', perhaps it might be better to make it less verbose and look less like an error message with full stack trace. I have attached a simple patch to illustrate what I have in mind.
            Hide
            Fernando Pinhati added a comment -

            #1 - Ok. However, collapse/expand actions really throw Java Exceptions, while all others persistent actions do not...

            #2 - Ok.

            Show
            Fernando Pinhati added a comment - #1 - Ok. However, collapse/expand actions really throw Java Exceptions, while all others persistent actions do not... #2 - Ok.
            Hide
            Matt Franklin added a comment -

            #1 Collapse in Rave is persistent, which means that a non-owner Page User collapsing a widget would be editing the page. Canvas is not persistent.

            #2 Ideally, it would be sharable to any object in the user's social graph. Depending how you implement the graph, it could be all users (IE in a company intranet) or the user's friends.

            Show
            Matt Franklin added a comment - #1 Collapse in Rave is persistent, which means that a non-owner Page User collapsing a widget would be editing the page. Canvas is not persistent. #2 Ideally, it would be sharable to any object in the user's social graph. Depending how you implement the graph, it could be all users (IE in a company intranet) or the user's friends.
            Hide
            Paul Sharples added a comment -

            Yes, it sounds as if #1 needs to be fixed, possibly a permission issue - i will look into it.

            #2. Yes, although the first iteration allows you to add other rave users individually, I had envisaged that at a later stage, a user could choose 'groups' of users, perhaps one group being friends or even another user defined group of users.

            Paul

            Show
            Paul Sharples added a comment - Yes, it sounds as if #1 needs to be fixed, possibly a permission issue - i will look into it. #2. Yes, although the first iteration allows you to add other rave users individually, I had envisaged that at a later stage, a user could choose 'groups' of users, perhaps one group being friends or even another user defined group of users. Paul
            Hide
            Fernando Pinhati added a comment -

            Hi,

            I'm testing the Shared Pages feature and I've got the following issues/ideas:

            (1) When the owner of a Shared page collapse some widget on the page, it's not possible to the viewer to expand the collapsed widget, an error message is alerted (Forbidden) and a Java exception is thrown. But it's possible to maximize the widget... I know that the 'canEdit' feature is not implemented, but I think that expanding a widget is not an edit action (like maximizing it).

            (2) As a page owner, I can share my page with all Rave users. Why not to share only with my friends? Share with all users may confuse the concept of connected people, that is important on a social environment...

            Show
            Fernando Pinhati added a comment - Hi, I'm testing the Shared Pages feature and I've got the following issues/ideas: (1) When the owner of a Shared page collapse some widget on the page, it's not possible to the viewer to expand the collapsed widget, an error message is alerted (Forbidden) and a Java exception is thrown. But it's possible to maximize the widget... I know that the 'canEdit' feature is not implemented, but I think that expanding a widget is not an edit action (like maximizing it). (2) As a page owner, I can share my page with all Rave users. Why not to share only with my friends? Share with all users may confuse the concept of connected people, that is important on a social environment...
            Hide
            Paul Sharples added a comment -

            I've added the shared pages feature to svn. This is based on the patch originally submitted here https://reviews.apache.org/r/4843/.

            Show
            Paul Sharples added a comment - I've added the shared pages feature to svn. This is based on the patch originally submitted here https://reviews.apache.org/r/4843/ .
            Hide
            Paul Sharples added a comment -

            I've been working on the page sharing functionality described by Scott in (1) above. Rather than commit the code, I've put it up as a patch so to invite comment.
            Some points...

            (1) A user can share a page with another rave user. Choosing share from the page menu allows you see a dialog box where you can add new users.
            (2) Once another user logs in who has a new page share, a dialog should appear asking them to "accept" or "decline" the share.
            (3) For now at least - a shared page appears with a little person icon in the tab view (also it happens to be a shade of green so that its easy to identify as a shared page.)
            (4) The user can remove the shared page at a later stage if they want to.
            (5) The original page owner can grant and revoke page share status to each user.

            I moved the pagesequencing values out of the page object and into the new pagerUser object. This allows several users to move sharedpages around within their tab sequence and have different rendersequences. (originally the rendersequencing was tied to the page object itself)

            Theres still plenty more to do on it yet. (For example the 'canEdit' role isn't implemented, and locking regions/widgets to shared users)

            Show
            Paul Sharples added a comment - I've been working on the page sharing functionality described by Scott in (1) above. Rather than commit the code, I've put it up as a patch so to invite comment. Some points... (1) A user can share a page with another rave user. Choosing share from the page menu allows you see a dialog box where you can add new users. (2) Once another user logs in who has a new page share, a dialog should appear asking them to "accept" or "decline" the share. (3) For now at least - a shared page appears with a little person icon in the tab view (also it happens to be a shade of green so that its easy to identify as a shared page.) (4) The user can remove the shared page at a later stage if they want to. (5) The original page owner can grant and revoke page share status to each user. I moved the pagesequencing values out of the page object and into the new pagerUser object. This allows several users to move sharedpages around within their tab sequence and have different rendersequences. (originally the rendersequencing was tied to the page object itself) Theres still plenty more to do on it yet. (For example the 'canEdit' role isn't implemented, and locking regions/widgets to shared users)
            Hide
            Scott Wilson added a comment -

            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

            ====

            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.

            Show
            Scott Wilson added a comment - 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 ==== 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.

              People

              • Assignee:
                Unassigned
                Reporter:
                Matt Franklin
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Development