Grouper Developers Forum

["William G. Thompson, Jr." <>]

On Mon, Feb 22, 2016 at 12:42 AM, Hyzer, Chris 
<>
 wrote:
> 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?

Yes, I also imagine there will be many cases where the groups are
sync'd to multiple targets.  So some visual indication on the
folder/group icon and then the tab is see the details?

> Do we think a marker is all we need or also some metadata (name/value 
> string attributes on assignment)?

Don't know, at the moment I'm thinking that connection details for the
consumers would just go in grouper-loader.properties.

Best,
Bill


>
> 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
>>>> >>>>> >
>>>> >>>>
>>>> >>>>
>>>> >>>
>>>> >