I like to try and discuss stuff I think are interesting and new, and why some of the changes matter.
Having finished the high level new features, lets look at known issues of interest, and then whatever bugs I have noticed being fixed.
There is a section in the readme about known issues with this release. I went through looking for interesting ones to call out.
"Cannot Configure Query Token to Read Multiple Attributes Using Argument Builder
In the Policy Builder, when you create a new rule and use a Query token in an action within the rule, you can only use the Argument Builder to specify a single attribute for the query to read. If you add more than one attribute, Designer uses only the most recently added attribute in the query.
If you must add multiple attributes to a Query token, you can either add attributes in Policy Builder without opening the Argument Builder or modify the XML to include the attributes you want to add.
To add attributes in Policy Builder, click the plus icon for each attribute you want to add and specify the attribute values you want to add into the Read attribute fields. Do not click the Edit the arguments icon. Click Finish, and Policy Builder appends the attributes to the expression rather than replacing the existing attribute.
To add attributes in the XML, open the policy in Policy Builder, click the XML Source tab, and manually add the additional attributes as new token-text elements within the token-query element."
This was a strange bug that got introduced in Designer 4.02 Auto Update 3 or 4 I think. There was a change to fix the next issue in the list (Argument Builder May Not Successfully Remove Arguments from Specific Actions), but it broke Policy Builder pretty badly, so they reverted it, but seem to have ended up with this particular bug. I had never run into it, but I was surprised to see this make it into the shipping product unfixed. It is particularly pernicious since you could make the change that worked before, but now when you deploy the driver will fail to start as the XML you submitted for this policy violates the DTD and the engine will refuse to load it.
"Setting the LDAP Ports Correctly After Importing a Project into Designer
When you create a project after importing it from a live system in Designer, Designer does not set the ports correctly in the Identity Vault Properties view.
To work around this issue, change the LDAP ports in the Identity Vault Properties view before deploying the imported project."
This is an odd one that I am not sure about, since generally the ports are for NCP, not LDAP. But I will keep my eye open to try and figure out what this comment is about. This was the first thing that made me wonder if the change from NCP to LDAP had occurred in this build. Perhaps it was importing it improperly but using LDAP anyway? Alas as far I know that is not the case.
What is interesting is that I have never seen the LDAP ports listed in Designer, so I come back around to thinking that maybe this is an issue that was in an early attempt to replace JClient with LDAP that is not yet complete. I am interested if anyone understands this specific bug any better than I do.
"Designer Overwrites Modified Package Linkage Order on Update
If you modify the order of linkages within a package, Designer does not recognize the package as being customized. Subsequently, if you update the package, Designer overwrites the modified linkage order with the linkage order specified in the updated package. (845207)"
This is a particularly annoying issue that remains. It helps if you understand how Packages do their magic under the covers. If you were to browse the file system of your workspace, you will see that the files for each Policy object (and in fact the objects in eDirectory as well) contain two copies of the data attributes. That is, for Packaged content, in eDirectory you will see the DirXML-PkgInitialState which holds the version of the payload that came with the package. Obviously the contents will depend in the object type. A Policy of XSLT object will hold the original XML. An ECMAScript resource (really a DirXML-Resource object, with a DirXML-ContentType set to Ecmascript) will hold the raw text of the ECMA functions it contains.
There is also a DirXML-PkgChecksum that stores the checksum (algorithm is unspecified and unknown at this time) of that content, so that when looking at your policies, it can do a checksum of the current state of the XML, compare to the packaged initial states checksum and know very quickly if they differ, and thus 'star' them in the Outline view as dirtied content.
That is the content. The DirXML-PkgLinkages new attribute that came with Designer 4.02 AU4 to push that data out to the IDV does not seem to be considered in the dirty calculation. It is stored in the Package info, if you made a linkage change in a driver in an open Package (Not Released yet, so not locked for changes, and your tree was set to Package Developer Mode in Designer) then it depends on how you did it. If you just moved the policy around with the arrows in the Policy window bottom left of the screen, then that should count as dirty. If you right clicked, Package Properties, selected the third tab, Linkage, and made the change there, you actually automatically sync that change to the Package.
So my guess is, if you moved it around with the arrows, and then on an upgrade, the linkage weights are re-evaluated and your change will be thrown away.
"A Failure Message is Displayed When a Deleted Role Container or Subcontainer Is Deployed"
This is a fun one. I have noticed there are a couple of places where Designer is not entirely aware of how eDirectory works. For example, you can name an object longer than 64 characters. But eDirectory schema limits CN to 64 chars. This throws a funny illegal attribute error on Deploy if you try it. The other good example is how eDirectory handles leading and trailing spaces or underscores. They matter, but if you had 6 leading underscores and 6 trailing spaces on an object name they count the same as 1 leading and one trailing. If you do a raw value compare as Designer seems to do, they look different, but eDirectory will inform you the object already exists. Try creating a policy with a trailing space, deploy it, it will have the eDir trailing space, but every compare after Designer will be confused.
Here is another example. If you try to delete a non-empty container you get a -629 error I think. The workaround is you need to delete the contents, deploy that set of deletes, then delete the parent container (now empty in eDir) and deploy it. This is probably a place it would be nice for Designer to be smart enough to do that. Or in fact to implement the LDAP extension in eDirectory 8.8.8 that allows you to do a non-empty container delete. (It is meant to be, and is, faster than deleting the children and then the parent. Aaron Burgemeister (ab of CS and forums fame) tested during the beta on 1 million object containers and the difference was huge in speed.
Fixed Bugs that I noticed:
Dirty DirXML-Resource objects
A bug that drove me crazy that I noticed was fixed is related to DirXML-Resource objects. In Designer 4.02 if you opened a DirXML-Resource object that did not have a custom editor, then it would be marked dirty, just because you opened it, even with no changes. That is, you would get an asterisk in the tab bar, indicating you need to save it.
This seems silly, but because of how Designer holds the project model in memory you want to try very hard to NOT make changes in two different tabs and having two dirty tabs. You are likely going to lose one of those changes.
Note I said DirXML-Resource objects that do not have custom editors, I mean, DirXML-ContentType that is text/xml or text/text. This is a distinction of interest since ECMA Script, Mapping Tables, Filter Extensions, EntitlementConfiguration objects all are valid DirXML-ContentTypes, but for all of those but the entitlementConfiguration object have a custom editor.
Thus when you right click a driver, select New, and then select an ECMA Script, Mapping Table, or Filter Extension you actually make a DirXML-Resource object with a specific DirXML-ContentType value. Which means you could make a new DirXML-Resource through that menu, then select the proper content type and get the object type you wanted.
This was an issue for me, since we have a driver configuration at the consulting firm I work at that we call LiQuiD SOAP that uses DirXML-Resource objects to make SOAP drivers faster and easier to develop. So I can spend a lot of time editing these things. Every time I would open one, it would get marked as dirty, and if I would forget to save it immediately, I could get into that strange state. Drove me crazy, since i would open a reference object, not make any changes and not notice it was starred until too late.
General Performance improvements:
I am unclear if it is the Eclipse upgrade, the move to 64 bit, or backend code fixes that resulted in much better performance, but I do not care, since the end result is positive.
The first thing I did when I got a copy of 4.5 was I opened 70 tabs from a fairly large project (maybe 120 drivers in 4 trees, of all different types with a large Package Catalog). What I found first of all was that it was actually possible. In older Designers, running 32 bit, I would run out of memory long before I could get that many tabs open. But here I noticed two things. First I was actually able to do it, and only use 1.2 GB of RAM (I was limited by my designer.ini file to 2GB for Designer). Second, while opening them all and closing them all took several minutes, it was faster than in 4.02, but closing one tab at a time was much faster than before as well.
This was all very good stuff to see. Amusingly I ran into a different older bug they had fixed for me in D4.02 Auto Update 2 that seems to have occurred (or else a related bug) that on Windows, with about 70 or more tabs, you run out of Windows USER object resources.
New Default Theme:
I am a bit colour blind, and the major manifestation is that I apparently have no taste in colour selection. So I look at the shipping theme and say "ick" but do not know why. I will defer to someone who can explain why it is kind of ugly. Regardless, go to the Window menu, Preferences at the bottom, and expand General, then select Appearance. Change the theme to Classic and it will return to the way it looked before.
There is an amusing minor oversight. If while you are in the Preferences window, expand NetIQ, then Designer, and the first item if "%version_control" which is probably a localization issue that got away from them. Pretty funny actually, but no harm done.
Help links may not all work:
The context sensitive help in Designer is still there, and when I started looking at the filter to understand how Out Of Band sync worked, it turns out that some of the links do not work. Oddly the content is there, and if you saw the link in the help window, and browsed down to it from the top, you could find the linked content. But not if you use some of the links. Just a heads up, it is reported and likely to be fixed soon.
That is all I have for now, I will keep my eyes open for more interesting fixed (or left open) and report on them as I find them.