Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] PITGroup assigned attributes?

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] PITGroup assigned attributes?


Chronological Thread 
  • From: "Hyzer, Chris" <>
  • To: "William G. Thompson, Jr." <>
  • Cc: Grouper Dev <>, Shilen Patel <>
  • Subject: RE: [grouper-dev] PITGroup assigned attributes?
  • Date: Mon, 22 Feb 2016 05:42:33 +0000
  • Accept-language: en-US
  • Authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=isc.upenn.edu;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:23

Sure. Maybe a provisioning tab on the groups/folders in the new UI? Shows
where provisioned and allows people with the ability to change that
designation? Do we think a marker is all we need or also some metadata
(name/value string attributes on assignment)?

Thanks
Chris

-----Original Message-----
From: William G. Thompson, Jr.
[mailto:]

Sent: Sunday, February 21, 2016 4:12 PM
To: Hyzer, Chris
<>
Cc: Grouper Dev
<>;
Shilen Patel
<>
Subject: Re: [grouper-dev] PITGroup assigned attributes?

Thinking ahead a little bit (assuming this all works out at least for
some cases) wondering what folks thoughts are on:
1) a standard set of consumers and syncAttribute marks to mark them with
2) some visual indication on folders and groups in the UI that they've
been marked for one or more of the sync consumers

Imagining a deployer configuring the standard set via properties, then
using the Grouper UI or gsh to mark the appropriate folders or groups,
and be good to go.

Best,
Bill

On Sun, Feb 21, 2016 at 3:59 PM, William G. Thompson, Jr.
<>
wrote:
> Working on the expect behavior as test cases as described here:
> https://gist.github.com/wgthom/9e40ea12d48aa1bb1c6d
>
> On the right track? Any tips on automating these? (going to try some
> basic gsh scripts to start with)
>
> Best
> Bill
>
>
>
> On Sun, Feb 21, 2016 at 11:18 AM, William G. Thompson, Jr.
> <>
> wrote:
>> By "indirect marked group" I mean groups that are being synced because of a
>> mark on a parent folder. The consumer just deals with effective membership
>> with regards to grouper groups within groups. Make sense?
>>
>> On Feb 21, 2016 9:48 AM, "Hyzer, Chris"
>> <>
>> wrote:
>>>
>>> Why do you have to worry about indirectly marked groups (group as a member
>>> of a marked group)?
>>>
>>> Don’t you just have to manage the members that are added/removed as a
>>> result which will flow through the change log? And ignore the indirect
>>> group markings?
>>>
>>> Thanks,
>>> Chris
>>>
>>> -----Original Message-----
>>> From:
>>>
>>> [mailto:]
>>> On Behalf Of William G. Thompson,
>>> Jr.
>>> Sent: Sunday, February 21, 2016 9:21 AM
>>> To: Shilen Patel
>>> <>
>>> Cc: Grouper Dev
>>> <>
>>> Subject: Re: [grouper-dev] PITGroup assigned attributes?
>>>
>>> Yes, here are the cases (so far) that I'm considering:
>>>
>>>
>>> https://docs.google.com/spreadsheets/d/1AK8v7m_MAzuByZa0PTV4JUmBlIBe99i-ZDUPUBIyR64/edit?usp=sharing
>>>
>>> Place a marker on a folder
>>> Place a marker on a group
>>> Remove a marker from a group
>>> Remove a marker from a folder
>>> Add an indirectly marked group
>>> Delete a directly marked group*
>>> Delete an indirectly marked group*
>>> Membership add on a marked group (direct or indirect)
>>> Membership delete on a marked group (direct or indirect)
>>>
>>> * note grouper will remove all memberships (and issue change log
>>> events) before the group is deleted. which will cause the target to
>>> also remove all memberships before the group is removed. correct?
>>> (possible work around? might just need to remove the group at the
>>> target in this case)
>>>
>>> Best,
>>> Bill
>>>
>>>
>>>
>>> On Sun, Feb 21, 2016 at 8:44 AM, Shilen Patel
>>> <>
>>> wrote:
>>> > You're still looking at add group and delete group to handle cases where
>>> > a
>>> > parent folder is marked? If so, this makes sense to me.
>>> >
>>> > - Shilen
>>> >
>>> > On 2/20/16, 11:07 AM, "William G. Thompson, Jr."
>>> > <>
>>> > wrote:
>>> >
>>> >>OK. Here's a gist of the marker attribute assign add and delete:
>>> >>https://gist.github.com/wgthom/5807e6c2b1900e432400
>>> >>
>>> >>attributeAssign_addAttributeAssign { /** * On assignment of the
>>> >>syncAttribute marker, create all the groups or group (if directly
>>> >>assigned) * and any current memberships at the target. */
>>> >>
>>> >>attributeAssign_deleteAttributeAssign { /** * On removal of the
>>> >>syncAttribute marker, delete all the groups or group (if directly
>>> >>assigned) at the target, unless * otherwise still marked by direct
>>> >>assignment or a parent folder. */
>>> >>
>>> >>Making sense?
>>> >>
>>> >>Best,
>>> >>Bill
>>> >>
>>> >>
>>> >>On Fri, Feb 19, 2016 at 2:29 PM, Shilen Patel
>>> >><>
>>> >> wrote:
>>> >>>
>>> >>> >> If the attribute assign delete is guaranteed to be in the change
>>> >>> >> log
>>> >>>on group and folder deletes then I should be able to key off of that?
>>> >>>
>>> >>> That's what I would do :) and have done with change log consumers I've
>>> >>>built that sync based on attribute assignments. Maybe Chris has other
>>> >>>thoughts.
>>> >>>
>>> >>> Thanks!
>>> >>>
>>> >>> - Shilen
>>> >>>
>>> >>> From: "<William G. Thompson>", "Jr."
>>> >>> <>
>>> >>> Date: Friday, February 19, 2016 at 2:25 PM
>>> >>> To: Shilen Patel
>>> >>> <>
>>> >>> Cc: Grouper Dev
>>> >>> <>
>>> >>>
>>> >>> Subject: Re: [grouper-dev] PITGroup assigned attributes?
>>> >>>
>>> >>> Removing the marker attribute from a group or folder would be saying I
>>> >>>no longer want this group or set of groups provisioned to the target.
>>> >>>So that case would be a group delete at the target.
>>> >>>
>>> >>> If the attribute assign delete is guaranteed to be in the change log
>>> >>> on
>>> >>>group and folder deletes then I should be able to key off of that?
>>> >>>
>>> >>> Best,
>>> >>> Bill
>>> >>>
>>> >>>
>>> >>> On Fri, Feb 19, 2016 at 7:42 AM, Shilen Patel
>>> >>> <>
>>> >>> wrote:
>>> >>>>
>>> >>>> Sure, if that would make things easier for you. Feel free to create
>>> >>>> a
>>> >>>>jira. :)
>>> >>>>
>>> >>>> I think one issue with your PIT code is that the attribute may have
>>> >>>>been assigned to the group, but then later unassigned. And then
>>> >>>>sometime (potentially long) after, the group was deleted. You'd still
>>> >>>>see that the group had the attribute assigned in the past, but would
>>> >>>>have to look at the time or context to see if it was part of the group
>>> >>>>delete operation.
>>> >>>>
>>> >>>> Though I'm wondering.. If your sync'ing is based on attribute
>>> >>>>assignments, I don't see change log events for assign adds and
>>> >>>> deletes.
>>> >>>> When a group is deleted, if the attribute was assigned at the time of
>>> >>>>deletion, you'd get the attribute assign delete before the group
>>> >>>>delete. So you'd know it was actually being sync'ed by the first
>>> >>>>event. I'm guessing you'd still want to look at the group deletes too
>>> >>>>in case the folder (or ancestor folder) had the attribute.
>>> >>>>
>>> >>>> Thanks!
>>> >>>>
>>> >>>> - Shilen
>>> >>>>
>>> >>>> From: "<William G. Thompson>", "Jr."
>>> >>>> <>
>>> >>>> Date: Thursday, February 18, 2016 at 10:26 PM
>>> >>>> To: Grouper Dev
>>> >>>> <>
>>> >>>> Subject: Re: [grouper-dev] PITGroup assigned attributes?
>>> >>>>
>>> >>>> For checking for the syncAttribute marker...
>>> >>>>
>>> >>>> This is working for groups that are still in the registry.
>>> >>>> group.getAttributeDelegate().hasAttributeOrAncestorHasAttribute(...)
>>> >>>>
>>>
>>> >>>> >>>>https://gist.github.com/wgthom/f34fb9edfe3029febf5b#file-isgroupmarkedfo
>>> >>>>rsync-java-L15
>>> >>>>
>>> >>>> And this is working for deleted groups in the PIT:
>>> >>>>
>>>
>>> >>>> >>>>https://gist.github.com/wgthom/f34fb9edfe3029febf5b#file-isgroupmarkedfo
>>> >>>>rsync-java-L22
>>> >>>>
>>> >>>> Would it make sense to have something like:
>>> >>>> pitGroup.hasPITAttributeAssignOrAncestorHasPITAttributeAssign(...)
>>> >>>>
>>> >>>> Best,
>>> >>>> Bill
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Thu, Feb 18, 2016 at 8:58 AM, William G. Thompson, Jr.
>>> >>>><>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> Thanks, Shilen. That looks exactly like what I need.
>>> >>>>>
>>> >>>>> This is still very much a work in progress, but would appreciate any
>>> >>>>> thoughts on the code or direction.
>>> >>>>>
>>> >>>>> Base "Group and Membership" consumer
>>> >>>>>
>>>
>>> >>>>> >>>>>https://gist.github.com/wgthom/cf129f9f33fdfdad5148#file-changelogconsu
>>> >>>>>merbaseimpl-java
>>> >>>>>
>>> >>>>> Example "Group and Membership" consumer implementation for a target
>>> >>>>>
>>>
>>> >>>>> >>>>>https://gist.github.com/wgthom/54e08c7d44b802f720ce#file-printchangelog
>>> >>>>>consumer-java
>>> >>>>>
>>> >>>>> Best,
>>> >>>>> Bill
>>> >>>>>
>>> >>>>> On Thu, Feb 18, 2016 at 7:48 AM, Shilen Patel
>>> >>>>> <>
>>> >>>>> wrote:
>>> >>>>> > Hi Bill,
>>> >>>>> >
>>> >>>>> > Take a look at PITAttributeAssignFinder. Let me know if that
>>> >>>>>doesn't give
>>> >>>>> > you what you need.
>>> >>>>> >
>>> >>>>> > Thanks!
>>> >>>>> >
>>> >>>>> > - Shilen
>>> >>>>> >
>>> >>>>> > On 2/17/16, 9:25 PM, "William G. Thompson, Jr."
>>> >>>>> > <>
>>> >>>>>wrote:
>>> >>>>> >
>>> >>>>> >>I'm working on a ChangeLogConsumer to sync groups and membership
>>> >>>>> >> to
>>> >>>>>a
>>> >>>>> >>target (in this case Office365), but it could be used for any
>>> >>>>>target.
>>> >>>>> >>
>>> >>>>> >>The current design calls for a marking attribute to be assigned to
>>> >>>>> >>groups or folders. If the attribute is assigned to a group it is
>>> >>>>> >>marked for provisioning. If the attribute is assigned to a folder
>>> >>>>>all
>>> >>>>> >>the groups within the folder and any sub folders are marked for
>>> >>>>> >>provisioning.
>>> >>>>> >>
>>> >>>>> >>As the changeLogEvents come though I can check the group or parent
>>> >>>>> >>folders for the mark. So far so good. However when a deleted group
>>> >>>>> >>changeLogEvent comes through for a directly marked group, the
>>> >>>>> >> group
>>> >>>>>is
>>> >>>>> >>already deleted so I can't query the group for attribute
>>> >>>>>assignments.
>>> >>>>> >>I can get the PITGroup, but it doesn't seem to provide access to
>>> >>>>> >>PITAttribtueAssignments.
>>> >>>>> >>
>>> >>>>> >>Is this possible somehow?
>>> >>>>> >>
>>> >>>>> >>Best,
>>> >>>>> >>Bill
>>> >>>>> >
>>> >>>>
>>> >>>>
>>> >>>
>>> >



Archive powered by MHonArc 2.6.16.

Top of Page