spike: reproduce - Permissions: Grant access errors for large # of files

[sbarbosadataverse]

Permissions: Grant access errors for large # of files

There was a data request sitting in permissions for Murray dataverse. I selected "accept" and it gave access to 308 file, which is the correct number of "Restricted" files, but the request came in for 315 files (7 files are not restricted). I clicked "Accept" again, and 168 files remained. I clicked "Accept" again and 8 files remained in the que. I clicked "Accept" again and nothing happened after the blue spinning, 8 files still remained in the que (the 8 not restricted for access)

I left the page, went back into permissions-files to add the user manually. I expected when I added her username, to only see "8" files show up in the list of files to give access to. Instead, all 315 files show up. Basically the system doesn't recognize a username already assigned to "files?" The files are also not in any type of order in this files permissions page.

When I added her to all 315 files again, I received 315 error messages as shown in the images below.

Removing her access seems to work in the same manner. It removed access in "chunks" and the updated page reflects smaller and smaller number of files as you keep choosing to "remove" access

[sbarbosadataverse]

@mheppler
Got it! thanks

[mheppler]

This popup has another minor, related bug #2572 that would improve the UI.

[mheppler]

I have tested this behavior on both localhost and dvn-build (both running the latest "develop" branch based off 4.2.3), but was not able to reproduce all the aspects of this bug report. (YES/NO is if I was able to replicate it or not.)

• [NO] Request access file count on the File Permissions manage page reflected the number of all files requested, which included files that were not restricted
• [YES] File Access popup list the files in random order (reported in originally in issue Multi Select Request Access: Grant list box has unordered file list, unlike file view on dataset page. #2572)
• [NO] File Access popup shows all files selected, but grants access in "chunks", you have to keep clicking "Grant" to apply it to all files, even though the list shows all files selected
• [YES] Removing file access works the same, in "chunks", you have to keep clicking "Remove" to apply it to all files, even though the list shows all files selected
• [YES] Grant Access popup doesn't display a user's access status to restricted files in the list after they have been selected in the User/Group autoComplete input (opened in new issue File Permissions - Grant Access popup needs existing user access status #2958)

If all these bugs cannot be replicated, that leaves the "removing access in chunks" bug to be fixed.

[sekmiller]

On remove permissions getting null pointer on removeRoleAssignments method revokeRole (line 245) is being called with a null role assignment row.

This happens in the same way whether you select "Remove Access" or click on the files link, select all and press "Remove Access" in the pop-up

[sekmiller]

https://java.net/jira/browse/GLASSFISH-19470

This is an issue tracking the error message we are seeing. There doesn't appear to be any activity on it. I left a note to say that we are seeing it in Glassfish 4.1.

[djbrooke]

Removing from 4.5. Note the external dependency with our friends at Glassfish, where the issue has existed for 4 years. When this issue is reprioritized, we may need to consider a different approach that removes the dependency.

[jggautier]

Stumbled on this issue while looking for GitHub issues about assigning roles (while troubleshooting a possible bug or UX problem related to assigning roles).

Does this issue, which seems to have been whittled down to an error caused by revoking file-level permissions on a large number of files, still exist now that Dataverse software is no longer using Glassfish? Or maybe I'm misunderstanding the software's current relationship status with Glassfish?

[pdurbin]

@jggautier I'd say it's unknown if this is still an issue on Payara (the derivative of Glassfish we use) or not. This issue was opened in the Glassfish 4.1 days and we're now on Payara 5.x.

[mreekie]

@jggautier I'd say it's unknown if this is still an issue on Payara (the derivative of Glassfish we use) or not. This issue was opened in the Glassfish 4.1 days and we're now on Payara 5.x.

Next Steps:

• Next sizing meeting
• let's decide to verify the behavior with a spike or close this.
• needs: @jggautier @kcondon @pdurbin

[kcondon]

Spoke to Sonia, she hasn't seen it recently but has no reason to believe it was fixed.
I tried it on the original dataset. It no longer allows request access so I just assigned manually.
I did not see the problem -I was able to assign access to all files fairly quickly ~5s and remove access a bit slower ~20s.
I also tried in my test environment and saw the same behavior as in prod.

Sonia said we could close this and she would open a new issue if she saw it again.

I also saw some UX issues that could cause confusion or issues, especially if the system was not responding well, causing a user to maybe click around more:

1. As more users are assigned access, the performance of assigning and removing access slows down. I believe in the past this has cause Sonia to use group assignments rather than individuals and advise user do the same.
2. Clicking remove access more than once on the same user that is slow to remove causes multiple different users to be removed. I did this accidentally during testing -I intentionally clicked it multiple times as I was waiting but didn't realize it deleted a real user's access until I saw the success banner with user's name.
3. If I grant all file access to a user who already has access to some files, there is both a success and a failure banner whose contents is a bit confusing, contains only one file from the success (new files) list and one file from the failure (existing) list.
4. Grant all files access to a user who already has all files access and see a large number of stack traces in server log as well as an unhelpful error similar to the one above -could not grant access to file xyz. Seems like it could be caught better on the logging side and reported better in UI, one or more files have previously been granted access, please check access list.

[cmbz]

2023/09/18
@kcondon attempted to reproduce the error and could not, but identified the following additional problems that might explain @sbarbosadataverse 's observations.

1. As more users are assigned access, the performance of assigning and removing access slows down. I believe in the past this has cause Sonia to use group assignments rather than individuals and advise user do the same.
2. Clicking remove access more than once on the same user that is slow to remove causes multiple different users to be removed. I did this accidentally during testing -I intentionally clicked it multiple times as I was waiting but didn't realize it deleted a real user's access until I saw the success banner with user's name.
3. If I grant all file access to a user who already has access to some files, there is both a success and a failure banner whose contents is a bit confusing, contains only one file from the success (new files) list and one file from the failure (existing) list.
4. Grant all files access to a user who already has all files access and see a large number of stack traces in server log as well as an unhelpful error similar to the one above -could not grant access to file xyz. Seems like it could be caught better on the logging side and reported better in UI, one or more files have previously been granted access, please check access list.

As a result, we will close this issue. @sbarbosadataverse please create an issue if you see any of the 4 problems again.