Command Console
The Command Console provides a simple console utility that exposes small administration and/or utility operations, which by themselves might be too trivial / limited in scope to be provided as a fully fledged tool page, or which might involve very dynamic / extensible use cases which cannot be covered by a generic, static page.
The Command Console can be extended by plugins to provide specific functionalities / commands. OOTBee Support Tools in version 1.1.0.0 provides the following default plugins / scopes:
- global - A global set of commands to provide the basic commands to inspect available plugins, switch active plugins and display a basic help
- permissions - A small utility to check the effective permissions for a specific user on a specific node
- subsystems - A set of commands to inspect, modify and reset the configuration of subsystems, allowing the same kind of interaction as is provided by JMX for Alfresco Enterprise
Each command of a plugin is executed / evaluated by a server-side web script. Execution of complex commands may take some time, so the output of a command may be delayed after the display value of "Previous command" has been updated to show the last used command. Whenever a new command is triggered by the user, the previous command will still finish execution on the server-side, but any result output of such a command will be discarded, as the newer command supersedes it. By default, all commands are tokenised into fragments on whitespace boundaries, so an imaginary command like
executeScript /Company Home/Data Dictionary/Scripts/myScript.js
would be considered to have multiple arguments / parameters, even though the entire path should be considered to be one parameter. Tokenisation on whitespace boundaries can be suspended by enclosing a value in double quotes, e.g.
executeScript "/Company Home/Data Dictionary/Scripts/myScript.js"
The global plugin for the Command Console is a pseudo-plugin. It does not need to be activated for its primary commands to be accesible, but may be activated in order to access its local help command. When the Command Console is accessed, the global plugin will always be active by default.
The listPlugins command lists all the plugins to the Command Console which can be activated. The list of names if sourced from the ootbee-support-tools.command-console.plugins property in alfresco-global.properties, which defines the comma-separated list of names of plugins to show as accessible.
The command
activatePlugin <nameOfPlugin>
activates a specific plugin and automatically invokes that plugin's implementation of the help command to list its supported commands and arguments.
The command
help
prints a simple summary of available commands and their supported arguments in the currently active plugin. This command itself generally does not require any parameters, but plugins are free to add optional parameters, e.g. to control the verbosity of the output if the list of commands / invocation variants would otherwise be too extensive.
This command is technically not a global command - it must be provided / implemented by every individual plugin itself to provide the details of its commands. The command will always be automatically invoked when a plugin is activated via the activatePlugin command as both a user convenience feature as well as a verification that the plugin actually exists. IF a plugin does not provide an implementation for this command, the activation of that plugin will fail and the Command Console show a error message referring to Unknown plugin "<nameOfPlugin>"
The permissions plugin provides commands to perform live evaluations of permissions via the Alfresco PermissionService. In contrast to the Node Browser tool, which only shows the statically set permissions with the authorities they have been granted / denied to, this allows an administrator to perform a live evaluation of permissions, taking into account the user's group memberships as well as the evaluation of DynamicAuthority constructs.
The command
effectivePermissions user <userName> node <nodeRef>
lists the effective permissions the specified user has on the specified node. This command only checks those permissions which are defined in the permission model as "settable" for the node in question, so it will not show any low-level permissions, permission groups or permissions that might be set on a parent / ancestor node, but not be formally applicable to the node itself. As an example, this command will not evaluate / show the effective state of:
- the "Lock" or "Unlock" permission groups, as these are defined in the permission model as "not exposed" (visible), thus considered to be technical or low-level permission groups
- the "SiteCollaborator" permission group on any node that is not of the type
st:site, as this permission group is defined only for that type (and its sub-types, unless a more specific permission model applies to any sub-type)
This command however will fully and transparently show the effective state for any permission that may result from a permission or permission group otherwise excluded from display, e.g. being granted the "SiteCollaborator" permission on a node via inheritance from the containing site, the command will properly reflect that the "Collaborator", "Contributor", "Editor" and "Consumer" permissions are effectively granted on a node of types cm:content, cm:folder or any of their sub-types (unless a more specific permission model applies to any sub-type).
The command
effectivePermission user <userName> permission <nameOfPermission> node <nodeRef>
checks wether the specified user has been granted or denied a specific permission on the specified node. This command can be used to check any permission or permission group. If an unknown permission is specified, the command will display the UnsupportedOperationException raised by the PermissionService. If a permission is specified, which is not applicaple to the specified node, the PermissionService will always report the permission as denied - even if the user in question is the almighty "admin" user itself.
The subsystems plugin provides commands to interact with the various subsystem instances active within an instance of Alfresco Repository, specifically to access their configuration properties, perform changes and revert any changes back to the original state as read from configuration files. Unless deactivated, the PropertyBackedBeanPersister provided by OOTBee Support Tools since version 1.1.0.0 will persist any configuration changes in the Alfresco database and reload them after a restart of the Alfresco Repository. In installations of Alfresco Enterprise, the PropertyBackedBeanPersister provided by OOTBee Support Tools should be disabled in favor of using the Alfresco default persister.
The command
listInstances
lists all currently instantiated / configured subsystem instances, regardless of their effective activation / enablement state. The output of this command will list each instance with its formal constituent identifier fragments (category, type, ID) of which the ID is used in all other commands of this plugin to refer to a specific subsystem instance.
The command
listProperties <instanceID>
lists all the configuration properties of a specific subsystem instance, divided into mutable and immutable properties, the latter of which may be exposed by subsystems at runtime for access to state information (e.g. status of SOLR server as retrieved via an HTTP admin call). The output will include the name of the property, its current value and a description of the property / its purpose, as far as such a description is being provided by the subsystem programmatically.
The command
setProperty <instanceId> <key>=<value>
sets the value of an individual mutable property of a subsystem instance. The affected subsystem will automatically restart.
The command
setProperties <instanceId> <key1>=<value1> <key2>=<value2> <keyN>=<valueN>
sets the value of multiple individual mutable properties of a subsystem instance in an atomic operation. The affected subsystem will automatically restart.
The command
removeProperties <instanceId> <key1> <key2> <keyN>
removes the values of multiple individual mutable properties of a subsystem instance. The affected subsystem will automatically restart. This operation does not reset the value back to the original value as configured in property files as such an operation is actually not supported by the underlying Alfresco APIs.
The command
revert <instanceId>
reverts all properties of a subsystem instance to the values as configured in property files, removing any configuration overrides stored in the database. The affected subsystem will automatically restart.