More tools for org admins to manage user records

[dsisu]

Please complete the following fields as applicable:

What version of the DMPRoadmap code are you running? (e.g. v2.2.0) 3.0.2

Expected behaviour: More tools for org admins to examine user records and remove old accounts from the system. Institutions require accurate statistics on number of (active) users they have.

Actual behaviour: Currently the users have full control over their accounts and it is up to the user to update their details.

Steps to reproduce: n/a

[dsisu]

This issue arose out of the 2020 Usability Testing exercise

[briri]

We don't allow user accounts to be deleted because it would orphan records in the database. We instead allow them to be archived by a super admin which anonymizes their information (by user request).

Would it be enough to mark them as inactive and then update our statistics gathering to ignore inactive users?

If we add a script to deactivate very old and unused accounts would that help with the need for this?

[dsisu]

Hi @briri, I guess we have to put your solutions to the Org Admin users.

Institutions want very accurate usage data - number of plans, active users, etc.

Deactivating very old user accounts could be a solution. The way DMPonline & DMPTool work relies on the user updating their own account and we should think of ways of prompting users to review their account as well.

I don't know how we produce the statistics on number of plans. For example, if a user changes institution, does their previous institution still see or get statistics on plans the user created while with them? My understanding is that it's not the case.

[briri]

Hi @dsisu,

The statistics should be generated monthly so if I was associated with Univ. of Edinburgh in January and created a plan and then moved over to Univ. of Glasgow in April, my plans created in January should still be a part of the Univ. of Edinburgh's stats for that month.

There are a few scenarios in the past where a major change (e.g. allowing the admin to differentiate between test/non-test plans) was made to the way statistics were gathered and the numbers were regenerated completely. So in that scenario the plans I created for Univ. of Edinburgh would not have been recorded properly.

We used to determine the Org-Plan connection via the plan owner's Org. We have recently begun connecting a Plan directly to the research Org the user specifies when creating the plan, so it may be time to revisit the statistics collection processes to see if there's a better approach

[dsisu]

Hi @briri, thanks for clarifying this.

It sounds as if usage statistics for plans works well then.

As an aside, we should add this type of background information to be displayed on the usage statistics page, for the benefit of to Org Admins. A brief line that reassures Org Admins that the no of plans chart includes plans from users who have now left the university.