Permissions: Removing a role assigned at Root, such as curator, is not immediately reflected in browse results due to slow indexing.

[kcondon]

Sonia attempted to remove a curator role assignment from root, it did not remove it and service became unresponsive shortly afterwards. Not sure it was related to service issue. There is another ticket about permission performance but this is a very specific use case that should be considered for changing how the transaction is managed, eg. remove role first in one transaction, do reindex in another transaction.

[pdurbin]

Right, at #2036 (comment) we re-confirmed that it only takes a few milliseconds to remove the role assignment from the database. The expensive part is the reindexing.

[kcondon]

Retest with production db

[pdurbin]

My earlier comment at #2697 (comment) is no longer accurate in the sense that the user removing the role no longer experiences the expense of reindexing (watching the spinner spin) since it was made asynchronous in #2036.

[kcondon]

So does that mean this is no longer an issue then?

---

From: Philip Durbin notifications@github.com
Sent: Wednesday, April 13, 2016 8:31 PM
To: IQSS/dataverse
Cc: Condon, Kevin M
Subject: Re: [IQSS/dataverse] Permissions: Removing a role assigned at Root, such as curator, is not immediately reflected in browse results due to slow indexing. (#2697)

My earlier comment at #2697 (comment)https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IQSS_dataverse_issues_2697-23issuecomment-2D151539046&d=CwMCaQ&c=WO-RGvefibhHBZq3fL85hQ&r=TUpjWt9sVfaAC8ETCY_cDPtqJKl7s242PLg6-Wx6UpM&m=zI8NyAHRbsz8L_T9um83IcRDacHhbXT--10w0Gw5Af8&s=GIZqaV8HLwFkAApEyoSRAjhyZKWzDVwQxEKlEdXdxQ0&e= is no longer accurate in the sense that the user removing the role no longer experiences the expense of reindexing (watching the spinner spin) since it was made asynchronous in #2036https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IQSS_dataverse_issues_2036&d=CwMCaQ&c=WO-RGvefibhHBZq3fL85hQ&r=TUpjWt9sVfaAC8ETCY_cDPtqJKl7s242PLg6-Wx6UpM&m=zI8NyAHRbsz8L_T9um83IcRDacHhbXT--10w0Gw5Af8&s=q4lyI8o8x3Vny1lHicO5BQC-QOtmt112lEPskOI0V84&e=.

You are receiving this because you were assigned.
Reply to this email directly or view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IQSS_dataverse_issues_2697-23issuecomment-2D209700813&d=CwMCaQ&c=WO-RGvefibhHBZq3fL85hQ&r=TUpjWt9sVfaAC8ETCY_cDPtqJKl7s242PLg6-Wx6UpM&m=zI8NyAHRbsz8L_T9um83IcRDacHhbXT--10w0Gw5Af8&s=sZqbdv5TubDERuDPwJ18b_wd87CWtfwwtMFK0CNkP40&e=

[pdurbin]

I depends on how you interpret what this issue is about, I guess. Indexing is not immediate, it's just asynchronous now. If desired, we could turn this issue into the new #50 about indexing being too slow. But that issue was recently closed as fast enough.

[kcondon]

Spoke with Phil. Before asynch indexing, Sonia would just see a spinner after removing and would seem to never return. Now returns but user would continue to see cards they no longer have access to until index is complete. This last asynch mode is how we interpreted the issue.

As for this being indexing being too slow and how it related to #50, that was about the sys admin use case of doing an overnight index all not completing in a reasonable time. That is good enough, happens in a few hours but not the same use case as this: curation of permissions.

It's clear there is not a likely short term solution to slower index times or even an ultimate solution so we need to decide if this is ok to live with.

[kcondon]

Asynch change made this much better but given the current perms/ index architecture the amount of improvement would not significantly change this so we should live with it for now and revisit if it becomes a problem for users. Closing.