1 Reply Latest reply: Jan 23, 2012 9:20 AM by snmdla RSS

    Beehive enhancement for tomorrow: re-add the OBEO sub folder sharing option

    snmdla
      OK, I inadvertently posted a comment meant for an enhancement to be posted tomorrow, so here we go with tomorrows enhancement of the day:

      Talking once more about delegation... There's quite a big fly in the ointment we need to talk about:

      While delegation granting dialogues in OBEO and bcentral take care of permissions for default folders like inbox, sent items, drafts etc. and pseudo folders like calendar or contacts, it does not so for non-default folders.

      We have the case of a superior that has a widely ramified folder structure and granted his secretary access to parts of it. When the secretary changed he changed delegation, and this did not change the non-default acls.

      So far nothing unspectacular. The issue is, that there is no option in OBEO to define permissions tree-wise (nor is there in beectl), so the superior had to walk the whole directory hierarchy to adapt the permissions, each folder requiring multiple clicks.

      There was a permissions dialogue for that in OBEO 1.5, but has been dropped.

      There is an enhancement request I'd ask you to second through MOS:

      10065126: READD THE SUB FOLDER SHARING OPTION TO OBEO

      This ER had the status approved for future release, but product management changed its plans and put it to "Suggestion Rejected".

      a related ER is the following:

      12557969: OBEO PERMISSIONS DIALOGUE SHOULD HAVE A TREE OPTION

      "The Beehive platform is designed from the ground up to be easy to manage." (cited from "Oracle Beehive: A Flexible Collaboration Platform for the Enterprise") - let's hope product management will give us tree perms management, at least in OBEO.

      Thanks, Tom
        • 1. Re: Beehive enhancement for tomorrow: re-add the OBEO sub folder sharing option
          snmdla
          As currently product management does not seem to be considering
          readding the desired dialogue (nor a tree switch for beectl perms
          related commands) lets look at our workaround.

          Lets look at it in an example: user user_a has set up a delegation to
          user_b, allowing access to his inbox.

          If you have set this up (using OBEO or BCentral as alternatives) a new
          Principal Record has emanated, that you can list with "beectl
          list_users":

          bhowner@bhhost:~> beectl list_users email addr@mydomain show more


          Display Record: 1
          ===========================================
          User Identifier: user=user_a
          Family Name: user_a

          ...
          Principal Record: 6
          ===============
          Principal Identifier: pcpd=145F:5618:user:9B37CFDA0D624736B413FEF81573597400000000000E -> 145F:5618:user:D8D547BB10AD4C079CE3A2604996535B000000000000,user=user_a
          Principal Name: 145F:5618:user:9B37CFDA0D624736B413FEF81573597400000000000E -> 145F:5618:user:D8D547BB10AD4C079CE3A2604996535B000000000000
          Delegated Principal: Yes
          DELEGATOR: user=user_a
          DELEGATED TO: user=user_b
          Lock status: UNKNOWN.

          bhowner@bhhost:~>

          An ACL to the inbox has been generated:

          bhowner@bhhost:~> beectl list_local_acl --entity "fldr=Inbox,wksp=user_a's Personal Workspace,enpr=myenpr"

          ------------------------------------------------------------------+-------------
          accessor | access_types
          ------------------------------------------------------------------+-------------
          ...
          ------------------------------------------------------------------+-------------
          pcpd=145F:5618:user:9B37CFDA0D624736B413FEF81573597400000000000E | +RWDO
          -> 145F:5618:user:D8D547BB10AD4C079CE3A2604996535B000000000000,us |
          er=user_a |
          ------------------------------------------------------------------+-------------

          Listed LocalACL for entity 'fldr=INBOX,wksp=user_a's Personal Workspace,enpr=myenpr'

          bhowner@bhhost:~>

          Now we need to generated similar ACLs for all subfolders of
          exampl-fldr, which, being a non-default folder, did not receive any
          ACL:

          So let's connect to BEE_DATA on the BEEDB, preferrable through SQLDeveloper, and run

          SELECT 'beectl add_local_ace --entity "'
          ||trim(TO_CHAR(c.enterprise_id,'0XXX'))
          ||':'
          ||trim(TO_CHAR(c.site_id,'0XXX'))
          ||':'
          ||c.container_type
          ||':'
          ||c.eid
          ||'" --accessor "pcpd=145F:5618:user:9B37CFDA0D624736B413FEF81573597400000000000E -> 145F:5618:user:D55B885774B6457AA0489F596D7DF873000000000000,user=user_a" --access_types "+RWDO"'
          -- , f.name,
          -- , c.path
          FROM bee_data.ws_real_folders f,
          bee_data.ocs_containers c
          WHERE f.eid=c.eid
          AND c.path LIKE '/dla/user_a''s Personal Workspace/exampl-fldr%'
          AND c.container_type='afrh'

          This will generate the beectl commands necessary to work around the
          missing switch. You need to run those commands afterwards.

          Of course this is not supported, but your only alternative is
          right-clicking all of the subfolders of exampl-fldr and grant the new
          user access manually.

          I would be happy if Oracle would enhance this are of user and rights
          management of beehive.

          Regards, Tom

          Edited by: snmdla on Jan 23, 2012 4:20 PM