Defines a property book. A property book is a collection of property pages.
You should use a property book when you are operating on an object and want to display or change
attribute values.
You should not use a property book if you want to have a wizard-like flow or if you are operating
on more than one type of object.
Defines a chained task. A chained task is a task that is automatically executed
when another task completes execution. For example, you might chain a task that
creates a home directory to the create user task.
The name of the Java class that should be loaded when the task or book is invoked.
The name must be fully qualified (it must contain the full package path). For example:
com.novell.administration.SomethingTask
Matches the name of a key inside properties files that contain translated strings.
The value identified by the key is extracted and used by iManager; for example, during module installation.
Matches the name of a key inside properties files that contain translated strings.
The value identified by the key is extracted and used by iManager; for example, during module installation
and display of roles and tasks.
The install element is a top-level or root element for iManager installation XML files.
The iManager installation XML files are used to determine the structure of modules, roles,
tasks, and books both during installation of Role Based Services and during initial layout
of the Unrestricted View (which shows all roles and tasks and does not take advantage of
Role Based Services).
Defines a module. A module is a container for books and tasks. You must have a module if you want to
have books or tasks. You should name your module according to your product plug-in.
When packaging an .npm file, make sure the module ID is consistent everywhere.
If you have different module IDs in different files, when the module is installed into RBS the
module will not work. The module will work in Unrestricted mode because that mode is not as strict as RBS.
You must test your modules in Unrestricted mode as well as after installing your module into RBS.
The module ID must be the directory name created by your module under webapps/nps/portal/modules.
For example, if you have a module that creates webapps/nps/portal/modules/vpn, then "vpn" must be
the module ID everywhere. Do not use "." characters in your module name.
Module IDs are used in the following locations:
In the module's .npm file in the META-INF/MANIFEST.MF file, there needs to be a Module-ID: entry. For example:
Manifest-Version: 1.0
Created-By: Novell, Inc.
Implementation-Title: NBM VPN Configuration
Implementation-Version: 1.0.20030320
Implementation-Vendor: Novell, Inc.
Module-ID: vpn
The Module-ID value must match the directory name created under webapps/nps/portal/modules, which, in
the preceding example, is vpn.
In the module's .npm file, the currentwebapp/portal/modules/vpn/install/Vpn.xml file (using the
preceding example), must specify a module ID that matches the directory name created under
webapps/nps/portal/modules, which is vpn in this example.
Apply this tag to roles and modules for which you do not want RBS objects created
in the directory when the module is installed. You would want to do this if
your role is targeted for TreeDown mode.
Defines an object creator plug-in. When an object-creator is registered, the object type name shows up
under the Create Object task.
If you want to use the generic creator, specify com.novell.emframe.fw.GenericCreator as the
class-name parameter.
If you want to create the object using your own code, create a Java class that extends the MTask class
and specify that class name for the class-name parameter.
An object-creator can also be used to veto object creation. If you specify
com.novell.emframe.dev.VetoCreatorTask as the class-name, the object appears in the
list under the Create Object task, but when you click on it, it won't let you create the
object, and iManager displays a generic error. If you want to have your own error message or
more helpful information, then you should create your own Java class that extends MTask and
specify it as the 'class-name' parameter.
It is also possible to register for object creation using iManager. Click the Developer button, then click
iManager Development > Add Object Class To Creation List. Note that if you have multiple iManager installations,
this will only register for object creation on the iManager server you are hitting.
NOTE: If more than one object-creator is registered for the same object, the second one is ignored.
This behavior is based on the principle that certain products have ownership of the object types they
use and object types should only be created by the products that own them.
Defines an object deletor plug-in, which is used to veto object deletion.
If you don't have any need to write specific code, use the generic veto class,
com.novell.emframe.dev.VetoDeletor. If you need to provide additional functionality, create
a Java class that extends com.novell.emframe.dev.VetoDeletor and use that class name as the
value of the class-name parameter.
NOTE: If more than one object-deletor is registered for the same object, the second one is ignored.
This behavior is based on the principle that certain products have ownership of the object types they
use and object types should only be deleted by the products that own them.
Defines an object move plug-in, which is used to veto object moves. If you don't need to write
specific code, use the generic veto class, com.novell.emframe.dev.VetoMove. If you need to provide
additional functionality, create a Java class that extends com.novell.emframe.dev.VetoMove and use
that class name as the value of the class-name parameter.
To specify the object type whose move you want to veto, provide a value for object-type-name.
NOTE: If more than one object-move is registered for the same object, the second one is ignored.
This behavior is based on the principle that certain products have ownership of the object types they
use and object types should only be moved by the products that own them.
Defines an object rename plug-in, which is used to veto renaming of objects. If you don't need to write
specific code, use the generic veto class, com.novell.emframe.dev.VetoRename. If you need to provide
additional functionality, create a Java class that extends com.novell.emframe.dev.VetoRename and use
that class name as the value of the class-name parameter.
To specify the object type whose renaming you want to veto, provide a value for object-type-name.
NOTE: If more than one object-move is registered for the same object, the second one is ignored.
This behavior is based on the principle that certain products have ownership of the object types they
use and object types should only be renamed by the products that own them.
Defines a page plug-in. A page (also referred to as a "property page") is a member of a book.
Pages can also have a chapter classification. Note that there is no notion of a chapter entity or container.
If a book is being constructed, the pages are classified into the chapters that are
defined for each page. If more than one page has the same chapter specified, those pages are
shown in the same chapter.
A page and the book it is assigned to must operate on the same object types.
Defines a page blocker, which blocks inherited pages from showing up in Modify Object.
Since pages register against an object type, if there is an object type, X, which is derived
from another object type, superX, by default, the pages from the super
class (superX) would appear when an object of type X is selected for Modify Object.
If there is a page that you don't want to show up, specify the ID of that page as the value of the
page-id parameter and the object type as the value of the object-type-name parameter.
No Java or JSP code is required for a page-blocker.
The plugins element is a top-level or root element for iManager plug-in XML files.
iManager plug-in XML files are used to define plug-ins, which add functionality to that
already provided by the iManager framework. For example, the iManager framework provides a
property book for modifying directory objects. A plug-in might add a page to the
property book for the User object type.
Defines a private page. Use a private-page when you don't want your page to show up for
the Modify Object task. Any book can still include this page. The parameters are exactly
the same as the page.
Privileges to be assigned for this attribute. Values can be any or all of those
defined in privilegeType.
If Supervisor is specified, it is redundant to include any other privileges.
Any XML data that should be stored on the module, role, or task object in the directory.
Must be in XML format. The XML must have a single root element that is unique; therefore you
should include your product name in the root element.
For example, the object could already have XML data with an "iManager" root tag, so
you should have a tag that describes your product, such as "DirXMLparameters"
The name of the .properties file that holds your translatable strings.
We suggest that you name the properties file something like this:
<string that resembles plug-in or module name>_xx.properties, where xx is the language code.
For example, if your plug-in is named LDAPplugin, your properties file could be named LDAPpluginResources_en.properties
For the value of resource-properties-file, you would then specify LDAPpluginResources because the iManager framework automatically
loads the correct language properties file by adding the _xx portion of the file name.
Your properties file should be stored inside your plug-in JAR file.
For example, "com.novell.admin.modules.FTPAdmin.Layout"
Defines a role, which is a container for tasks and books. You can assign books and tasks to a role
by specifying the role's ID as the value of the role-assignment parameter of the task or book.
Defines a task plug-in, which allows your UI to take over the content pane of iManager.
You can then write custom code that creates a wizard (an ordered flow of UI pages),
displays a single page, or even displays no page at all. You should use a task rather than a page
if you plan on operating on more than one object type at a time, if you don't want the UI to appear
as a page of a book, or if you are doing non-directory operations.
This is a version you use to describe your plug-in. It is used during module installation and update
to determine whether the module needs to be installed.
Defines a view. A view is represented by the icons that run along the top frame of iManager, such as
Roles and Tasks, View Objects, Configure, Favorites, and Developer.
Views take over the entire window except for the frame that contains the view icons. You might want to
write your own view if your plug-in needs to be cross-tree aware or if you don't want it to be displayed
inside the traditional Roles and Tasks view, which show roles and tasks in the left frame.
When writing your own view, you must create Java classes as well as JSPs. Your Java class need not
extend or implement any iManager framework classes.
View access is controlled by the iManager Views Access task in the Configure view.
The XML Instance Representation table above shows the schema component's content as an XML instance.
The minimum and maximum occurrence of elements and attributes are provided in square brackets, e.g. [0..1].
Model group information are shown in gray, e.g. Start Choice ... End Choice.
For type derivations, the elements and attributes that have been added to or changed from the base type's content are shown in bold.
If an element/attribute has a fixed value, the fixed value is shown in green, e.g. country="Australia".
Otherwise, the type of the element/attribute is displayed.
If the element/attribute's type is in the schema, a link is provided to it.
For local simple type definitions, the constraints are displayed in angle brackets, e.g. <<pattern = [1-9][0-9]{3}>>.
If a local element/attribute has documentation, it will be displayed in a window that pops up when the question mark inside the attribute or next to the element is clicked, e.g. <postcode>.
Abstract(Applies to complex type definitions and element declarations). An abstract element or complex type cannot used to validate an element instance. If there is a reference to an abstract element, only element declarations that can substitute the abstract element can be used to validate the instance. For references to abstract type definitions, only derived types can be used.
Collapse Whitespace PolicyReplace tab, line feed, and carriage return characters with space character (Unicode character 32). Then, collapse contiguous sequences of space characters into single space character, and remove leading and trailing space characters.
Disallowed Substitutions(Applies to element declarations). If substitution is specified, then substitution group members cannot be used in place of the given element declaration to validate element instances. If derivation methods, e.g. extension, restriction, are specified, then the given element declaration will not validate element instances that have types derived from the element declaration's type using the specified derivation methods. Normally, element instances can override their declaration's type by specifying an xsi:type attribute.
Nillable(Applies to element declarations). If an element declaration is nillable, instances can use the xsi:nil attribute. The xsi:nil attribute is the boolean attribute, nil, from the http://www.w3.org/2001/XMLSchema-instance namespace. If an element instance has an xsi:nil attribute set to true, it can be left empty, even though its element declaration may have required content.
Prohibited Derivations(Applies to type definitions). Derivation methods that cannot be used to create sub-types from a given type definition.
Prohibited Substitutions(Applies to complex type definitions). Prevents sub-types that have been derived using the specified derivation methods from validating element instances in place of the given type definition.
Replace Whitespace PolicyReplace tab, line feed, and carriage return characters with space character (Unicode character 32).
Substitution GroupElements that are members of a substitution group can be used wherever the head element of the substitution group is referenced.
Substitution Group Exclusions(Applies to element declarations). Prohibits element declarations from nominating themselves as being able to substitute a given element declaration, if they have types that are derived from the original element's type using the specified derivation methods.
Target NamespaceThe target namespace identifies the namespace that components in this schema belongs to. If no target namespace is provided, then the schema components do not belong to any namespace.