Novell Identity Manager has a number of tools you can use for editing and managing policy.

The original tool was actually Console One in the DirXML 1.1a timeframe. There was a Console one snapin that was actually nice. It exposed the XML stored as an attribute in a page you could edit.

In principle that still works if you want to edit the raw XML by hand. Now in Console One you would just find the Policy object you want to edit, select the Other tab, and the XML is stored in an attribute called XMLData.

Probably not the most efficient way to do it, but when all else fails it is pretty useful to know this is an option.

Novell iManager is the next way, and the snapins for iManager have gotten better with each release. The current set coming for the release of Novell Identity Manager 3.6 are just plain awesome! They have added a lot more AJAX style interface widgetry and it turns out to be quite powerful. Beyond that they have added support for new features coming with each release of Identity Manager.

To get the latest builds of the newest snapins, they have posted a landing page at:
http://www.novell.com/coolsolutions/dirxml/imanager/

I highly recommend these new snapins. The authors pay attention in Novell Support forums, (forums.novell.com on both HTTP and NNTP) and if you have a feature request, a change to make it work better, or so on, please post there, as they are listening, and I know personally they have added and changed a few things that I wanted.

The latest tool is Designer for Identity Manager. The official release is currently 2.1.1 that ships with Identity Manager 3.5. The most advanced build is the 3.0 build that is under active development right now, to be ready to be released with the Identity Manager 3.6 release that is coming out soon.

You can find all the builds, the released build, a stable build of 3.0, along with nightly builds that are the latest and greatest bleeding edge, (that while they may have the bug fix you needed, they may also have introduced a regression you will regret) at the Designer landing page:
http://www.novell.com/coolsolutions/dirxml/designer/

As with the iManager snapins, definitely follow the Designer forum on the Novell Support forums as the Designer team is actively watching for bug reports to get fixed in the latest builds. This is a wonderful support loop, where you can find a bug, report it, get it fixed, and it shows up in the next nightly build.

I happen to be a big fan of using Global Configuration Values (GCV) wherever possible that makes sense. These are great for things like paths for object placement in the tree, since I often develop in a test lab environment with one tree name, and deploy for production in another tree. If I have a GCV that describes the active user container (lets call it acemActiveUserContainer) and one that describes the disabled user container, (acmeDisabledUserContainer) then every time I reference one of those paths for objects, I use the GCV instead of the actual path.

When it comes time to move from test to production, I change the GCV's in the Driver Set object after I import it to match the locations in production, and that saves me a lot of work. Searching the drivers for all references to the absolute path could take a long time. Check out the series on doing just that for the Active Directory driver, if you are interested.

http://www.novell.com/communities/node/4335/how-gcvize-a-driver-part-1-subscriber-channel
http://www.novell.com/communities/node/4336/how-gcvize-a-driver-part-2

I also discuss some tricks about using GCV's in rules in the article:

http://www.novell.com/communities/node/4825/using-global-configuration-values-xpath

Anyway, one of the biggest pain points I run into using a GCV is that I often decide I need a GCV for a value I am about to use, as I am writing the rule.

For example, I was working on a JDBC driver where I needed to write a value back to a foreign key table, basically the value was a number that I knew would be one thing in the test lab database, but likely different in the production system. Perfect spot for a GCV right? Well I was in Argument Builder writing the string, and I had selected the Global Configuration Value token, which looks like:



There is the magnifying glass icon to show the GCV selector which looks like:


This is great, since although I try to standardize on naming of GCV's I ALWAYS forget what exactly I named it. Now iManager has a similar selector, but last I looked it did not show the value of the GCV, which is helpful as well.

In the past, I had to close out the rule, go to the driver or driver set object, edit its properties, and then add a new GCV that contains the info I want to store. Then return back to my rule I was in the middle of, and try to resume my train of thought.

I am not sure when this little widget showed up, but it is wonderful. If you look in the upper right of the above picture, you will see a little drop down arrow, and a picture of something I have no idea what it is. Anyway, select it, and you see:



You get the option to make a GCV on the driver or the driver set. This is great, as it helps keep the train of thought going.

Selecting either, pops up a window that looks like the next image:



Which is just like the selector on the Properties page of the Driver or Driver Set objects.

Name is the GCV name that you will be using. There are any number of naming schemes that can be used here. I like to follow one similar to schema naming, with a short (2-4) character company reference (acme for example) then something tells you what it is regarding. Thus my use above of acmeActiveUserContainer and acmeDisabledUserContainer. I have seen some that use gcv-acme-Vault-Active as a model as well. Whatever works for you is fine, just use them!

Display name is an interesting issue. Earlier iManager snapins and Designer builds did not always show the name of the GCV on the GCV page of the driver properties, requiring a click to get the name, which I found annoying since I have such trouble remembering the names, even of ones I created. (I have a terrible memory for things like that). What I usually do is put the GCV name in the Display Name field, so that it might be something like:

Container that holds the Active Users in the eDirectory Vault. (acmeActiveUsersContainer)

But if you have a GCV picker like shown above, why ever would you care to remember the actual names? Well as I discuss in the various articles, you can use a GCV even in fields that normally do not have a GCV picker or any way to select one, by using the notation ~GCVName~ or in our example ~acmeActiveUsersContainer~ . One common example is in a Condition test, of If Source DN is in subtree, normally you can just pick a specific location within the directory. But it turns out you can replace that string, with ~acmeActiveUsersContainer~ and it will work as well.

Finally you get to Description. I highly recommend using Descriptions wherever possible. You never know when someone else will have to look at your work and figure out what you were doing. Try to explain the what and the why of your goal. In description of rules I would recommend that you explain what you did in the rule, why you did it, and most importantly, if something obvious looks like the more correct way to do it, why you did not use the obvious answer. Otherwise some wise guy is going to come along later, look at your rule and say, thats silly, there is a much simpler way to do it, and repeat all the work you just went through.

Anyway, once you have your new GCV defined, you can continue on with defining your rule, without breaking your train of thought.

I love this feature, and have one feature request I hope to see in a build someday soon. There is currently no ability to edit a GCV from that location. What I find most often is that I realize I need a new GCV, I start to edit it, write a Description I think is useful, continue working and realize there is an important item I need in the Description, but if I do not write it now, I will forget and never get around to doing it.

I posted this request to the Novell Support Forums for Designer, and one of the Designer team entered it into Bugzilla as an enhancement request. Now I watch the nightly builds (and the bugzilla page) hoping it will be implemented and show up. This is a nice win win situation for everyone involved. I get a better tool, and the Designer group get great feedback from people using the tool in the field in ways they never would have imagined.