Funder template status changed

[sjDCC]

I see we flag when the funder template has changed. What does this denote (changes since customisation, or changes per se?) and have we built any functionality around this e.g. saying what has changes, alerts to prompt those who have customised changes templates...

For Strathclyde uni, I get many more entries where the funder template has changed

[vyruss]

@sjDCC this may have been fixed in #365 (v0.2.6)

[xsrust]

This is actually likely still an issue after that PR.
'Original funder template has changed' denotes that the underlying template which has been customised by the uni has changed. This means that the org-admin must click 'edit customization' in order to bring their customizations through into the new template. Once they click this, upon refreshing the templates index page, they will simply see 'published' and be allowed to edit the draft of their template (which they can also publish).

As far as I am aware, no additional notification functionality has been built in around this.

[sjDCC]

This strikes me as something that would benefit from UX input @JEK-III in future to improve workflow and notifications

For now if we flag that a newer version of the template is in use and that their customisation is inactive that should be sufficient. We should make it clearer that they need to 'edit customisation' to transfer this through to the new template though (I assumed it still showed), and ideally it would be unpublished first until they've checked and made any changes needed.

How about changing the action line to 'Transfer customisation' instead of 'Edit customisation' and make it unpublished at first? That should prompt them to check their content is still valid and make any changes needed.

Is it feasible to implement those steps? Happy to help mock something basic up with you

[JEK-III]

Bouncing the UX question to @rhu001, who is handling the admin interface.

[sjDCC]

Also note there's a related ticket #232

[rhu001]

@sjDCC are the template changes occurring because the local admins are changing them or because they are changing from the funder and the local admin doesn't realize they have changed until they see the status on the table? Would like to understand the use case before advising on UX changes. Also, is there a case where there are more than one local admin or a super admin who might change the template that the other local admin has to account for and re-adjust for their institution?

[sjDCC]

Hi @rhu001, essentially it's the second case you describe.

This notification text that "Original funder template has changed!" appears in the table when an institution has customised the funder template and the funder has subsequently released a new version. Essentially it's an alert that something has changed so they need to check their customisation is still valid. The local org admins don't have permissions to change the funder template, only their customisations on it. It seems the customisation only transfers through to the new funder template version when the org-admin clicks to 'edit customisation' and saves changes.

I don't fully understand your second question: "Also, is there a case where there are more than one local admin or a super admin who might change the template that the other local admin has to account for and re-adjust for their institution?"

There may be more than one org-admin at an institution but we don't set any alerts when one of them has changed their template. Funders (or more like Steph and me) administer the funder templates. Organisations can customise these, but this is effectively overlaid institutional content (example answers, guidance and additional sections) on a single version of the funder template, not new versions of the funder template.

[rhu001]

Hi @sjDCC I was asking that second question because I wanted to know who was the "user" who could potentially be the one putting the new funder template into the DMP system. Super admins like you and Stephanie and potentially the funder themselves? If that's the case then it might be good to have on their end when they upload the new updated funder template to have some sort of button that says "Notify org admins of change" then that would send out both an email notification as well as put a notification on the org admin's dashboard notifying them that an "action" would need to occur in order for them to fully update their customized local version of a funder template. In the CDL DMP system, we are going to have a dashboard for all admins (both super and local org) that they see as soon as they login that will have all of their outstanding action items on it. That way the notification that a template has changed is not so buried. Does this make sense?

[sjDCC]

This sounds perfect and also addresses the point @stephaniesimms raised in #232 It's good for the template owner / admin to control the notifications as sometimes you're just fixing typos, not doing anything substantive that would affect any institutional customisations.

I guess we need to ensure the customisations are transferred to new versions of templates though when there aren't notifications. One for devs @xsrust @vyruss and @briri to consider...

[rhu001]

Great. Additional clarification... only super admins and funders have ability to upload a new funder template right? Local org admins (even if there are more than one local admin) don't have the ability to do this?

[sjDCC]

Correct. Org-admins can only administer their own institutional templates (though I don't think many have these in DMPTool). It's only funders or super admins who can make changes to funder templates

[rhu001]

Will the researcher end-users who may be in the midst of creating a plan based on a local customized template need to be notified that they need to re-work their plans as well?

[vyruss]

@sjDCC it is impossible to transfer customisations automatically as it is impossible to determine what the template owner will have changed, whether it is adding a comma or deleting a phase and adding 3 new ones. It's the same issue as "minor change/major change" and we decided there should be no such differentiation. Any change in any Funder template creates a new template version and thus renders the customisations of the old version outdated.

@rhu001 it is impossible to change a published template, so the plan the end-users will be working on is not affected. By notifying users of this, I think we'd be building functionality into the tool to fix something which is their responsibility, i.e. making sure that they're using the latest template.

EDIT: I just re-read this and it was impossible to ignore how many times I wrote "impossible" :D

[sjDCC]

Hi @vyruss. Can you explain what happens to any institutional customisations when a new version of a funder template is released. From what Sam said earlier, I understand they are in limbo until the org-admin verifies they are still appropriate and re-publishes? If that's the case we need to make it clear what steps an org-admin needs to follow when a new version of a funder template is released. The current messaging that "Original funder template has changed!" doesn't really explain what they need to do.

10 days ago I suggested we make it clearer that they need to click the link to 'edit customisation' to transfer their customisations through to the new template. If these don't show automatically on new versions of the template (which is how I understand it) then they would ideally switch to being unpublished until the org-admin has checked and made any changes needed.

My suggestion was to change the text in the action line to 'Transfer customisation' instead of 'Edit customisation' and make it unpublished at first. That should prompt org-admins to check their content is still valid and make any changes needed.

@stephaniesimms noted that sometimes the changes we make to a published funder template are trivial e.g. fixing typos, so super-admins should have the ability to turn these notifications off and essentially just push through new versions of templates without requiring action from all org-admins who have added institutional customisations. Essentially if we know the changes won't have affected any suggested answers, guidance or additional sections, we shouldn't prompt them all the validate changes. We can address this use case as part of the MVP release though under #232

For now the main issue is to clarify any steps org-admins currently need to follow when the "Funder template has changed" notice appears, and make these clear in the MVP 0.3 release code.

[xsrust]

changing the text to 'Transfer customization' should be trivial.
Is that the only change which would need to be made to clarify the steps to org-admins?

[sjDCC]

I think so, as well as ensuring their customisations are unpublished on the release of a new version of a funder template. Currently they still show as published so it's not clear you need to do anything.

Thinking about this some more it would actually really help to know exactly what happens to their content (guidance, suggested answers etc) when a new version is released....

I've just looked into one template with this "Original funder template has changed!" warning to test things out. When I clicked 'edit customisation' I could see my annotations. On returning to the front template table screen, the warning has now appeared. I guess the act of me clicking 'edit customisation' has pulled all my content through to the new version of the template and published it. There was no indication it was unpublished at any point.

If the scenario above is accurate, I would suggest:

1. change 'edit customisation' to 'transfer customisation' in cases where a new version of a funder template has been released
2. on clicking 'transfer customisation' we should pull through any institutional customisations to the new version of the funder template, but not auto-publish
3. Ensure institutional customisation is 'unpublished' when a new version of a funder template is released and remains so until the org-admin has checked/amended their content AND clicked to republish it. Feasibly the changes could be new questions and sections so we don't want to auto-publish when transferred, which seems to be what is happening currently.

Does that sound right @stephaniesimms @rhu001 @JEK-III

If so there are two changes - adjusting 'edit customisation' to 'transfer customisation' and making institutional customisations unpublished until verified and republished by org admin.

[sjDCC]

Have just tested this and new workflow works. Thanks @xsrust Closing out.