find users of given role?

http://www.sun.com/servers/midrange/m5000/

Is there a way to find all users of a given role (out of the box)? I looked through various clt options but could not find this. I have a script to do it, but out of the box would be nice. Example:

Searching for users of "beta"...
for i in `$iw-home/bin/iwuseradm list-users -t | awk '{print $1}'`; do
  for p in `$iw-home/bin/iwuseradm all-roles-of-user $i`; do
    if [ "$p" = "beta" ]; then
      echo $i
    fi
  done
done

The issue you have to account for is that with 6.7x the roles (other than Master) are branch-specific - so you need to account for that in your loop above (probably in between 'i' and 'p')

jed

The issue you have to account for is that with 6.7x the roles (other than Master) are branch-specific - so you need to account for that in your loop above (probably in between 'i' and 'p')

Yeah. We don't constrain based upon branch so I can make assumptions. All roles are always assigned at the root level.

If I were to do this for portability, I would want to compare against a given area.

Side note: I actually ended up sorting the data in my real script since some users are assigned to the same role in different locations (for whatever reason).

My script ended up being:


# cat /app/suncom/iw-home/local/bin/list-role-members 
#!/bin/sh

if [ -z "$1" ]; then
    echo "$0 "
    exit
fi

iwhome=`iwgethome`
tmp=`mktemp`

for i in `$iwhome/bin/iwuseradm list-users -t | awk '{print $1}'`; do
  for p in `$iwhome/bin/iwuseradm all-roles-of-user $i`; do
    if [ "$p" = "$1" ]; then
      echo $i >> $tmp
    fi
  done
done
sort -u $tmp
rm $tmp

*EDIT*
Actually, looking at "all-roles-of-user" usage, I may not need to do a unique sort.

>> List all the roles has anywhere in the system. <<

Eh..whatever. We have CPU cycles to spare Smiley Happy

I think I found the right CLT:

iwaccess all-permission-entries /default/main | egrep -i "\trole\t" | awk -F\t '{print $1}'

I did something earlier today, in Perl, on Windows (in a WFT):[html]sub iw_getrole{
my $role = shift;
my $branch = __VALUE__('iw_branch');
my $cmd = qq($iwhome/bin/iwaccess permission-entries $branch -inherited -expand-groups);
my @results = grep { /\b$role\b/i && s/\t.*\n//} qx($cmd 2>&1);
my $html = qq(\n\n);
foreach (sort @results){
$html .= qq($_\n);
}
$html .= qq(\n);
return($html);
}[/html]Enjoy!

OOTB, Perl Module:

TeamSite::Flexroles

# Return a list of sorted unique users who are having the specified roles.
#
# Inputs: $vpath - The vpath which the roles are obtained from.
# @roles - An array of role names for getting the users.
#
sub get_users_having_roles($vpath, @roles)

This API should cover all the corner cases. Such as inherited roles, users from groups, master role, etc...

--Michael

OOTB, Perl Module:

TeamSite::Flexroles

# Return a list of sorted unique users who are having the specified roles.
#
# Inputs: $vpath - The vpath which the roles are obtained from.
# @roles - An array of role names for getting the users.
#
sub get_users_having_roles($vpath, @roles)

This API should cover all the corner cases. Such as inherited roles, users from groups, master role, etc...

--Michael

Ah yes, I keep forgetting about that module because it doesn't have any POD doc so you have to find it and read the code.

As it happens, it uses:

$iwhome/bin/iwaccess permission-entries "$vpath" -inherited -expand-groups

I had forgotten about the use of the two flags at the end in my previous code snippet (I'm going to update that today) - but note that the method only uses "permission-entries" not "all-permission-entries" - which I believe is a significant difference here.

Using all-permission-entries - you should be able to get information about all users who occupy a role anywhere within the provided vpath and it's sub-branches. E.g. using /default/main you'll get information about /default/main, /default/main/****/yyy/zzz, etc.

Using just permission-entries - you will only get information about the specific branch vpath provided. E.g. using /default/main/**** you will not get information about /default/main/****/yyy/zzz, etc.

Heh - just edited my previous entry, and realized I had forgotten to make it say all-permission-entries there too :-) Fixed.

Ah yes, I keep forgetting about that module because it doesn't have any POD doc so you have to find it and read the code.

As it happens, it uses:
$iwhome/bin/iwaccess permission-entries "$vpath" -inherited -expand-groups
I had forgotten about the use of the two flags at the end in my previous code snippet (I'm going to update that today) - but note that the method only uses "permission-entries" not "all-permission-entries" - which I believe is a significant difference here.

Using all-permission-entries - you should be able to get information about all users who occupy a role anywhere within the provided vpath and it's sub-branches. E.g. using /default/main you'll get information about /default/main, /default/main/****/yyy/zzz, etc.

Using just permission-entries - you will only get information about the specific branch vpath provided. E.g. using /default/main/**** you will not get information about /default/main/****/yyy/zzz, etc.

Good info!
So depend on what you actually want to retrieve. We may want to provide that option too in the module.

Hi, can you please give your suggestions about the following:

1. sub get_users_having_roles($vpath, @roles)
If we are looking for all existing editors(not related to any particular branch), what value should we give to $vpath? We are testing with '/default/main'. Is that correct?

2. $html = convert_list_to_html_select(" ",1,undef,@usersList);
We also tried with value as "" or undef.
a. The default value space/empty (select) option is not showing in the result.
b. The domain and users names are showing in capital letters, we would like to show as it is.
Is there any work around for this by using this function?

If we write our own code for this, we could use lc() to convert into lower case. But we may not get the actual results if we want. For example, domain\fred, DOMAIN\REETA. It would be better to follow one, but just checking the possibility of getting as it is.

3. Is there any better way for this?

4. Can we add our own attribute to the following tag(tsusers.xml)? Our intention is to add department here. So that we could get only the editors of Department1.
[html] [/html]

Thanks in advance.

Environment:
TS 6.7.1 SP1, Windows 2003 SP1

Hi, can you please give your suggestions about the following:

1. sub get_users_having_roles($vpath, @roles)
If we are looking for all existing editors(not related to any particular branch), what value should we give to $vpath? We are testing with '/default/main'. Is that correct?

As currently written - the module function will not do what you need - instead you need to use the code posted previously (for the reasons described previously).

2. $html = convert_list_to_html_select(" ",1,undef,@usersList);
We also tried with value as "" or undef.

As mentioned, the documentation is lacking - but if you look at the code, I believe you could use 0 (zero) for the first argument - to indicate that there is no default value. ...

a. The default value space/empty (select) option is not showing in the result.
b. The domain and users names are showing in capital letters, we would like to show as it is.
Is there any work around for this by using this function?

Again - learn to read the code. There is nothing there that inserts an empty option into the list - which then means that a default of 0 means that you will most likely see the first entry in the list by default instead of "nothing". I'd consider this a bug in the code - I'd rather have a parameter for indicating if you want a blank entry, and handle it appropriately.
The work-around is to parse / modify the results that you get back from this method - something like (untested):

my $html = convert_to_html_select(....);
$html =~ s|(<select[^>]*>)|$1\n<option></option>\n|sm;
...

If we write our own code for this, we could use lc() to convert into lower case. But we may not get the actual results if we want. For example, domain\fred, DOMAIN\REETA. It would be better to follow one, but just checking the possibility of getting as it is.

3. Is there any better way for this?

4. Can we add our own attribute to the following tag(tsusers.xml)? Our intention is to add department here. So that we could get only the editors of Department1.
[html] [/html]

WRT '3' - you can always write your own code. The advantage is you know what it is (hopefully) and have full control over it. The disadvantage is that you write the code and have to maintain it.

WRT 4 - No. You cannot do custom augmentation of tsusers.xml.

Ghoti, thanks for your valuable input with clear details. I appreciate that, you are big brother to this community.

Sorry, I missed that point from the following code (convert_to_html_select(...)) :
[html]
if (!$default) { $default = ""; }
if ($default eq $_) {
$x = " $_\n";
[/html]
I thought we have to give a string value to be selected. But there is no code for getting the empty option. Whether we give 0 or ""(other than the any value from the list), it will select the first value. The documentation is also not clear.

I think I found the right CLT:

iwaccess all-permission-entries /default/main | egrep -i "\trole\t" | awk -F\t '{print $1}'

...

Well, with a bit more realistic testing (on a real server instead of my very limited personal server) - it turns out I was wrong (see, I can admit it ;-)
iwaccess all-permission-entries only shows the role of the branch owner for every branch on the system (for those who care, this is a fairly easy way to ge a complete list of branches - but that's not what we were looking for right now)

iwaccess permission-entries vpath -inherited -expand-groups will show you information about the vpath and it's predecessors (at least for those roles that were inherited) - but it does not work in reverse. I.e. if you provide just /default/main as the vpath - you get the information for /default/main only.

I think you could either do what was originally proposed (by jed) or use a combination of these two commands in a similar loop. So - back to the original post:

s there a way to find all users of a given role (out of the box)?

Actually, now that I think about it some more, my code will work - for my situation - except that I have to use permission-entries not all-permission-entries

Originally Posted by jed
s there a way to find all users of a given role (out of the box)?

If that is what you meant as Fish explained, it is unnatural to the principal of flexroles. Just curious, what is the purpose of finding users of a certain role without a branch context?

In our case, we want to display only the editors in a drop down box.

jed

If that is what you meant as Fish explained, it is unnatural to the principal of flexroles. Just curious, what is the purpose of finding users of a certain role without a branch context?

In my use-case, we do not define roles at the branch level. We always fix the role to the root (or store or whatever the lowest level is). So, if someone is in a role, I can assume that role will work for every branch.

Side note:
I really only need this list because I created a new "beta" role for new UI options and I forgot who I assigned it to Smiley Happy

roat, jed,
In flexroles, a role doesn't exist without a branch context. The definition of a role (except the Master role) is a set of actions that a user is allowed to perform within a branch.

The query of get me all users having role X in any branch in TeamSite, is similar to ask for get me all users having write permission on any directory in the filesystem. It can still be done by custom scripting, but it is just not a common query that is provided OOTB, yet.

--Michael

roat, jed,
In flexroles, a role doesn't exist without a branch context. The definition of a role (except the Master role) is a set of actions that a user is allowed to perform within a branch.

The query of get me all users having role X in any branch in TeamSite, is similar to ask for get me all users having write permission on any directory in the filesystem. It can still be done by custom scripting, but it is just not a common query that is provided OOTB, yet.

--Michael

While I agree with the rationale - if IWOV added the functionality of -

-expand-groups

to the all-permission-entries and/or export-permission-entries sub-commands, one would be able to parse the results of a single CLT call to retrieve the information that was desired here. While that might be of limited use (for jed mosly ;-) it would have the added benefit of being able to review all the role-assignments for the entire server by an administrator or security person or whatever.

Just a thought...

We could write the custom code, no problem with that.

But it would be better to have a generic function to grab all users of each role from tsusers.xml file without depending on any branch.

Previously we were using this function to find all users having editor role:
use TeamSite::Usertask qw(get_names_from_file);