Sadly, updating this old article, it seems that they removed this functionality in Designer 4.5 or so. Which is a shame, it was useful.
Novell Identity Manager comes with a great offline editing tool, Designer for Identity Manager (Designer from now on).
This initially was meant to be an offline tool to make it easier for consultants to take work home to work on, and to provide documentation for customers. But boy did it get out of hand and grow into a more useful tool than just that!
Designer is based on an open source toolkit framework known as Eclipse. This provides the shell around with the Identity Manager plugins interface. Eclipse provides all the basic widgetry and the IDM plugins use it to let you work on an Identity Manager project.
For some things now, Designer is your only real option, like editing Provisioning Request Definitions (PRD) for the Roles Based Provisioning Module (RBPM). You can read more, and see some screen shots of where all the bits and pieces in a PRD belong in these two articles:
With each release, new features are getting added, and often these are things iManager could do but Designer was lacking. Usually these are in the realm of online actions. For example the ability to include Roles Based Entitlement (RBE) policies in Designer showed up in Designer 3.5 and 4. This has an ironic side affect, if you have lots of objects and lots of entitled users. As far as I can tell in Designer 3.5 and 4, when you import or compare a driver set with an Entitlement Policies container, Designer appears to be evaluating all the search filters and returning all the objects that thus have earned the entitlements. (An RBE entitlement is basically an LDAP search filter, where the result set (the same as a dynamic group) gets the entitlement).
In a large tree, this can basically cripple Designer. Specifically I ran into this when there were over a million users, and the entitlement policies returned a fairly large number of that million users. This meant Designer would take up to an hour to import a project as this traffic went on, and once imported would be unusable as garbage collection tried to clean up all that memory that had stored the results. Using a user account that had been blocked from seeing the Entitlement Policies container (You could use an IRF) made everything behave totally different. Keep that in mind if you are seeing very slow import or compare behavior and you have RBE based entitlements in your tree. (I think it would continue to do this, even if you did not have an RBE driver left in the tree).
The Documentation feature of Designer is great if at the end of a project you need to deliver some kind of documentation. Now I am of two minds on this part. In reality the documentation output is both very interesting, but mostly useless. While I suppose you could recreate a solution from scratch by using the Designer documentation, I would not wish that task upon anyone!
However, as an occasional reference to see what a rule does without opening up Designer it can be quite useful. Also it makes clients happy to get hundreds (if not thousands) of pages of documentation out of a project. After all, you can tell the results of a project by how high the stack of paper it generated was, right?
Interestingly enough, Designer 4 is more efficient at rendering documentation as I had a largish project that Designer 3.5 even with as much memory allocated as I could, could not generate the documentation for it. But this happened right as IDM 4 and Designer 4 were released, so I was able to try it in Designer 4 and it was able to get through the process.
One of the major new features in Designer 4 is support for Packages. This takes the old driver configuration files, and tries to break them down into many smaller pieces, so that each can be managed separately, allowing for actual upgrades and bug fixes in a reasonable fashion. There is a lot to Packages, and I tried to cover that in this series of articles:
As you can see, Designer has lots of great features. What I find interesting is that there are some that remain hidden and unknown to most people. So lets talk about an interesting one. The eDirectory Browser.
Built into Designer, since I think Designer 3 is an eDirectory Browser view. It is a little buried to get opened, but if you go the Window menu, Show View,
and select Other, then you get a browser box showing the various views.
Interestingly enough, there is a keyboard short cut to get to this view faster, and it has some amusing behaviors. If you look in the screen shot you will see it records the keyboard short cut as Alt Shift Q, Q. That is Alt and Shift and Q and then the letter Q? That is an odd patterning. Well if you try just Alt Shift Q, you get a pop up in the bottom right hand corner that looks like this image
This shows you the various characters you can add after the Alt Shift Q to get to specific views. I had not noticed this before, and it is quite interesting. Scalable to 26 views I guess. Unfortunately, the eDirectory Browser is not one of those shortcuts. What is nice, is once you pop up the short cut list of views you can click to select the one you want. A nice user interface decision.
At least one of those listed views can be quite useful, specifically the Error view. This is useful when Designer throws an error box and you cannot copy the text out, you can return to the Error View to see the whole stack trace to see if you can get a hint of what went wrong. Usually you will get a Null Pointer Exception error, which invariably means some piece of information that was required by the function was missing. Usually looking at the Java stack trace, the class name at the top is a dead giveaway as to what called it. The rest of the views are meant for more Eclipse style things, and not specific to the Identity Manager plugins that we are interested in.
Anyway, if you select Q for Other views from that list, you will see a browser window with lots of views that are mostly Eclipse related or else other plugin related.
If you wanted to find the Error Log the long cut way, you would expand General, the first item in the list and it is in that set of views.
If you expand Designer for Identity Manager, where most of the Designer related views are listed (The rest are in Provisioning a little lower on the screen) there is an item, eDirectory Browser. Note that in the image, it is ghosted, that is because I already had it opened. You can see a couple of other views I already have open are ghosted as well.
I am not sure if this is the default, but usually when I open it, it becomes another tab on my left most sub window, where the Outline and Project view are. However I cannot remember if I dragged it there, and now Designer remembers or if it is a default.
In Eclipse, any window or tab can be dragged into most any other window or tab, so you can rearrange your deck chairs as desired. I like it in a long tall view, since it shows the left hand side of what Console One would show, which is best viewed tall and skinny.
One of the changes in Designer 3.5 was to make the eDirectory browser, and some other processes use a facility in Designer for running in the background. If you have ever used Apache Directory Studio's LDAP browser if you process a big query, you will see it run in the background, so as not to block the rest of the user interface.
The eDirectory Browser can do something the same. This is useful, in case you foolishly expand a Users container that has a million users in it. It will eventually return and render all the million users as little icons, but it might take a while to get there. This approach is nice because it does not block operations in the rest of Designer while it is loading in the background.
Usually you will see a little widget in the bottom of the screen on the status bar, next to the memory gas gauge, with a funny little animation indicating it is running in the background until it is done.
Now, out of the box, when you select any object and right click, you can choose Properties. This brings up a simple view, which should be familiar to many as Console One's Other tab.
This is great, since you can see most any attribute, and the default widgets for each syntax type are reasonably defined. For example, although ACL syntax is really just an Integer, a DN and a string, making you type them free form would be less than helpful. Though I know people who like doing ACL's via LDAP by preference, which requires the free hand typing. Regardless, if you have an ACL set on the object, you will see an ACL entry, and if you select to edit it, you get at least a slightly more useful ACL editor, which lets you pick the level of rights, and for which attribute. This is very helpful.
Path syntax attributes, which is still my all time favorite syntax type, get a slightly less useful browser. But you do get a DN picker widget, which is helpful. Path syntax is great when you need to link some piece of data to an object. Path has an integer, a DN, and a string, which sounds a lot like ACL syntax doesn't it? I am not sure but I would bet the indexing allowed and searching that is allowed is different between the two types. However it does make some sense, as ACL syntax is for granting permissions in eDirectory and Path syntax was originally meant for referencing objects in the file system. The first step to granting a right is to identify the target. Ok that may be a bit of a stretch.
Anyway, it turns out that since Console One is Java based, the source code is owned by Novell, and basically a fairly mature product, the Designer team took the easy way out and just included most of the Console One code in Designer. Thus many of the basic snapins are present in Designer, they just ship disabled.
To change this, what you need to do is look in the plugins directory of your installed Designer (%designer home%/eclipse/plugins or it might just be %designer home%/plugins in Designer 4) in which there is a file called "PageClassRegistry.properties".
Note: This file only exists after you have run the eDirectory Object Manager at least once. This class contains a list of Console One snapins that ship with Designer because they are part of the base Console One code that is included with Designer.
You can see that only two snapins are enabled by default, all the others are disabled (commented-out). There are snapins which are disabled with a single pound sign "#" and others which are disabled with a double pound sign "##".
Basic testing has shown that you can enable all the single-pound-signed and make them work without problems but the double-pound-signed have been seen to cause problems.
To enable some of the disabled snapins, just un-comment them and the change takes effect immediately.
This is pretty neat, and once you do enable a snapin when you next open the Properties of an object, you get the additional tabs that the snapin provides. I will include the properties file so you can get a feel for what is available.
Personally I suspect when you choose in Console One, the Page options at the bottom of each Properties page, you are seeing this text file rendered into a UI, and when you enable/disable something, you basically modify this file, or its equivalent.
#=== all types ===
#=== Person ===
#=== Organizational Person ===
#=== NCP Server ===
#=== Organizational Unit ===
#=== User ===
#=== Top ===