I suppose that this data might be embedded in commands headers (ie. in script commands) so it might in script look like:

/*
 Activate on the server user tracking mechanisms to aid in problem resolution.
 AS:Description: Activate log tracker for a user
 AS:CommandId: http://jabber.org/protocol/admin#add-user-tracker
 AS:Component: sess-man
 AS:Group: Logging
 */

This additional information could be retrieved:

1. using additional command (ie. retrieve-admin-commands)

2. adding additional group attribute to <item/> element of disco#items discovery data returned by server

First solution would allow us to simple add this feature and easily add support on client side, while secondary solution would be more generic, but we would need to adjust our client library to be able to retrieve this group data.

Andrzej Wójcik wrote:

I suppose that this data might be embedded in commands headers (ie. in script commands) so it might in script look like:

[...]

This OK, that's what I was thinking about.

This additional information could be retrieved:

using additional command (ie. retrieve-admin-commands)

adding additional group attribute to <item/> element of disco#items discovery data returned by server

First solution would allow us to simple add this feature and easily add support on client side, while secondary solution would be more generic, but we would need to adjust our client library to be able to retrieve this group data.

I prefer the second approach from the performance point of view. The first, however, gives us more flexibility. I think we should just experiment which works better for us.

I am assigning this task to you Andrzej, as you will most likely be implementing this on the client side, so it is best to make modifications on the server side as well.

Added support for passing grouping information in adhoc commands metadata and ability to retrieve it using disco#info and custom adhoc command.

We still need to add grouping information to commands.

I tried to create names of particular groups and add them to adhoc command scripts but I've found an issue with this grouping idea, as we create a name for a group for a command and it is ok if command is for single component, but what if command is for more than one component? Example:

CompRepoItemAdd.groovy is Add new item named command which works for VHostManager and ExtComponent so it should appear in two separate groups: VHost management and External components, right? But how to define it as we have only single field and single instance of file(to aviod multiple copies of same script) in source code?

We might try to get all commands from sess-man and display them in groups as specified in scripts (AS:Group:) and display commands for any other component grouped by component name so we would get something like in example below:

Users

Add user

Delete user

Configuration

Manage active server plugins

Manage active server components

VHost Manager

Add new item

Delete item

External component

Add new item

Delete item

Statistics

Get active users

I think grouping by component makes sense in most cases. Alternatively we can have a command assigned to multiple groups:

AS:Group: host-management,ext-comp

Yes, but then UI would not know which group is assigned for which component jid which would make it impossible to use this solution.

I also thinked about using this group with some kind of template, ie.

${componentName} could be resolved to VHost Manager in case of VHostManager and to Ext component in case of ExtComponent

and this way we could create groups even more complex ie.

Components/${componentName} would be resolved to Components/VHost Manager in case of VHostManager

Ok, let's do as you suggest.

Added support for replacing ${componentName} in group with name of component presented in service discovery.

I left adhoc commands scripts unchanged for now (will not include ${componentName} in groups. Will update them when during work on service management console as them we would establish correct group names.