Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check all 6 collections when select set as admin for 6 #4652

Open
wants to merge 12 commits into
base: production
Choose a base branch
from

Conversation

CarolineDenis
Copy link
Contributor

@CarolineDenis CarolineDenis commented Mar 14, 2024

Fixes #2695

Checklist

  • Self-review the PR after opening it to make sure the changes look good
    and self-explanatory (or properly documented)
  • Add relevant issue to release milestone

Testing instructions

  • go in security and accounts
  • click on make admin button under specify 6 permissions
  • open set collections under specify 6 permissions
    ==> verify that all collections are checked
    ==> verify that you can unchecked some collections and save

@CarolineDenis CarolineDenis added this to the 7.9.6 milestone Mar 14, 2024
Triggered by 268443a on branch refs/heads/issue-2695b
@CarolineDenis
Copy link
Contributor Author

@acwhite211,

There is an issue with the api,
/api/set_admin_status/${user.id}/ seems to not be correctly setting the Sp5 admin status. Can you check this?
To reproduce:
go in security and accounts
click on make admin button under specify 6 permissions
see that the button is now remove admin
open set collections under specify 6 permissions
see that all collections are checked
refresh page
see that the button is back to make admin

@acwhite211
Copy link
Member

acwhite211 commented Apr 19, 2024

It seems the set_admin_status api adds the SpPincipalID of an Administator (which is 1), with the SpecifyUserID, to specifyuser_spprincipal. This api seems to be working properly, and can be confirmed by the is_admin function.

-- example for setting the new user, with ID 17, to admin

-- set_admin
INSERT INTO specifyuser_spprincipal (SpPrincipalId, SpecifyUserId)
SELECT spprincipalid, 17
FROM   spprincipal
WHERE  name = 'Administrator';

-- is_admin - return 1 if true, no results if false
SELECT 1
FROM   specifyuser_spprincipal,
       spprincipal
WHERE  17 = specifyuser_spprincipal.specifyuserid
       AND specifyuser_spprincipal.spprincipalid = spprincipal.spprincipalid
       AND spprincipal.name = 'Administrator'
LIMIT  1;

-- list_admins
SELECT specifyuserid, specifyuser.name
FROM   specifyuser_spprincipal
       JOIN spprincipal USING (spprincipalid)
       JOIN specifyuser USING (specifyuserid)
WHERE  spprincipal.name = 'Administrator';

-- get users_collections_for_sp6
SELECT DISTINCT c.usergroupscopeid, c.collectionname
FROM   collection c
       INNER JOIN spprincipal p
               ON p.usergroupscopeid = c.usergroupscopeid
       INNER JOIN specifyuser_spprincipal up
               ON up.spprincipalid = p.spprincipalid
       INNER JOIN specifyuser u
               ON u.specifyuserid = up.specifyuserid
                  AND p.grouptype IS NULL
WHERE  up.specifyuserid = 17;  

The other step after setting the user to Admin is to add the collections the user has access to via PUT api call to /context/user_collection_access_for_sp6/{user_id}/

It seems that the problem in that call the user_collection_access_for_sp6 PUT api removes the user admin entry in the specifyuser_spprincipal table. Here is the line of code where this is done:

# First delete the mappings from the user to the principals.
cursor.execute("delete specifyuser_spprincipal "
"from specifyuser_spprincipal "
"join spprincipal using (spprincipalid) "
"where specifyuserid = %s and usergroupscopeid not in %s",
[user.id, collectionids])

Here are the sql statements that are made by the set_users_collections_for_sp6 function:

-- First delete the mappings from the user to the principals.
DELETE specifyuser_spprincipal
FROM   specifyuser_spprincipal
       JOIN spprincipal using (spprincipalid)
WHERE  specifyuserid = 17
       AND usergroupscopeid NOT IN ( 65536, 32768, 4 );

-- Next delete the joins from the principals to any permissions.
DELETE FROM spprincipal_sppermission
WHERE  spprincipalid NOT IN (SELECT spprincipalid
                             FROM   specifyuser_spprincipal);

-- Finally delete all the principals that aren't connected to
-- any user. This should just be the ones where the mappings
-- were deleted above.
DELETE FROM spprincipal
WHERE  grouptype IS NULL
       AND spprincipalid NOT IN (SELECT spprincipalid
                                 FROM   specifyuser_spprincipal);

-- Now to add any new principals. Which ones alerady exist?
SELECT usergroupscopeid
FROM   spprincipal
       JOIN specifyuser_spprincipal using (spprincipalid)
WHERE  grouptype IS NULL
       AND specifyuserid = 17;

-- Add a principal for collection ids that don't already exist
UPDATE spprincipal set usergroupscopeid = %s WHERE spprincipalid = %s;
INSERT specifyuser_spprincipal(SpecifyUserID, SpPrincipalID) VALUES (17, %s);

I think this might of just been an oversight, so I'm adding an extra condition to that query statement to exclude Admin principals. We might want to design a more comprehensive solution, but this at least avoids removing the admin status.

DELETE specifyuser_spprincipal
FROM   specifyuser_spprincipal
       JOIN spprincipal using (spprincipalid)
WHERE  specifyuserid = 17
       AND usergroupscopeid NOT IN ( 65536, 32768, 4 )
       AND spprincipal.Name != 'Administrator'; -- added this condition

There still seems to be an issue of the 'User Group' picklist being set to the old value, rather than 'Manager'. Looking at the SpecifyUser table, the value is set to 'Manger', but it shows up as LimitedAccess on the front-end. Not sure why this is, the user.userType comes from the resource api. Checking the /context/user.json/ file served to the front-end, the usertype: "Manager" variable is correct.

I added defaultValue={userResource.get('userType') || undefined} in the LegacyPermissions combobox to userType. This fixed the front-end issue with the userType combobox.

@CarolineDenis CarolineDenis marked this pull request as ready for review April 22, 2024 13:49
@acwhite211 acwhite211 self-requested a review April 23, 2024 14:10
@CarolineDenis CarolineDenis requested a review from a team May 13, 2024 14:42
Copy link
Collaborator

@emenslin emenslin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Testing instructions

  • go in security and accounts
  • click on make admin button under specify 6 permissions
  • open set collections under specify 6 permissions
    ==> verify that all collections are checked
    ==> verify that you can unchecked some collections and save

Looks good, all collections are checked.

hgMPNySDQM.mp4

@emenslin emenslin requested a review from a team May 13, 2024 20:33
Copy link
Contributor

@pashiav pashiav left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Testing instructions

  • go in security and accounts
  • click on make admin button under specify 6 permissions
  • open set collections under specify 6 permissions
    ==> verify that all collections are checked
    ==> verify that you can unchecked some collections and save

All collections are checked when made into an admin and you can edit the selected collections and save. Looks good!
Screen Shot 2024-05-13 at 4 05 28 PM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📋Back Log
Development

Successfully merging this pull request may close these issues.

Setting a user as admin does not set their 6 collections
5 participants