Event Trigger Contexts
Configuration management has two contexts for event triggers: global and project.
All server-side triggers are configured on the Integrity Lifecycle Manager server. Each context contains JavaScript elements that define the event triggers. Each type of event trigger can be created and maintained independent of the other. This means you can define different event triggers for the same events in different projects, or you can define event triggers that apply globally within your environment.
|
|
When working with shared subprojects, Integrity Lifecycle Manager uses the actual name of the subproject in the file system rather than its relative name in the configuration management project hierarchy. This enhances the portability of change packages across different configuration management projects. Therefore, when returning query information resulting from a script, Integrity Lifecycle Manager uses the actual file system name of the shared subproject.
|
Global Context
Global event triggers are available and active for all configuration management operations. As administrator, you use the global context for any JavaScript elements used to define additional procedures for all configuration management users.
Project Context
Configuration management project event triggers are established within a project events file. The project context is generally used for project-specific configuration processes. Event triggers in this context generally add to, but do not override, event triggers defined in the global context. The project context is active when either the project or a Sandbox based on the project is active.
|
|
Configuration management events not available in the project context are: New Project and Drop Project.
|
