DISCUSS: User Management

GoogleCodeExporter commented 9 years ago

Documentation: https://handbook.arctosdb.org/documentation/sharing-data-and-resources.html

Code: https://github.com/ArctosDB/documentation-wiki/edit/gh-pages/_documentation/sharing-data-and-resources.markdown

[ ] @KyndallH suggests how to video
[ ] http://handbook.arctosdb.org/documentation/sharing-data-and-resources.html needs some gaps filled in. I added a blurb, but I think a user's perspective is needed.
[ ] There are a lot of empty cells on the 'read this' table; we need more documentation, particularly video.
[ ] It would be useful if documentation occasionally mentioned what NOT to do - "if THAT, then editing THIS will alter 70,000 specimens and turn into a huge mess, so instead I'll...."
[x] There's some documentation at http://handbook.arctosdb.org/documentation/users.html, but it should be beefed up. If I wanted to "hack" Arctos I'd probably start by just asking someone to give me access....added this to the documentation index - probably no one was seeing it!
[x] Add link to this issue
[x] Add navigation

What steps will reproduce the problem?

1. Let admin users grant anyone their rights

- What is the expected output? 

Users awesomifying collections after having carefully read the documentation.

- What do you see instead?

Users apparently hurling fingers in the general direction of their keyboard.

Please use labels and text to provide additional information.

There are dangerous forms in shared nodes (eg, containers) and there are users 
who create extremely unexpected error messages from these forms. I suggest the 
AC should take a more active role in monitoring access to shared nodes, or 
limit grant access, or provide a test before allowing access (Gordon's best 
idea ever!), or SOMETHING. It seems only a matter of time before someone who 
should perhaps not yet have admin access finds a way to cause significant 
damage to an unrelated collection.

Original issue reported on code.google.com by dust...@gmail.com on 18 Aug 2015 at 3:05

KyndallH commented 8 years ago

As one of those people that have had my objects moved by other institutions, I agree this is an issue though minor (only has happened to my knowledge a handful of times to me).

Instead of making other people have to pass a test, they should not have the ability to change things in institutions that they do not have privileges to. If I have an UAM barcode, MSB should not be able to move it. I rely heavily on students having the ability to move my objects around and add specimens to loans so they need those privileges. I don't want to restrict it to collections within institutions because in Genomic Resources, I work with barcodes from several collections. I'd prefer not to give my students intimidate access to all the collections at UAM and I doubt curators want them to have that level of access.

dustymc commented 8 years ago

they should not have the ability to change things in institutions that they do not have privileges to

We've had that discussion in the past (although I can't find it....) and the consensus was to keep containers globally shared and barcodes globally unique.

The current container logic prevents update of containers unless the user has access to a collection in the institution to which the affected containers belong, which probably more or less prevents one of the situations which lead to this issue. Stronger enforcement of that (eg, put containers in VPDs) is technically possible, and I don't really have any strong opinions on how it should work.

I do have stronger opinions regarding more-shared nodes (eg, Agents), and believe that we do need to generally improve training/documentation/something, somehow.

KyndallH commented 8 years ago

I actually like having shared agents since people often borrow specimens from multiple institutions or collect specimens in other institutions. I like being able to see where they are borrowing specimens from (though I can't see what specimens). I like being able to update data on shared agents. I don't delete, just update with more current shipping information or a new student. Nice to keep track of an individual through institutions.

I don't mind having shared barcodes either though I'd prefer people not having the ability to move my specimens. By having the history makes it easy to fix if mistakes happen.

campmlc commented 8 years ago

I agree that we absolutely need to limit the ability of one collection to move another collections barcodes. We have a situation that some of MSB's old legacy in-house DGR locator NK system barcodes (>400,000 records) match UAM Arctos barcodes. As we transition into Arctos object tracking, occasionally a student will scan the wrong label, but it should not result in the movement of UAM samples to MSB. I agree that shared agents are very useful.

dustymc commented 8 years ago

agents .... multiple institutions

Yea, that's my stronger opinions. I've made better hundreds (thousands?) of agents from cross-collection data, and I'm not the only one doing so. There are MSB parasite field notes with UAM specimens, etc., etc., etc., and agents is the key to that. It's hugely powerful and I'd fight changing it.

Barcodes - well, lots of semi-theoretical reasons to share them - it'd be nice to see that MVZ knows where the junk you loaned to them is, etc. - but whatever, it's not really useful in the same way agents/localities/etc. is. (Insect collections may have a less-waffly outlook.)

occasionally a student will scan the wrong label, but it should not result in the movement of UAM samples to MSB

It doesn't, anymore, probably. (It's not a table-level rule so MAYBE there's a way around it, but not one I can find.) campmlc seems to have access to UAM collections (probably other users in similar situations for various reasons), so still lots of reasons to be very aware of what's going on when working in a shared system.

mkoo commented 8 years ago

AWG 2016-08-01: iDigBio webinars for Arctos, specifically localities,citations, to help people understand the data model and consequences of their curatorial actions

campmlc commented 6 years ago

Status of this? Do we need an Agents webinar?

mkoo commented 5 years ago

closed by AWG 3/7/2019. Manage collection users can grant collection access to their local users.

dustymc commented 5 years ago

Manage collection users can grant collection access to their local users.

That has never been the problem.

ccicero commented 5 years ago

Manage collection users can grant collection access to their local users.

NOT TRUE. You actually need global admin to grant operator permissions.

I'm re-opening this issue (and bringing back Priority-Critical) based on email conversation with Dusty 9 Apr 2019 in response to a new collection trying to grant permissions.

From Dusty:

I think there's some value in the separation between "manage your stuff" and "manage stuff that everyone uses" (and maybe "let your techs manage stuff that everyone uses" should be even more separated, somehow)
I don't know how to safely make that happen for new users - this stuff was all developed when Arctos was much smaller and growing much slower, and new users were generally across the hallway from experienced users.

So I think there are two conversations here:

1) the technical stuff - do we need to revise the roles, introduce more roles, etc. 2) the social stuff - what sort of training (if any) do we require before giving UserA RoleZ?

And http://handbook.arctosdb.org/documentation/users.html is correct-ish, but it's still static rather than pulling from the table that controls Arctos.

At the very least, you shouldn't need global admin to grant operator permissions!

campmlc commented 5 years ago

Agree we need to revisit this. This is another reason that new collections absolutely need to be working with a mentor. We are bringing in a lot of inexperienced people all at once who shouldn't be given access to tools that might affect others. Ideally we'd train one person at each institution thoroughly, and then have them train and monitor others, but the learning curve is very steep and will be an ongoing process. We need some supervision. How to do we limit access in the meantime?

On Tue, Apr 9, 2019 at 10:05 AM Carla Cicero notifications@github.com wrote:

Manage collection users can grant collection access to their local users.

NOT TRUE. You actually need global admin to grant operator permissions.

I'm re-opening this issue (and bringing back Priority-Critical) based on email conversation with Dusty 9 Apr 2019 in response to a new collection trying to grant permissions.

From Dusty:

I think there's some value in the separation between "manage your stuff" and "manage stuff that everyone uses" (and maybe "let your techs manage stuff that everyone uses" should be even more separated, somehow)

I don't know how to safely make that happen for new users - this stuff was all developed when Arctos was much smaller and growing much slower, and new users were generally across the hallway from experienced users.

So I think there are two conversations here:

the technical stuff - do we need to revise the roles, introduce more roles, etc.

the social stuff - what sort of training (if any) do we require before giving UserA RoleZ?

And http://handbook.arctosdb.org/documentation/users.html is correct-ish, but it's still static rather than pulling from the table that controls Arctos.

At the very least, you shouldn't need global admin to grant operator permissions!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/745#issuecomment-481316186, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hBnqlgTQZivuPFzaQY3SOHw2eDK6ks5vfLpBgaJpZM4HMCk2 .

dustymc commented 5 years ago

shouldn't need global admin to grant operator permissions

Elaborate please.

I don't see how permission to manage "local" things (create specimens, delete identifications, etc.) should come with the ability to grant access to manage global/shared things (agents, taxonomy, etc.) to other users. Those seem like two very distinct "training levels" to me. (Three actually - the grantor should also know how to USE the things they're granting in sufficient detail to explain them to the grantee.)

I also understand that a new curatorial user needs to invite operators and give them sufficient access, and to manage shared things (eg, agents are generally encountered very early in the migration process).

I don't know how to reconcile those things.

http://handbook.arctosdb.org/documentation/sharing-data-and-resources.html

dustymc commented 5 years ago

AWG consensus:

write better docs re: giving users access to shared data then
move creating users to manage_collection

dustymc commented 5 years ago

Status: Need clear documentation regarding access to shared/scary roles linked from the manage users form before adjusting permissions.

mkoo commented 5 years ago

Elevating again @dustymc We need a new role, call it manage_operators (or something like that) for these functions: Invite users to become operators; grant and revoke rights from users and Operators; unlock,lock users etc

This will separate these more routine tasks from access to global variables and other scary forms.

Once this new role is made, we can follow up with documentation. This is becoming much more critical with new collections coming onboard.

campmlc commented 5 years ago

I agree.

On Mon, Jun 10, 2019 at 2:11 PM Michelle Koo notifications@github.com wrote:

Elevating again @dustymc https://github.com/dustymc We need a new role, call it manage_operators (or something like that) for these functions: Invite users to become operators; grant and revoke rights from users and Operators; unlock,lock users etc

This will separate these more routine tasks from access to global variables and other scary forms.

Once this new role is made, we can follow up with documentation. This is becoming much more critical with new collections coming onboard.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/745?email_source=notifications&email_token=ADQ7JBH25FL5DSDJGQ2CHG3PZ2YNDA5CNFSM4BZQFE3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLC42I#issuecomment-500575849, or mute the thread https://github.com/notifications/unsubscribe-auth/ADQ7JBCTQ6X223RLYMZAL6LPZ2YNDANCNFSM4BZQFE3A .

dustymc commented 5 years ago

manage_operators

OK, I'm digging it so far....

we can follow up with documentation

Let's don't?? We have documentation that apparently isn't read. I'm not anxious to downgrade that!

The new role will essentially give access to https://arctos.database.museum/AdminUsers.cfm?action=edit&username=mkoo. Understanding the role itself is easy. Understanding the implications of using the role is not. Users who can get to that page can share their rights - you can give anyone rights to access anything in the two tables at the bottom. You have manage_geography, so that includes providing access for that student you just hired yesterday to fundamentally alter the nature of anything/everything in Arctos. Changing https://arctos.database.museum/geography.cfm?geog_auth_rec_id=69 to "fix a specimen" changes 121719 other specimens in about 70 collections, for example.

I think http://handbook.arctosdb.org/documentation/sharing-data-and-resources.html is the "root page" (or at least it's intended to be). Everything above, along with the specifics of what roles do, should be in the big red "Read this before assigning roles to users" box.

1) how can that documentation be made better? 2) how can we assure that people wielding this power haven't scrolled past the big red box?

I suppose I could be convinced to go this way, but it seems backwards to me and it's not what we discussed in the AWG meeting. I think we need the documentation cleaned up first.

Jegelewicz commented 5 years ago

We need to assign someone to write this documentation.

Jegelewicz commented 5 years ago

@KyndallH suggests how to video

Jegelewicz commented 5 years ago

Roll manage operators into manage collection and out of global admin.

Jegelewicz commented 5 years ago

Need new issue to move create DOI to manage collection

Jegelewicz commented 5 years ago

Need to write better descriptions in http://arctos.database.museum/Admin/user_roles.cfm to detail what a user with the role can actually do.

Jegelewicz commented 5 years ago

Change [Def] to "see what this allows a user a to do".

Jegelewicz commented 5 years ago

Add column to http://arctos.database.museum/Admin/user_roles.cfm "suggested user type" aka "new user", "experienced user", etc.

dustymc commented 5 years ago

add access_to_shared_data(y/n) column

Jegelewicz commented 5 years ago

add access_to_shared_data(y/n) column

Maybe more than that? WHAT shared data?

Jegelewicz commented 5 years ago

Work on this here.

dustymc commented 5 years ago

after spreadsheet is reintegrated, make columns sortable

dustymc commented 5 years ago

add column: form access, pull from Admin/form_roles.cfm
add filter by role to Admin/form_roles.cfm

dustymc commented 5 years ago

Spreadsheet structure is finalized; implement the structure

ccicero commented 5 years ago

@campmlc @dustymc Should we schedule a call with just the three of us to actually work on the documentation? I think it will happen faster if we do that. I can make the edits with a shared screen, but it would be helpful to have input as I go along.

dustymc commented 5 years ago

roles table is rebuilt
"read this" form is rebuilt and editable by manage_documentation
view form access form is filterable and linked
manage_collection should be able to manage users

Still to-do:

http://handbook.arctosdb.org/documentation/sharing-data-and-resources.html needs some gaps filled in. I added a blurb, but I think a user's perspective is needed.
There are a lot of empty cells on the 'read this' table; we need more documentation, particularly video.
It would be useful if documentation occasionally mentioned what NOT to do - "if THAT, then editing THIS will alter 70,000 specimens and turn into a huge mess, so instead I'll...."
Users are still demonstrably not reading the documentation. I maintain that users who are not willing to read documentation should not have access to anything that they can break, but it's not MY stuff they're breaking so... I still have little idea what to do about that given our current resources.

The role change means that the below operators can now give their rights, including the right to give rights, to others, whether they understand the implications of doing so or not. If there was a "uber-critical" priority I'd be using it for this...

MANAGE_COLLECTION

ABOTT (LOCKED)
ACDOLL (OPEN)
ACHINN (OPEN)
ACOCONIS (OPEN)
ADHORNSBY1 (OPEN)
ADRIENNER (OPEN)
AECARRIER (LOCKED)
AEROCHILD (OPEN)
AGOROPASHNAYA (OPEN)
AHABERSKI (OPEN)
AJLINN1910 (OPEN)
AKROHN (OPEN)
ALANBATTEN (OPEN)
ALINDSAY (LOCKED)
ALISONWHITING (OPEN)
AMCARRIL (OPEN)
AMSNYDER (LOCKED)
ANDREASRD (LOCKED)
ANDRES_LOPEZ (OPEN)
ANDY (OPEN)
ANNA1992 (LOCKED)
APPAYNE (LOCKED)
AREN (OPEN)
ARGASTALDI (LOCKED)
ATROX (OPEN)
BBJOHNSON3 (OPEN)
BETHANY (LOCKED)
BFLUKER (OPEN)
BJOHNSON_DMNS (OPEN)
BKATAFIA37 (LOCKED)
BMCCALL (OPEN)
BRANDI (LOCKED)
CAMPMLC (OPEN)
CAMWEBB (OPEN)
CARLSLIEB (OPEN)
CAROLYN (OPEN)
CBABBITT (OPEN)
CCARTER (LOCKED)
CCICERO (OPEN)
CDARDIA (LOCKED)
CEMYERS (LOCKED)
CHPHILLIPS (LOCKED)
CMGIENGER (OPEN)
COA_MMESSINA (LOCKED)
COA_NDUGGAN (LOCKED)
COA_SMURPHY (LOCKED)
COA_SSWANN (LOCKED)
CTALLMAN5 (OPEN)
CWITT (OPEN)
CWLINKEM (LOCKED)
DEMBOSKI (OPEN)
DGSTEWART (OPEN)
DHOUVENE (LOCKED)
DHUNT (OPEN)
DIAMSMCG (OPEN)
DIANNAKREJSA (OPEN)
DLM (OPEN)
DMCINTIRE2 (OPEN)
DPERRIGUEY (OPEN)
DROBERTS (OPEN)
EBRAKER (OPEN)
EELY (LOCKED)
EJBROCK (OPEN)
EKRIMMEL (LOCKED)
ESDEARMON (OPEN)
EWOMMACK (OPEN)
FFDSS (OPEN)
FFMRG (OPEN)
FMCARTER (OPEN)
FRIEL (LOCKED)
FSKBH1 (OPEN)
FTKEG (OPEN)
GARTHSPELLMAN (OPEN)
GJDELZER (OPEN)
GORDON (LOCKED)
HASMITH6 (LOCKED)
HDSPARKS (LOCKED)
HKBERRIOS (OPEN)
JACKKWATTS2397 (OPEN)
JBWILLIAMSON (OPEN)
JCABBOTT (LOCKED)
JCARLIS3 (LOCKED)
JEBRAD (OPEN)
JEGELEWICZ (OPEN)
JJWITHROW (OPEN)
JLDUNNUM (OPEN)
JLUNDQUI (LOCKED)
JMALANEY (LOCKED)
JMALANEY_1 (LOCKED)
JMALEY1 (OPEN)
JMETZGAR (LOCKED)
JOEY76909 (OPEN)
JOHANSENR (OPEN)
JOHWILLI (LOCKED)
JOSECOOK (LOCKED)
JTGIERMAK (OPEN)
JTSTEPHENSON (OPEN)
KATHERINELANDERSON (OPEN)
KDEWEY1 (LOCKED)
KEVINWINKER (LOCKED)
KLYBERGER (LOCKED)
KMDALY (OPEN)
KMINISSIAN (LOCKED)
KRGOMEZ (OPEN)
LAM (OPEN)
LAWALKER5 (OPEN)
LBROSKEY (LOCKED)
LEACHE (LOCKED)
LINDSEYFREDERICK (OPEN)
LJOHNSON10 (LOCKED)
LMTABAK (OPEN)
LOLSON (OPEN)
MALTMANN (LOCKED)
MARSZULO (OPEN)
MBOWSER (OPEN)
MBPRONDZINSKI (OPEN)
MJALBE (LOCKED)
MJANDERSEN (OPEN)
MKOO (OPEN)
MLELEVIE (LOCKED)
MLMOODY (LOCKED)
MONTEG (LOCKED)
NATALIE (LOCKED)
NGUYENMAY23 (LOCKED)
NICOLENY (LOCKED)
NICOLERIDGWELL (OPEN)
NMEDWARDS (LOCKED)
NROSE (OPEN)
OBEDHORNELAS (LOCKED)
OPHIS (OPEN)
PATTON (OPEN)
PDRUCKEN (LOCKED)
PETERSMILLER (OPEN)
PHRED (LOCKED)
RACZG (OPEN)
RAPFAFF (LOCKED)
RICKART (OPEN)
RJ3NN1NGS (OPEN)
RKNOWICKI (OPEN)
ROBSON (OPEN)
RWMARCOTTE (LOCKED)
SARA (OPEN)
SBIRKS (OPEN)
SCCOFFMAN (OPEN)
SHANE (LOCKED)
SHARPPHYL (OPEN)
SHAWNEEAMELIA (LOCKED)
SHIRAR (OPEN)
SKANIE (LOCKED)
SLIPHARDT (OPEN)
SOARMSTR (LOCKED)
SOTEROPOULOSD2 (OPEN)
STEFFI (OPEN)
SULLIVAN (LOCKED)
TIMO_SP (LOCKED)
TRUCKEY (OPEN)
TTEMPLEMAN (LOCKED)
TYOUNG42 (LOCKED)
VOLEGUY (OPEN)
VROHWER (LOCKED)
VTHILL (OPEN)
WILLIAMSON (LOCKED)

dustymc commented 5 years ago

These users can edit documentation, which writes code. They can fix help links, edit the user 'read this' documentation, add columns to specimenresults, map tail length to continent in everyone's downloads....

MANAGE_DOCUMENTATION

CAMPMLC (OPEN)
CCICERO (OPEN)
DLM (OPEN)
EKRIMMEL (LOCKED)
FFDSS (OPEN)
GORDON (LOCKED)
JBWILLIAMSON (OPEN)
JEGELEWICZ (OPEN)
LAM (OPEN)
LBROSKEY (LOCKED)
MKOO (OPEN)
SBIRKS (OPEN)

Do all of those users need that level of access?

Those data are available here:

and in the "Arctos Collection Report" that gets mailed out quarterly.

Maybe we need to make assigning shared/scary roles somehow involve AWG approval??

ccicero commented 5 years ago

Thanks D! Table looks good.

By "read this" form - Do you mean http://arctos.database.museum/Admin/user_roles.cfm?action=editSummaryTable ?

Also, can you provide a link to "view form access form is filterable and linked" (not sure what form this refers to)

And can you provide a list of the 'manage_collection' users by institution (or collection)? That will help to clean that up.

I don't think SBIRKS, GORDON, or EKRIMMEL need manage documentation. I don't know JBWILLIAMSON or LBROSKEY or FFDSS (Derek?), but the rest seems ok. Seems like we could/should add a few other active members of the AWG.

dustymc commented 5 years ago

Only a few of us can get that far, but yes http://arctos.database.museum/Admin/user_roles.cfm

The locked accounts are fine - it's useful to know what someone could have done, and they can't do anything now.

"view form access form is filterable and linked"

is...

eg you need at least coldfusion_user to see these forms: http://arctos.database.museum/tools/view_form_permissions.cfm?filter_role=coldfusion_user

list of the 'manage_collection' users by institution (or collection)?


BEGIN
  FOR R IN (
    select
            GRANTEE ,
            ACCOUNT_STATUS
          from
            DBA_ROLE_PRIVS,
            dba_users
           where
            DBA_ROLE_PRIVS.GRANTEE=dba_users.USERNAME and
            GRANTED_ROLE='MANAGE_COLLECTION' AND
            ACCOUNT_STATUS='OPEN'
          group by
            GRANTEE,
            ACCOUNT_STATUS
          order by
            GRANTEE
    ) LOOP
      DBMS_OUTPUT.PUT_LINE(R.GRANTEE);
      FOR C IN (
        select
          granted_role role_name
        from
          dba_role_privs,
          collection
        where
          upper(dba_role_privs.granted_role) = upper(replace(collection.guid_prefix,':','_')) and
          upper(grantee) = R.GRANTEE
      ) LOOP
        DBMS_OUTPUT.PUT_LINE('-->'||C.ROLE_NAME);
    END LOOP;
  END LOOP;
END;
/

ACDOLL
-->DMNS_BIRD
-->DMNS_EGG
-->DMNS_HERP
-->DMNS_INV
-->DMNS_MAMM
-->DMNS_PARA
ACHINN
-->CHAS_BIRD
-->CHAS_EH
-->CHAS_ES
-->CHAS_EGG
-->CHAS_ENTO
-->CHAS_FISH
-->CHAS_HERB
-->CHAS_HERP
-->CHAS_INV
-->CHAS_MAMM
-->CHAS_TEACH
ACOCONIS
-->UMNHOBS_MAMM
ADHORNSBY1
-->UNR_BIRD
-->UNR_EGG
-->UNR_FISH
-->UNR_HERP
-->UNR_MAMM
ADRIENNER
-->DGR_BIRD
-->DGR_MAMM
-->MSB_BIRD
-->MSB_FISH
-->MSB_HOST
-->MSB_MAMM
-->MSB_PARA
-->MSBOBS_MAMM
AEROCHILD
-->UTEP_ARC
-->UTEP_BIRD
-->UTEP_ES
-->UTEP_ENTO
-->UTEP_FISH
-->UTEP_HERB
-->UTEP_HERP
-->UTEP_HERPOS
-->UTEP_INV
-->UTEP_MAMM
-->UTEP_TEACH
-->UTEP_ZOO
-->UTEPOBS_ENTO
-->UTEPOBS_HERP
AGOROPASHNAYA
-->UAM_ALG
-->UAM_HERB
-->UAMB_HERB
AHABERSKI
-->UAM_ENTO
-->UAMOBS_ENTO
AJLINN1910
-->OWU_AMPH
-->OWU_BIRD
-->OWU_EH
-->OWU_ES
-->OWU_ENTO
-->OWU_FISH
-->OWU_GEOL
-->OWU_HERB
-->OWU_INV
-->OWU_MAMM
-->OWU_PARA
-->OWU_REPT
-->UAM_ARC
-->UAM_ART
-->UAM_EH
-->UAMOBS_EH
AKROHN
-->UCSC_BIRD
-->UCSC_FISH
-->UCSC_HERP
-->UCSC_MAMM
ALANBATTEN
-->UAM_ALG
-->UAM_HERB
-->UAMB_HERB
ALISONWHITING
-->BYU_HERP
AMCARRIL
-->DMNS_BIRD
-->DMNS_EGG
-->DMNS_HERP
-->DMNS_MAMM
-->DMNS_PARA
ANDRES_LOPEZ
-->UAM_FISH
-->UAM_HERP
-->UAM_INV
-->UAMOBS_FISH
ANDY
-->DGR_BIRD
-->MSB_BIRD
AREN
-->UAM_ART
-->UAM_BIRD
-->UAM_FISH
-->UAM_HERP
-->UAM_INV
-->UAM_MAMM
-->UAMOBS_MAMM
ATROX
-->MVZ_BIRD
-->MVZ_EGG
-->MVZ_HERP
-->MVZ_HILD
-->MVZ_MAMM
-->MVZOBS_BIRD
-->MVZOBS_FISH
-->MVZOBS_HERP
-->MVZOBS_MAMM
BBJOHNSON3
-->UAM_ARC
BFLUKER
-->ASUMZ_BIVALVE
-->ASUMZ_FISH
-->ASUMZ_INVERT
BJOHNSON_DMNS
-->DMNS_INV
BMCCALL
-->ASUMZ_BIVALVE
-->ASUMZ_FISH
-->ASUMZ_INVERT
CAMPMLC
-->APSU_BIRD
-->APSU_FISH
-->APSU_HERP
-->APSU_MAMM
-->ASUMZ_BIRD
-->ASUMZ_BIVALVE
-->ASUMZ_ENTO
-->ASUMZ_FISH
-->ASUMZ_HERP
-->ASUMZ_INVERT
-->ASUMZ_MAMM
-->BYU_HERP
-->DGR_BIRD
-->DGR_ENTO
-->DGR_MAMM
-->HWML_PARA
-->MSB_BIRD
-->MSB_FISH
-->MSB_HERP
-->MSB_HOST
-->MSB_MAMM
-->MSB_PARA
-->NMMNH_BIRD
-->NMMNH_ENTO
-->NMMNH_FISH
-->NMMNH_GEOL
-->NMMNH_HERB
-->NMMNH_HERP
-->NMMNH_INV
-->NMMNH_MAMM
-->NMMNH_PALEO
-->NMU_MAMM
-->NMU_PARA
-->OWU_AMPH
-->OWU_BIRD
-->OWU_EH
-->OWU_ES
-->OWU_ENTO
-->OWU_FISH
-->OWU_GEOL
-->OWU_HERB
-->OWU_INV
-->OWU_MAMM
-->OWU_PARA
-->OWU_REPT
-->STAR_ALG
-->STAR_HERB
-->UNM_ES
-->USNPC_PARA
CAMWEBB
-->UAM_ALG
-->UAM_HERB
-->UAMB_HERB
CARLSLIEB
-->UTEP_HERB
-->UTEP_HERP
-->UTEP_INV
CAROLYN
-->UAM_ALG
-->UAM_HERB
-->UAMB_HERB
CBABBITT
-->MSB_HOST
-->MSB_PARA
CCICERO
-->APSU_BIRD
-->APSU_FISH
-->APSU_HERP
-->APSU_MAMM
-->CHAS_BIRD
-->CHAS_EH
-->CHAS_ES
-->CHAS_EGG
-->CHAS_ENTO
-->CHAS_FISH
-->CHAS_HERB
-->CHAS_HERP
-->CHAS_INV
-->CHAS_MAMM
-->CHAS_TEACH
-->COA_BIRD
-->COA_EGG
-->COA_ENTO
-->COA_HERP
-->COA_MAMM
-->DGR_BIRD
-->DGR_ENTO
-->DGR_MAMM
-->DMNS_BIRD
-->DMNS_EGG
-->DMNS_HERP
-->DMNS_INV
-->DMNS_MAMM
-->DMNS_PARA
-->HWML_PARA
-->KNWR_ENTO
-->KNWR_HERB
-->KWP_ENTO
-->MLZ_BIRD
-->MLZ_EGG
-->MLZ_MAMM
-->MSB_BIRD
-->MSB_FISH
-->MSB_HERP
-->MSB_HOST
-->MSB_MAMM
-->MSB_PARA
-->MSBOBS_MAMM
-->MVZ_BIRD
-->MVZ_EGG
-->MVZ_FISH
-->MVZ_HERP
-->MVZ_HILD
-->MVZ_MAMM
-->MVZOBS_BIRD
-->MVZOBS_FISH
-->MVZOBS_HERP
-->MVZOBS_MAMM
-->NBSB_BIRD
-->NMU_BIRD
-->NMU_ENTO
-->NMU_FISH
-->NMU_HERB
-->NMU_MAMM
-->PSU_MAMM
-->UAM_ALG
-->UAM_ARC
-->UAM_ART
-->UAM_BIRD
-->UAM_EH
-->UAM_ES
-->UAM_ENTO
-->UAM_FISH
-->UAM_HERB
-->UAM_HERP
-->UAM_INV
-->UAM_MAMM
-->UAMOBS_BIRD
-->UAMOBS_EH
-->UAMOBS_ENTO
-->UAMOBS_FISH
-->UAMOBS_MAMM
-->UAMB_HERB
-->UCM_BIRD
-->UCM_EGG
-->UCM_FISH
-->UCM_HERP
-->UCM_MAMM
-->UCM_OBS
-->UCSC_BIRD
-->UCSC_FISH
-->UCSC_HERP
-->UCSC_MAMM
-->UMNH_BIRD
-->UMNH_ENTO
-->UMNH_HERP
-->UMNH_MALA
-->UMNH_MAMM
-->UMZM_BIRD
-->UMZM_MAMM
-->UNM_ES
-->UNR_BIRD
-->UNR_EGG
-->UNR_FISH
-->UNR_HERP
-->UNR_MAMM
-->USNPC_PARA
-->UTEP_ARC
-->UTEP_BIRD
-->UTEP_ES
-->UTEP_ENTO
-->UTEP_FISH
-->UTEP_HERB
-->UTEP_HERP
-->UTEP_HERPOS
-->UTEP_INV
-->UTEP_MAMM
-->UTEP_TEACH
-->UTEP_ZOO
-->UTEPOBS_ENTO
-->UTEPOBS_HERP
-->UWBM_HERP
-->UWBM_MAMM
-->UWYMV_BIRD
-->UWYMV_FISH
-->UWYMV_HERP
-->UWYMV_MAMM
-->WNMU_BIRD
-->WNMU_FISH
-->WNMU_MAMM
CMGIENGER
-->APSU_HERP
CTALLMAN5
-->UAM_EH
-->UAMOBS_EH
CWITT
-->DGR_BIRD
-->MSB_BIRD
DEMBOSKI
-->DMNS_BIRD
-->DMNS_EGG
-->DMNS_HERP
-->DMNS_INV
-->DMNS_MAMM
-->DMNS_PARA
DGSTEWART
-->UAM_ES
DHUNT
-->UAM_ALG
-->UAM_HERB
-->UAMB_HERB
DIAMSMCG
-->UCSC_BIRD
-->UCSC_HERP
-->UCSC_MAMM
DIANNAKREJSA
-->ASNHC_HERB
-->ASNHC_MAMM
DLM
-->ALMNH_ES
-->APSU_BIRD
-->APSU_FISH
-->APSU_HERP
-->APSU_MAMM
-->ASNHC_HERB
-->ASNHC_MAMM
-->CHAS_BIRD
-->CHAS_EH
-->CHAS_EGG
-->CHAS_ENTO
-->CHAS_FISH
-->CHAS_HERB
-->CHAS_HERP
-->CHAS_INV
-->CHAS_MAMM
-->CHAS_TEACH
-->COA_BIRD
-->COA_EGG
-->COA_ENTO
-->COA_HERP
-->COA_MAMM
-->DGR_BIRD
-->DGR_ENTO
-->DGR_MAMM
-->DMNS_BIRD
-->DMNS_EGG
-->DMNS_HERP
-->DMNS_INV
-->DMNS_MAMM
-->DMNS_PARA
-->HWML_PARA
-->KNWR_ENTO
-->KNWR_HERB
-->KWP_ENTO
-->MLZ_BIRD
-->MLZ_EGG
-->MLZ_MAMM
-->MSB_BIRD
-->MSB_FISH
-->MSB_HERP
-->MSB_HOST
-->MSB_MAMM
-->MSB_PARA
-->MSBOBS_MAMM
-->MVZ_BIRD
-->MVZ_EGG
-->MVZ_FISH
-->MVZ_HERP
-->MVZ_HILD
-->MVZ_MAMM
-->MVZOBS_BIRD
-->MVZOBS_FISH
-->MVZOBS_HERP
-->MVZOBS_MAMM
-->NBSB_BIRD
-->NMU_BIRD
-->NMU_ENTO
-->NMU_FISH
-->NMU_HERB
-->NMU_MAMM
-->PSU_MAMM
-->UAM_ALG
-->UAM_ARC
-->UAM_ART
-->UAM_BIRD
-->UAM_EH
-->UAM_ES
-->UAM_ENTO
-->UAM_ENV
-->UAM_FISH
-->UAM_HERB
-->UAM_HERP
-->UAM_INV
-->UAM_MAMM
-->UAMOBS_BIRD
-->UAMOBS_EH
-->UAMOBS_ENTO
-->UAMOBS_FISH
-->UAMOBS_MAMM
-->UAMB_HERB
-->UCM_BIRD
-->UCM_EGG
-->UCM_FISH
-->UCM_HERP
-->UCM_MAMM
-->UCM_OBS
-->UMNH_BIRD
-->UMNH_ENTO
-->UMNH_HERP
-->UMNH_MALA
-->UMNH_MAMM
-->UMZM_BIRD
-->UMZM_MAMM
-->UNM_ES
-->UNR_BIRD
-->UNR_EGG
-->UNR_FISH
-->UNR_HERP
-->UNR_MAMM
-->USNPC_PARA
-->UTEP_ARC
-->UTEP_BIRD
-->UTEP_ES
-->UTEP_ENTO
-->UTEP_FISH
-->UTEP_HERB
-->UTEP_HERP
-->UTEP_HERPOS
-->UTEP_INV
-->UTEP_MAMM
-->UTEP_TEACH
-->UTEP_ZOO
-->UTEPOBS_ENTO
-->UTEPOBS_HERP
-->UWBM_HERP
-->UWBM_MAMM
-->UWYMV_BIRD
-->UWYMV_FISH
-->UWYMV_HERP
-->UWYMV_MAMM
-->WNMU_BIRD
-->WNMU_FISH
-->WNMU_MAMM
DMCINTIRE2
-->UAM_ARC
DPERRIGUEY
-->UNM_ES
DROBERTS
-->CHAS_BIRD
-->CHAS_EH
-->CHAS_ES
-->CHAS_EGG
-->CHAS_ENTO
-->CHAS_FISH
-->CHAS_HERB
-->CHAS_HERP
-->CHAS_INV
-->CHAS_MAMM
-->CHAS_TEACH
EBRAKER
-->UCM_BIRD
-->UCM_EGG
-->UCM_FISH
-->UCM_HERP
-->UCM_MAMM
-->UCM_OBS
EJBROCK
-->MVZ_BIRD
-->MVZ_EGG
-->MVZ_HERP
-->MVZ_MAMM
-->MVZOBS_BIRD
ESDEARMON
-->MSB_FISH
EWOMMACK
-->UWYMV_BIRD
-->UWYMV_EGG
-->UWYMV_FISH
-->UWYMV_HERP
-->UWYMV_MAMM
FFDSS
-->KNWR_ENTO
-->KNWR_INV
-->KWP_ENTO
-->UAM_ENTO
-->UAMOBS_ENTO
FFMRG
-->UAM_ART
FMCARTER
-->UAM_ARC
-->UAM_EH
FSKBH1
-->KWP_ENTO
-->UAM_ALG
-->UAM_BIRD
-->UAM_ENTO
-->UAM_ENV
-->UAM_FISH
-->UAM_HERB
-->UAM_HERP
-->UAM_INV
-->UAM_MAMM
-->UAMOBS_MAMM
-->UAMB_HERB
FTKEG
-->NMU_BIRD
-->NMU_ENTO
-->NMU_FISH
-->NMU_HERB
-->NMU_HERP
-->NMU_MAMM
-->NMU_PARA
GARTHSPELLMAN
-->DMNS_BIRD
-->DMNS_EGG
-->DMNS_PARA
GJDELZER
-->UAM_ALG
-->UAM_HERB
-->UAMB_HERB
HKBERRIOS
-->UAM_ALG
-->UAM_HERB
-->UAMB_HERB
JACKKWATTS2397
-->UAM_ARC
JBWILLIAMSON
-->KWP_ENTO
-->UAM_ENTO
JEBRAD
-->UWBM_HERP
-->UWBM_MAMM
JEGELEWICZ
-->ALMNH_ES
-->ASNHC_HERB
-->ASNHC_MAMM
-->BYU_HERP
-->DGR_BIRD
-->DGR_ENTO
-->DGR_MAMM
-->MSB_BIRD
-->MSB_FISH
-->MSB_HERP
-->MSB_MAMM
-->MSB_PARA
-->NMMNH_BIRD
-->NMMNH_ENTO
-->NMMNH_FISH
-->NMMNH_GEOL
-->NMMNH_HERB
-->NMMNH_HERP
-->NMMNH_INV
-->NMMNH_MAMM
-->NMMNH_PALEO
-->OWU_AMPH
-->OWU_BIRD
-->OWU_EH
-->OWU_ES
-->OWU_ENTO
-->OWU_FISH
-->OWU_GEOL
-->OWU_HERB
-->OWU_INV
-->OWU_MAMM
-->OWU_PARA
-->OWU_REPT
-->UMNH_BIRD
-->UMNH_HERP
-->UMNH_MAMM
-->UMNH_TEACH
-->UMNHOBS_MAMM
-->UTEP_ARC
-->UTEP_BIRD
-->UTEP_ES
-->UTEP_ENTO
-->UTEP_FISH
-->UTEP_HERB
-->UTEP_HERP
-->UTEP_HERPOS
-->UTEP_INV
-->UTEP_MAMM
-->UTEP_TEACH
-->UTEP_ZOO
-->UTEPOBS_ENTO
-->UTEPOBS_HERP
JJWITHROW
-->UAM_BIRD
-->UAMOBS_BIRD
JLDUNNUM
-->DGR_BIRD
-->DGR_ENTO
-->DGR_MAMM
-->MSB_BIRD
-->MSB_FISH
-->MSB_HERP
-->MSB_HOST
-->MSB_MAMM
-->MSB_PARA
-->MSBOBS_MAMM
JMALEY1
-->MLZ_BIRD
-->MLZ_EGG
-->MLZ_HERB
-->MLZ_MAMM
JOEY76909
-->ASNHC_HERB
-->ASNHC_MAMM
JOHANSENR
-->APSU_FISH
JTGIERMAK
-->MSB_HERP
JTSTEPHENSON
-->DMNS_BIRD
-->DMNS_EGG
-->DMNS_HERP
-->DMNS_INV
-->DMNS_MAMM
-->DMNS_PARA
KATHERINELANDERSON
-->UAM_ES
KMDALY
-->KNWR_ENTO
-->KWP_ENTO
-->UAM_ENTO
-->UAMOBS_ENTO
KRGOMEZ
-->UAM_ART
-->UAM_EH
-->UAMOBS_EH
LAM
-->COA_BIRD
-->COA_EGG
-->COA_ENTO
-->COA_HERP
-->COA_MAMM
-->DGR_BIRD
-->DGR_ENTO
-->DGR_MAMM
-->KWP_ENTO
-->MLZ_BIRD
-->MLZ_EGG
-->MLZ_MAMM
-->MSB_BIRD
-->MSB_FISH
-->MSB_HERP
-->MSB_HOST
-->MSB_MAMM
-->MSB_PARA
-->MSBOBS_MAMM
-->MVZ_BIRD
-->MVZ_EGG
-->MVZ_HERP
-->MVZ_HILD
-->MVZ_MAMM
-->MVZOBS_BIRD
-->MVZOBS_HERP
-->MVZOBS_MAMM
-->NBSB_BIRD
-->PSU_MAMM
-->UAM_ART
-->UAM_BIRD
-->UAM_ES
-->UAM_ENTO
-->UAM_FISH
-->UAM_HERB
-->UAM_INV
-->UAM_MAMM
-->UAMOBS_MAMM
-->UAMB_HERB
-->UMNH_BIRD
-->UMNH_ENTO
-->UMNH_HERP
-->UMNH_MALA
-->UMNH_MAMM
-->UWBM_HERP
-->WNMU_BIRD
-->WNMU_FISH
-->WNMU_MAMM
LAWALKER5
-->UAM_EH
-->UAMOBS_EH
LINDSEYFREDERICK
-->NMMNH_BIRD
-->NMMNH_ENTO
-->NMMNH_FISH
-->NMMNH_GEOL
-->NMMNH_HERB
-->NMMNH_HERP
-->NMMNH_INV
-->NMMNH_MAMM
-->NMMNH_PALEO
LMTABAK
-->OWU_AMPH
-->OWU_BIRD
-->OWU_EH
-->OWU_ES
-->OWU_ENTO
-->OWU_FISH
-->OWU_GEOL
-->OWU_HERB
-->OWU_INV
-->OWU_MAMM
-->OWU_PARA
-->OWU_REPT
LOLSON
-->UAM_MAMM
-->UAMOBS_MAMM
MARSZULO
-->NMU_BIRD
-->NMU_ENTO
-->NMU_HERP
-->NMU_MAMM
-->NMU_PARA
MBOWSER
-->KNWR_ENTO
-->KNWR_HERB
-->KNWR_INV
-->KNWROBS_FISH
-->KNWROBS_HERB
-->KNWROBS_MAMM
-->KWP_ENTO
-->UAM_ENTO
-->UAMOBS_ENTO
MBPRONDZINSKI
-->ALMNH_ES
MJANDERSEN
-->DGR_BIRD
-->DGR_MAMM
-->MSB_BIRD
-->MSB_FISH
-->MSB_HERP
-->MSB_MAMM
-->MSB_PARA
MKOO
-->MVZ_BIRD
-->MVZ_EGG
-->MVZ_FISH
-->MVZ_HERP
-->MVZ_HILD
-->MVZ_MAMM
-->MVZOBS_BIRD
-->MVZOBS_FISH
-->MVZOBS_HERP
-->MVZOBS_MAMM
NICOLERIDGWELL
-->NMMNH_BIRD
-->NMMNH_ENTO
-->NMMNH_FISH
-->NMMNH_GEOL
-->NMMNH_HERB
-->NMMNH_HERP
-->NMMNH_INV
-->NMMNH_MAMM
-->NMMNH_PALEO
NROSE
-->MVZ_BIRD
-->MVZ_EGG
-->MVZ_HERP
-->MVZ_MAMM
OPHIS
-->UNR_BIRD
-->UNR_EGG
-->UNR_FISH
-->UNR_HERP
-->UNR_MAMM
PATTON
-->MVZ_BIRD
-->MVZ_EGG
-->MVZ_HERP
-->MVZ_HILD
-->MVZ_MAMM
-->MVZOBS_BIRD
-->MVZOBS_HERP
-->MVZOBS_MAMM
PETERSMILLER
-->UWBM_HERP
RACZG
-->HWML_PARA
RICKART
-->UMNH_BIRD
-->UMNH_HERP
-->UMNH_MAMM
RJ3NN1NGS
-->WNMU_BIRD
-->WNMU_FISH
-->WNMU_MAMM
RKNOWICKI
-->KWP_ENTO
-->UAM_ENTO
ROBSON
-->UMNH_BIRD
-->UMNH_HERP
-->UMNH_MAMM
-->UMNH_TEACH
-->UMNHOBS_MAMM
SARA
-->MSB_BIRD
-->MSB_HOST
-->MSB_PARA
SBIRKS
-->UWBM_HERP
-->UWBM_MAMM
SCCOFFMAN
-->UAM_ARC
SHARPPHYL
-->DMNS_INV
SHIRAR
-->UAM_ARC
-->UAM_EH
SLIPHARDT
-->DGR_MAMM
-->MSB_MAMM
SOTEROPOULOSD2
-->ASUMZ_BIRD
-->ASUMZ_BIVALVE
-->ASUMZ_ENTO
-->ASUMZ_FISH
-->ASUMZ_HERP
-->ASUMZ_INVERT
-->ASUMZ_MAMM
-->STAR_ALG
-->STAR_HERB
STEFFI
-->UAM_ALG
-->UAM_HERB
-->UAMB_HERB
SYSTEM
TRUCKEY
-->DMNS_BIRD
-->DMNS_EGG
-->DMNS_HERP
-->DMNS_INV
-->DMNS_MAMM
-->DMNS_PARA
UAM
-->ALMNH_ES
-->APSU_BIRD
-->APSU_FISH
-->APSU_HERP
-->APSU_MAMM
-->ASNHC_HERB
-->ASNHC_MAMM
-->ASUMZ_BIRD
-->ASUMZ_BIVALVE
-->ASUMZ_ENTO
-->ASUMZ_FISH
-->ASUMZ_HERP
-->ASUMZ_INVERT
-->ASUMZ_MAMM
-->BYU_HERP
-->CHAS_BIRD
-->CHAS_EH
-->CHAS_ES
-->CHAS_EGG
-->CHAS_ENTO
-->CHAS_FISH
-->CHAS_HERB
-->CHAS_HERP
-->CHAS_INV
-->CHAS_MAMM
-->CHAS_TEACH
-->COA_BIRD
-->COA_EGG
-->COA_ENTO
-->COA_HERP
-->COA_MAMM
-->COA_REPT
-->DGR_BIRD
-->DGR_ENTO
-->DGR_MAMM
-->DMNS_BIRD
-->DMNS_EGG
-->DMNS_HERP
-->DMNS_INV
-->DMNS_MAMM
-->DMNS_PARA
-->HWML_PARA
-->KNWR_ENTO
-->KNWR_HERB
-->KNWR_INV
-->KNWROBS_FISH
-->KNWROBS_HERB
-->KNWROBS_MAMM
-->KWP_ENTO
-->MLZ_BIRD
-->MLZ_EGG
-->MLZ_HERB
-->MLZ_MAMM
-->MSB_BIRD
-->MSB_FISH
-->MSB_HERP
-->MSB_HOST
-->MSB_MAMM
-->MSB_PARA
-->MSBOBS_MAMM
-->MVZ_BIRD
-->MVZ_EGG
-->MVZ_FISH
-->MVZ_HERP
-->MVZ_HILD
-->MVZ_MAMM
-->MVZOBS_BIRD
-->MVZOBS_FISH
-->MVZOBS_HERP
-->MVZOBS_MAMM
-->NBSB_BIRD
-->NMMNH_BIRD
-->NMMNH_ENTO
-->NMMNH_FISH
-->NMMNH_GEOL
-->NMMNH_HERB
-->NMMNH_HERP
-->NMMNH_INV
-->NMMNH_MAMM
-->NMMNH_PALEO
-->NMU_BIRD
-->NMU_ENTO
-->NMU_FISH
-->NMU_HERB
-->NMU_HERP
-->NMU_MAMM
-->NMU_PARA
-->OWU_AMPH
-->OWU_BIRD
-->OWU_EH
-->OWU_ES
-->OWU_ENTO
-->OWU_FISH
-->OWU_GEOL
-->OWU_HERB
-->OWU_INV
-->OWU_MAMM
-->OWU_PARA
-->OWU_REPT
-->PSU_MAMM
-->STAR_ALG
-->STAR_HERB
-->UAM_ALG
-->UAM_ARC
-->UAM_ART
-->UAM_BIRD
-->UAM_EH
-->UAM_ES
-->UAM_ENTO
-->UAM_ENV
-->UAM_FISH
-->UAM_HERB
-->UAM_HERP
-->UAM_INV
-->UAM_MAMM
-->UAMOBS_BIRD
-->UAMOBS_EH
-->UAMOBS_ENTO
-->UAMOBS_FISH
-->UAMOBS_MAMM
-->UAMB_HERB
-->UCM_BIRD
-->UCM_EGG
-->UCM_FISH
-->UCM_HERP
-->UCM_MAMM
-->UCM_OBS
-->UCSC_BIRD
-->UCSC_FISH
-->UCSC_HERP
-->UCSC_MAMM
-->UMNH_BIRD
-->UMNH_ENTO
-->UMNH_HERP
-->UMNH_MALA
-->UMNH_MAMM
-->UMNH_TEACH
-->UMNHOBS_MAMM
-->UMZM_BIRD
-->UMZM_MAMM
-->UNM_ES
-->UNR_BIRD
-->UNR_EGG
-->UNR_FISH
-->UNR_HERP
-->UNR_MAMM
-->USNPC_PARA
-->UTEP_ARC
-->UTEP_BIRD
-->UTEP_ES
-->UTEP_ENTO
-->UTEP_FISH
-->UTEP_HERB
-->UTEP_HERP
-->UTEP_HERPOS
-->UTEP_INV
-->UTEP_MAMM
-->UTEP_TEACH
-->UTEP_ZOO
-->UTEPOBS_ENTO
-->UTEPOBS_HERP
-->UWBM_HERP
-->UWBM_MAMM
-->UWYMV_BIRD
-->UWYMV_EGG
-->UWYMV_FISH
-->UWYMV_HERP
-->UWYMV_MAMM
-->WNMU_BIRD
-->WNMU_FISH
-->WNMU_MAMM
VOLEGUY
-->MVZ_BIRD
-->MVZ_EGG
-->MVZ_HERP
-->MVZ_HILD
-->MVZ_MAMM
-->MVZOBS_BIRD
-->MVZOBS_HERP
-->MVZOBS_MAMM
VTHILL
-->UNR_BIRD
-->UNR_EGG
-->UNR_FISH
-->UNR_HERP
-->UNR_MAMM

PL/SQL procedure successfully completed.

Elapsed: 00:00:01.25
\

Jegelewicz commented 5 years ago

Not sure I need that access?

Also EKRIMMEL (LOCKED) no longer works for an Artos-using institution and probably should not have it (even thought I think she's great and wish she would come back....).

dustymc commented 5 years ago

The locked accounts are fine - it's useful to know what someone could have done, and they can't do anything now.

I think you can revoke from you if you want....

Jegelewicz commented 5 years ago

That makes sense, but someone could unlock her account without asking the right questions and then it's a problem? I don't think it is with Erika, but just thinking big picture. I cannot revoke for her - because her account is locked? or because I don't have privileges in whatever collections she does? Just want to make sure I know what actual abilities I have!

dustymc commented 5 years ago

someone could unlock her account without asking the right questions

Yes - now anyone with manage_collection. Anyone who isn't willing to ask the right questions should not have that level of access.

There's some documentation at http://handbook.arctosdb.org/documentation/users.html, but it should be beefed up. If I wanted to "hack" Arctos I'd probably start by just asking someone to give me access....

Accounts do get re-used fairly often - quite a few of the current curators/CMs started in Arctos as students.

Jegelewicz commented 1 year ago

I think the written documentation is fairly solid. I also added the User documentation as reading for new collections as part of the Create an Arctos Team step in data migration. The video tutorial label is still here - although I am a bit unclear what that would entail.

ArctosDB / documentation-wiki

DISCUSS: User Management #123

I'm re-opening this issue (and bringing back Priority-Critical) based on email conversation with Dusty 9 Apr 2019 in response to a new collection trying to grant permissions.

And http://handbook.arctosdb.org/documentation/users.html is correct-ish, but it's still static rather than pulling from the table that controls Arctos.