AdminUsersFeature Customization

Hi @myth

I’m playing with SS AdminUsersFeature. Just a couple of questions on this if you do not mind.

  1. How do we enable the AddPermissions Dropdown in default screen

  1. As I have a lot of permissions I normally have a couple of “default permission sets” (as in screen above) so that I don’t end up selecting say 30 permissions in the dropdown. Is there a way to incorporate something like this in the standard UI for AdminUsersFeature ?

  2. Is there a way to see the existing password of the user selected ?

  3. What is the recommended way to update the password for a user in the code behind. (not using the UI ) ?

  4. In displaying the Users in the default table , is there a way to add say a highlighted color for rows where the User Account is locked for example ?

  1. I assume grouped rows are not supported in the SS Datagrid / AdminUsersFeature Grid ?

    I normally like to display grids with option to use a groupby feature as in example below.


Thanks in advance.

The available roles and permissions is discovered from the ValidateHasRole/ValidateHasPermission Request DTO attributes or the RequiredRole/RequiredPermission service attributes in the code-base. So your APIs need to use them for them to be available.

No, storing plain-text passwords would be a major security risk.

The UI uses APIs defined in AuthDtos.cs, e.g. the Admin UI uses AdminUpdateUser:

Here’s the client code used to update the password:

No, you can propose feature requests in

Nope, it doesn’t support grouping.

Thanks @myth,

Just for clarity, you are saying that by default the AdminUsersFeature UI cannot incorporate permissions except if I rebuild the view with added functionality ?
Any reason why this was not included by default in this View as I would assume permissions to be a feature that most devs will use ?

On viewing the password I’m implying the password will be stored as it is currently in the DB but the admin user can see (view) the password in the admin panel.

Thanks ,

There are no storage of Permissions and Roles anywhere, the only way ServiceStack can now about them is by scanning what Roles and Permissions are used to protect Services.

There’s no way an App can view a password that wouldn’t be susceptible from a Hacker from also viewing the passwords which is why passwords are only stored in one-way hashes which can’t be reversed by anyone to reveal the original password.

Thanks @mythz,

OK now I get it ;))

1 Like

One last question,is there perhaps a pre-submit event or something on the default view where I can incorporate some logic for the “default permission sets” as explained initially ?

The UI is powered by the AppMetadata which you have an opportunity to modify with something like:

appHost.ModifyAppMetadata((req, metadata) => {
    var adminUsers = metadata.Plugins.AdminUsers;
1 Like