This policy in the output transform is used to rename about-to-be-deleted
objects in Google, because Google doesn't immediately delete objects, it
leaves them around for a while. By renaming them, first, the driver
ensures that a later <add> event won't error out because the new object
name conflicts with a deleted but not yet purged object in Google.

For some time now, I've been ignoring a problem here where a user account
is deleted (account lifecycle), so it gets renamed and deleted in Google,
but then the user returns to an active status. What I've been seeing
happen, if they come back during the period where Google has marked the
account as deleted, but has not yet purged it, is that the driver hits
the matching rule, finds the deleted account, and restores it.

That would be fine, except that what the driver doesn't do is rename the
restored account back to what it used to be named before this rename-then-
delete policy was applied to it. So what I see is student (z025853) has a
Google account (

He gets deleted, so in Google I see him renamed and deleted as

He comes back, so I see the driver process an <add> for him, the matching
rule finds him, and he ends up restored as

I have this in old traces, and can see it happening like:

<modify class-name="UserEntry" event-id="LidGen
Input#Publisher#0:7e671a46-e021-4f8b-8d77-1e135e4d07f7" from-merge="true"
qualified-src-dn="O=NIU\OU=Users\CN=Z025853" src-dn="\NIU-FLAT\NIU\Users
\Z025853" src-entry-id="905613">
<modify-attr attr-name="GivenName">
<value timestamp="1416192435#4" type="string">David</value>
<modify-attr attr-name="FamilyName">
<value timestamp="1416192435#5" type="string">Gersic</value>
<modify-attr attr-name="IsSuspended">
I had a few minutes while waiting on somebody else to do something, so I
thought I'd see about fixing this. It seemed that it should be possible
to catch the <modify> with the @from-merge=true on it, and rename the
restored account back to what it should be ( It
turns out not to be quite that simple, but I don't understand why not.

In watching the trace now, I don't see the driver matching policies find
the deleted account. So, with no match, there's no <modify @from-
merge=true> to do anything with. The <add> proceeds through the usual
processing, and a new account is created.

I suspect that this is a change in how the shim and the back end Google
API work. I think the old shim, prior to spring 2015, and the old Google
API worked one way, and the new shim, with the new Google API, work
differently in this regard. If so, then it seems to me that NOVLGGLEUSER-
sub-otp_HandleDeleteEvents is no longer relevant and could be removed
from the Google Apps User Package.

The point of this rename was to stop name collisions with deleted
objects. If I delete an object now, and create a new one that should
conflict, it doesn't. The matching rules that used to find the deleted
object by its alias, no longer do, so the <modify> never happens, and I
can't therefor catch the <modify> and add a <rename> to it.

I'm thinking, therefor, that NOVLGGLEUSER-sub-otp_HandleDeleteEvents is
no longer needed, and could be removed.

Alternately, I'm missing something here and I should be seeing the
Matching Rules find the deleted account, but I'm not.

David Gersic
Knowledge Partner

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.