Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] USDU delete subjects after unresolvable for X days

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] USDU delete subjects after unresolvable for X days

Chronological Thread 
  • From: "Hyzer, Chris" <>
  • To: "Black, Carey M." <>, "Gettes, Michael" <>
  • Cc: "" <>
  • Subject: RE: [grouper-dev] USDU delete subjects after unresolvable for X days
  • Date: Wed, 6 Feb 2019 21:26:05 +0000

I updated the wiki so you can have settings per source too... we have a
solution for individual deprovisioning, we need something for mass
deprovisioning... we should consider USDU when we tackle that


-----Original Message-----
From: <>
On Behalf Of Black, Carey M.
Sent: Wednesday, February 06, 2019 4:05 PM
To: Gettes, Michael <>
Subject: RE: [grouper-dev] USDU delete subjects after unresolvable for X days


My concern is if the subject it removed before the membership are _processed_
by the "deprovisioner".
Things in Grouper are not instantaneous. ( More like "short time
bounded batches". And there are different queues and processes that are not
guaranteed to be serialized nor synchronized. )

If the USDU removes the memberships AND deletes the subject (in a single
pass), the likely hood of the deprovisioners would have ANY data about the
subject is just about zero. ( All the data would need to be "on the
Membership" being removed, and that still depends on Attribute point in time
data sources too. )

However, If the deprovisioning process needs Subject data ( that might be
cached in Grouper attributes on the subject ) to deprovision then it is
likely not able to do what it needs to do.

However, if the process is that the USDU removes the memberships and waits to
delete the subject until all of those memberships have been processed by all
provisioners ( AKA: change log consumers) before the subject is deleted in
grouper, then the local Grouper data integrity can sustain the Grouper based

So to me, the USDU should look like a multi-phase process (with a time
delay/verification check before the next phase for that subject) to not break
the deprovisioning processes.

I don't think Wiki's are a good space to make a feature request. (
That what things like Jira are for. :) )
And I am trying to talk through the details before a formal
request/altered request is made. Mostly because I am very open to the reality
that I may not be seeing something that others might. :)
( I like discussing details to build full plans. :) )

Carey Matthew

-----Original Message-----
From: Gettes, Michael <>
Sent: Wednesday, February 6, 2019 3:15 PM
To: Black, Carey M. <>
Subject: Re: USDU delete subjects after unresolvable for X days

USDU is supposed to remove the subject from all groups it is a member of as
part of it’s processing. So I think 2 is a non-issue. Different schedules
for different subject sources is certainly an interesting point and one I
hadn’t thought of. As I hope Chris would agree - you should definitely add
this to the wiki page so it gets taken into account.


> On Feb 6, 2019, at 12:59 PM, Black, Carey M. <> wrote:
> Michael,
> RE:
> While I understand the idea of this request, there might be some unintended
> consequences if other things are not considered.
> 1) some subject sources might need to be treated differently than others.
> Maybe different timelines (remove after N days),
> Maybe different logic based on that source. ( some sources may never
> need cleaned., or only yearly? )
> Some might expect to see lots of subject changes, others might expect
> very view. ( so a single "failsafe" might be high for some and low for
> others.)
> 2) if an USDU subject is still "provisioned" to some downstream system then
> there may be other problems caused by removing the Subject from the
> downstream system after the USDU scrubs the subject from grouper.
> Maybe there needs to be a step that identifies the unresolvable
> subject that triggers downstream provision/de-provision processes before
> the subject is removed.
> What are your thoughts along those lines?
> --
> Carey Matthew

Archive powered by MHonArc 2.6.19.

Top of Page