Hi Sev,

Threads automatically shift from close to open when someone responds to it and it appears in our support monitoring dashboard. We set it to closed when we are expecting a response from someone, not just when the issue is resolved/closed. I had assumed that Ben's responses to you was sufficient here, which is why I set it to closed, expecting you to respond to Ben's comment.

Regarding your question with the database table that would record the permission, this would be seen under the core.roleassignments table, where it would show the resourceid, userid (which could be the individual's userid or the groupId of a project or site level group), and the specific role.
 
As both Ben and I said, those dataset permissions should never have reset on an upgrade since they should be saved on the database. For those permissions to be changed, there would have to be some kind of SQL script running to alter the database. If you're restoring a full backup that indeed had the permissions set on the dataset, then it should not have been affected by the software upgrade.

So this would mean there is something external that is causing the database to be written to after the upgrade. The only way I know of permissions to be overwritten like this that isn't done directly in the Manage Security section of the Study would be via a study reload where the XML within the study archive would overwrite the information there.

Is it possible that you have some kind of pipeline job setup where it's running old study reloads that doesn't have the permissions set? Did you have a chance to look and see if the labkey.log recorded any activity after the upgrade completed? Study reloads would list themselves there and also within the pipeline section of that specific container under Admin > Go To Module > Pipeline.

Regards,

Jon