FoD/SSC: Reconsider commands/options for managing app/user/group assignments

[rsenden]

SSC & FoD modules currently provide a very different command/option structure for managing user assignments to apps/versions/groups:

SSC:

• fcli ssc appversion create --add-users ...
• fcli ssc appversion update --add-users ... --rm-users ...
• fcli ssc appversion-user add ... --appversion ...
• fcli ssc appversion-user delete/rm ... --appversion ...
• fcli ssc appversion-user list/ls
• fcli ssc user: Only manages user details, not assignments

FoD:

• fcli fod app create-*: Only has option to assign groups, not individual users
• fcli fod app update: No options to add/remove users/groups
• No fcli fod app-user add/delete/list commands
• fcli fod user create --applications ... --groups ...
• fcli fod user update --add-apps ... --remove-apps ... --add-groups ... --remove-groups ...
• fcli fod user-group create --applications ... --users ...
• fcli fod user update --add-apps ... --remove-apps ... --add-users ... --remove-users ...

Observations:

• fcli ssc allows for (mass-)assignments of users to a single appversion, whereas fcli fod allows for (mass-)assignment of apps to a single user (and fcli fod allows for mass-assignment of users to groups and groups to users)
• fcli ssc allows for listing users assigned to particular appversion, fcli fod doesn't
• Neither fcli ssc or fcli fod allow for listing the apps/versions/groups to which a particular user has been assigned
• Differences in option names; fcli ssc ... --rm-* vs fcli fod ... --remove-*
• Most fcli commands are atomic in nature, based on a single REST endpoint, whereas many of the commands above combine multiple REST calls in a single command

We should come up with a consistent command/option structure between fcli ssc and fcli fod modules that allows for providing a full feature set, with functionality for listing/managing assignments at both user-level and entity-level, like adding/listing/removing (one or more) users for an individual app/version, and add/list/remove (one or more) apps/versions for an individual user.

Primary question is whether we want to represent assign/remove actions as options (like in the current fcli fod user update --add-apps/add-groups options), or as actions (like in the current fcli ssc appversion-user add/rm commands)?

Modeled as options:

• Potentially more consistent with SSC/FoD UI
• Goes against fcli principles of having actions modeled as sub-commands
• Goes against fcli principles of having atomic actions
• Allows for creating app/version and assigning users/groups with a single fcli command
• Doesn't provide a good place for having commands that list current assignments from either user or entity perspective

Modeled as sub-commands:

• Less consistent with SSC/FoD UI, where user/group assignments are part of the 'create' wizard
• Better consistency with other fcli commands and fcli principles
• Requires multiple fcli invocations; first create app/version, then assign users (or first create user, then assign apps/versions, depending on use case)
• Allows for a proper list command next to the add/rm commands

When choosing the sub-command based approach, what would be the best command structure? Some examples:

• fcli fod app add-users versus fcli fod app-users add, and fcli fod user add-apps vs fcli fod user-apps add?
  • Separate entity allows for reusing existing action commands and aliases like add/rm/remove, but having multiple app-* entities may look a bit less attractive
• Singular or plural entity/sub-command names? I.e., fcli fod app add-user vs fcli fod app add-user, or fcli fod app-users add vs fcli fod app-user add?
• Separate commands for assigning users to single app/version and for assigning apps/versions to single user (fcli fod app-users <users> --app <single-app> and fcli fod user-apps add <apps> --user <single-user>), or single command for (mass-)assignments in both ways (fcli fod app-users add --apps <apps> --users <users> and/or fcli fod user --apps <apps> --users <users>)?

Any other ideas/suggestions/preferences?

[kadraman]

FoD UI only allows groups to be added at creation time so that's all I put on fod app create - we could also have users as an option but it would required another API call so not atomic. It might be better to remove groups option and rely on separate and subsequent commands to do this (like below).

FOD UI allows users and groups to be added to app, so we definitely need that; I do like fod app add-users, fod app remove-users, fod app add-groups, fod app remove-groups.

FOD UI also allows users/groups to be explicitly assigned to applications so I think it might make sense to keep these options on fod user create|update and fod group create|update.

FOD UI also allows users and groups to be explicitly assigned to applications - so these should probably be kept?

[rsenden]

Another consideration to keep in mind; in general, all actions within a single entity should return/output the same record type. For example, ideally, all fcli fod app * commands should output app records. Commands for adding/removing/listing users/groups will likely output user records, and hence should probably be under a separate parent command like app-user.

[psmf22]

In my opinion having an app-user command makes sense and would also give us a good place for list commands in either direction like fod app-user list-apps --user or fod app-user list-users -appid

I think for clarity´s sake having separate add commands would be preferable, though under a single entity. For example fod app-user add-apps --user --apps and fod app-user add-users --appid --users

In case we would like to enable both way mass assignment having a single fod app-user add --apps --users command would be my preference.

[rsenden]

@psmf22 Thanks for the input. Apart from assigning users, we'll also need to be able to assign groups (and for SSC, assign local users or LDAP entities). Should we have separate entities, like fod app-user and fod app-groups, or maybe have a generic fod app-access instead? Thoughts?

[rsenden]

For now, we've decided to postpone this decision until after 2.0.0 has been released. In FoD, all commands and options related to assigning users/groups/... have been marked as PREVIEW or DEPRECATED (to be double-checked that all relevant commands and options have been covered), don't remember for sure whether this has also already been done for SSC, otherwise this should be done before releasing 2.0.0.

[rsenden]

For SSC, I've now implemented an access-control entity for managing roles, users, and user assignments. Adding/removing users to an appversion is (for now) done through the appversion create/update commands, not sure whether we should (also) have dedicated user assignment commands under access-control. Also not sure whether we should (also) have an appversion list-users command.

For FoD, we should probably adopt a similar structure, moving current user and user-group commands to a new access-control entity.

[rsenden]

A new access-control entity has now been implemented for FoD as well, so this issue can be closed.