Dealing with GroupType Fields in Notes



By: pnuffer

April 25, 2007 2:31 am

Reads: 175

Comments:2

Rating:0

Problem

A Forum reader recently asked:

“I am creating groups in eDirectory that sync over to the Lotus Notes address book. However, they are created as type “multi-purpose” by default, and I want to create them as “security” type groups (ACLs). How would I do this?”

And here’s the response from Perry Nuffer …

Solution

The Group GroupType field is set by default in the NotesDriverShim. The NotesDriverShim has a defect that sets this default GroupType field to “0″ (multi-purpose), even when a GroupType field is provided within the XDS add command received by the NotesDriverShim. In other words, if you attempt to create a group in Notes by sending an input XDS document to the
NotesDriverShim with an ‘add-attr attr-name=”GroupType”‘ and a value of “2″ (Access Control List Only), the NotesDriverShim will create the Group, default the GroupType field to 0, then append the GroupType field value of 2. The problem with this: you probably don’t want your new group to have two GroupType values (0 and 2).

To work around this defect, you can:

1. Set the GroupType field of the known Group on a specific modify command that may suit your needs, by removing the existing value and applying the value of 2.

OR

2. Set the GroupType field after the Group has been added, by catching its add-association event within the input transformation policy set. See the sample policies below (a & b) for how this can be done.

a. In the Subscriber’s creation policy set, insert the following policy:

<?xml version="1.0" encoding="UTF-8"?>
<policy>
  <rule>
    <description>Attach GroupType field fix-up flag to Group add commands</description>
    <conditions>
      <and>
        <if-class-name op="equal">Group</if-class-name>
      </and>
    </conditions>
    <actions>
      <do-set-op-property name="fix-up-notes-GroupType-field">
        <arg-string>
          <token-text xml:space="preserve">true</token-text>
        </arg-string>
      </do-set-op-property>
    </actions>
  </rule>
</policy>

b. In the input transformation policy set, insert the following policy:

<?xml version="1.0" encoding="UTF-8"?>
<policy>
  <rule>
    <description>Check Group's fix-up operation data on add-association</description>
    <conditions>
      <and>
        <if-operation op="equal">add-association</if-operation>
        <if-op-property name="fix-up-notes-GroupType-field" op="equal">true</if-op-property>
      </and>
    </conditions>
    <actions>
      <do-set-src-attr-value class-name="Group" name="GroupType">
        <arg-association>
          <token-xpath expression="text()"/>
        </arg-association>
        <arg-value type="string">
          <token-text>2</token-text>
        </arg-value>
      </do-set-src-attr-value>
    </actions>
  </rule>
</policy>

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags:
Categories: eDirectory, Technical Solutions

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

2 Comments

  1. By:queenw

    Connecting to a Notes 6.5.6 environment and trying to figure out how to deal with the DenyAccess group character (or number of DN entries) limitation. Our Notes admins simply create a new group when the last one fills up, currently up to $DenyAccess89!. Corporate policy requires that these groups stay around for a few years so no way to simply delete down to a known quantity.

    Any thoughts on how an IDM driver can deal with this situation? Maybe query Notes from the subscriber channel to determine the latest DenyAccess group name?

    Thanks,
    Wes Queen

  2. By:geoffc

    QueenW asked how to handle the Deny Access group issue, in that Notes indvidual attributes have something like a 32K or 64K size limit (I forget, Notes 6 and 7 are different sizes, but neither is large enough really).

    What you need to do is find a way to automate the way that the Deny Access groups UNID could get updated within the driver. Currently it is stored within a GCV in the driver object.

    To make a change in a GCV, a driver restart is needed.

    You could potentially track down the rules that reference that GGV and replace it with a Map token, that pulls the value from a Mapping table.

    What this buys you is that Mapping tables are re-read on the fly, so you could (in IDM 3.5.1 and higher) give the Notes admin enough rights to just modify the attribute of the Mapping tables value in the driver set (Perhaps with an LDIF, he just runs and each time he makes a new Deny Access group, he has to paste the current UNID into the LDIF file and run a script that updates the table.

    That may be a step better, but not 100% of what you want.

Comment