| name | dirxml-designer-workspace |
| description | Read and describe NetIQ / OpenText Identity Manager Designer workspaces on disk — DirXML drivers, policies (DirXML Script, XSLT, mapping), filters, entitlements, packages, Identity Vault schema, User Application / RBPM provisioning (workflows, forms, roles, resources, PRDs). Use this skill whenever the user references a Designer workspace, a `designer_workspace*` folder, a `.Driver_` / `.ScriptPolicy_` / `.MappingPolicy_` / `.Filter_` / `.IdmPackage_` file, or asks about DirXML policies, IDM drivers, driver sets, GCVs, Subscriber/Publisher channels, eDirectory sync, User App workflows, role/resource provisioning, or IDM documentation. Trigger even if the user doesn't name the product — phrases like "the CyberArk driver", "our AD sync policies", "the IDM workspace", "a PRD", or a path under `Model/EdirOrphan/` or `Model/Provisioning/` mean this skill applies. |
NetIQ / OpenText IDM Designer Workspace
Use this skill when you need to understand, describe, document, or answer questions about a Designer workspace on disk. It spares you from re-deriving the file layout and object model from first principles each session.
What a Designer workspace is
A Designer workspace is an Eclipse workspace (it contains a standard .metadata/ directory) that holds one or more IDM projects. Each project is a Designer model of an Identity Manager deployment — DriverSets, Drivers, policies, Identity Vault schema, and optionally the User Application / RBPM provisioning model.
Designer stores every model object as two files that share a short uppercase ID:
<ID>.<Type>_ — metadata (XML, com.novell.designer.model:CObject root) with scalar attributes and relations to other objects<ID>_contents.xml — the actual payload (DirXML Script policy, XSLT, mapping table, filter XML, entitlement XML, ECMAScript, etc.)
Objects with children (Drivers, Subscribers, Publishers, DriverSets) also have a sibling directory named with the same ID that contains the child objects. So to walk the tree you chase both the relations keys and the matching directory.
Orientation: the minimum you must know to work in one of these
Open the workspace and get your bearings in this order:
- Identify the project roots. Every child directory of the workspace with a
.project file whose nature is com.novell.idm.DesignerProjectNature is an IDM project. Ignore .metadata/ (Eclipse bookkeeping) and .tmp/.
- Inside a project, the interesting trees are:
Model/IdentityManager/<DomainID>/ — the Modeler view: Domain, IdentityVault, Servers, Applications (app icons connecting to drivers). Schemas live under <IdentityVaultID>/.Model/EdirOrphan/ — where DriverSets, Servers, Drivers, Libraries, and their policies actually live. "Orphan" means not currently bound to a live eDirectory replica in the Modeler, but this is the normal storage location for the driver configuration source of truth.Model/Provisioning/AppConfig/ — User Application / RBPM: workflows (RequestDefs → *.prd), forms, roles, resources, SoD, attestations, directory abstraction layer.Model/Project/<ProjectID>/ — Catalog (package categories) and TreeData.Designer/Documents/Generated/ — Document Generator output, if the user has run it.
- The driver tree is a hub-and-spoke graph, not a simple nesting. A
.Driver_ metadata file declares relations like Idm:Subscriber, Idm:Publisher, Idm:Filter, Idm:Entitlements, Idm:Policies pointing at sibling objects. Subscriber/Publisher then declare Idm:EventPolicies, Idm:MatchingPolicies, Idm:CreatePolicies, Idm:CommandPolicies, Idm:InputPolicies, Idm:OutputPolicies, Idm:SchemaMappingPolicies, Idm:TransformPolicies — each of these is an ordered policy set.
- Packages leave fingerprints. Almost every driver is built from one or more
IdmPackage_ references — when you see relations name="Idm:InstalledPackages" on a DriverSet or Driver, that's tracing the package provenance.
The canonical lookup: given X, how do I find it?
| You have | Where to look |
|---|
| Driver name (e.g. "CyberArk") | Grep Model/EdirOrphan/*/*.Driver_ for name="CyberArk" — the file ID is the driver ID |
Driver ID (e.g. 9HPNAS5Y) | Metadata is Model/EdirOrphan/<DriverSetID>/<ID>.Driver_; children are the sibling directory .../<ID>/ |
| Policy by name | Grep *.ScriptPolicy_ / *.StylesheetPolicy_ / *.MappingPolicy_ for name="..." — the real content is the adjacent _contents.xml |
| The policies attached to a channel in execution order | Read the .Subscriber_ / .Publisher_ metadata file — policy-set relations (Idm:EventPolicies, etc.) are in document order, which is the order Designer runs them |
| A filter's classes/attrs | <ID>_contents.xml with root <filter> (sibling of <ID>.Filter_) |
| GCVs (global config values) | At DriverSet scope: *.GlobalConfig_ under Model/EdirOrphan/<DriverSetID>/. At Driver scope: driver-embedded DirXML-ConfigValues CDATA in the .Driver_ file. Per-server overrides: <DriverID>_<ServerID>_DirXML-ConfigValues.xml |
| eDirectory schema extensions | Model/IdentityManager/<DomainID>/<IdentityVaultID>/<SchemaDefID>_schema.xml |
| User App workflows (PRDs) | Model/Provisioning/AppConfig/RequestDefs/*.prd |
| Roles / Resources / SoD / Attestations | Model/Provisioning/AppConfig/RoleConfig/{RoleDefs,ResourceDefs,SoDDefs,Attestations}/ |
| Workflow forms | Model/Provisioning/AppConfig/WorkflowForms/{WorkflowRequestForms,WorkflowApprovalForms,WorkflowTemplateForms}/ |
| Directory Abstraction Layer (entities, queries, relationships, choice lists) | Model/Provisioning/AppConfig/DirectoryModel/ |
Reading policy content
The .<Type>_ file is thin metadata and relations — the interesting stuff is almost always in <ID>_contents.xml. Three content dialects dominate:
- DirXML Script — root
<policy>, inside are <rule> → <description> / <conditions> / <actions>. Conditions use <if-*> (e.g. if-class-name, if-operation, if-global-variable, if-xpath). Actions use <do-*> (do-veto, do-set-dest-attr-value, do-status, do-add-association). Tokens like <token-attr>, <token-xpath>, <token-src-dn> appear inside arg-* elements. This is the primary dialect — most ScriptPolicy files are DirXML Script.
- XSLT stylesheet — root
<xsl:stylesheet>. These are .StylesheetPolicy_ and run via the XSLT engine; they receive the XDS event document and emit transformed XML. Watch for the magic <xsl:param> names (srcQueryProcessor, destQueryProcessor, dnConverter) that Designer/IDM injects.
- Mapping policy — root
<attr-name-map> with <class-name> and <attr-name> children mapping between <nds-name> (eDirectory) and <app-name> (connected system).
Filters are their own dialect: root <filter>, with <filter-class> (per eDirectory class) and <filter-attr> (per attribute) carrying publisher=, subscriber=, merge-authority= attributes.
Describing a driver: the recipe
When the user asks "what does the X driver do?" or "document this driver":
- Find the
.Driver_ metadata file by name.
- From it, collect: shim (
DirXML-JavaModule), target app (DirXML-ShimAuthServer etc.), driver-level config (DirXML-ShimConfigInfo CDATA — a nested <driver-config> with driver-options / subscriber-options / publisher-options), trace settings.
- List the policies attached to each channel (read
.Subscriber_ and .Publisher_ and walk their relations in order). For each, read its _contents.xml and summarize the rules — a DirXML Script rule's <description> is almost always a real sentence written by the developer and is the best single source of summary text.
- Read the Filter to describe what classes/attributes actually flow and in which direction.
- Read the Schema Mapping (MappingPolicy) to show the eDir↔app attribute naming.
- Read any Entitlement files to list what the driver can grant.
- Check
DirXML-ConfigValues CDATA and separate *_DirXML-ConfigValues.xml for GCV values that parameterize the policies.
- Mention package provenance:
Idm:InstalledPackages relations tell you which IdmPackage_ objects contributed.
What to ignore
.metadata/ anywhere — Eclipse plugin state; irrelevant to IDM content..tmp/ — transient..DS_Store, .lock, _icon.gif, _icon.png — cosmetic/housekeeping.- History under
.metadata/.plugins/org.eclipse.core.resources/.history/ — Eclipse's local file history cache; not the IDM source of truth.
Reference files (read on demand)
references/workspace-layout.md — full directory map, every known type extension, and what each top-level tree is for.references/object-types.md — every .<Type>_ file in this ecosystem, what it represents, and what its _contents.xml holds (if any).references/policies-and-rules.md — DirXML Script grammar, XSLT conventions, mapping/filter payloads, and how policy sets attach to channels.references/provisioning-userapp.md — UserApp / RBPM layout: RequestDefs, forms, roles, resources, SoD, attestations, DAL.references/identity-vault-and-packages.md — Identity Vault schema, packages, global configs, server bindings, GCV override files.examples/cyberark-driver-walkthrough.md — a fully traced example driver from the ig-idm project showing how the metadata, relations, policies, filter, schema map, and entitlements connect. Read this first when learning the model; then generalize.
Tone and format for output
The user is an IDM consultant, so use IDM vocabulary directly (subscriber/publisher channel, GCV, NDS vs app name, merge authority, association, entitlement). Prefer concise prose; reach for bullet lists only when enumerating policies, rules, filter attrs, or similar. Quote short rule descriptions from the XML — they usually explain intent better than any paraphrase.
Modification is out of scope for this skill (it's read-and-describe only). If the user asks to edit, flag that editing Designer files byte-for-byte is viable for small script/filter tweaks, but non-trivial changes (adding policies, renaming drivers, rewiring relations) really want to be done in Designer itself because IDs, BackReferences, and the Modeler graph all have to stay consistent.
