more permissive unregister access

[graybeal]

@carueda suggests that we might loosen up the unpublish ontology' access:

Enable the Unregister option also for the owner of the ontology but only when the visibility of the ontology is owner and perhaps also when the status is not stable

I think for owner-private ontologies they should be able to unregister whatever they want. There is no concern in that case about the ontology being depended on by other people.

If the ontology is public, I hypothesize that any non-stable ontology (draft, unstable, untested) could be retracted. Yes, it may be that some people would have used those ontologies, but there is an "at your own risk" aspect to that, it seems to me. A thought in that case is that the "Unpublish" command trigger "Are you sure?" guidance that explains why it may be worth leaving the ontology, e.g.:

We ask that before unregistering your ontology you consider whether anyone else might already be using it, and whether it could offer future value to other users even though it is no longer useful to you.

The possible responses could be "Good point, cancel my request" and "I still want to unregister my ontology".

Also, creating a 'deprecated' status might make people more comfortable leaving their ontology online. Would it be hard to add that? Would I need to create a separate ticket?

[carueda]

Just for reference:

The confirmation dialog looks like this when about to unregister a particular version:

and like this when about to unregister the complete entry for an ontology (including all revisions):

[lewismc]

Nice job @carueda

[carueda]

ha, I haven't done anything yet ;) ... just thinking about adding more info to these dialogs along the lines of what John is suggesting above..

[carueda]

@graybeal @lewismc

Toward implementing this, here is how these dialogs look like now in my local dev environment:

For a particular version:

For a whole ontology entry:

Note that I have included more details about the affected version(s) so the user have more context before proceeding with the unregistration.

For a bit easier implementation, without compromising too much the functionality/usability (IMO):

• admins continue to have all the privileges incl unregistration;
• but, now also the owner (whether direct user or on behalf of submitting organization) can proceed with unregistration but only if the ontology's visibility is not public;
• adding more rules to this logic would take more effort (and time is very limited).

If you agree with this implementation, I can include this as part of the next 3.8.8 release (along with the also recently implemented #150).

[lewismc]

+1 this looks good. Do you think we should capture it as a user story?

[carueda]

Thanks @lewismc . I went ahead and included this in the just released 3.8.9 (already enabled for COR). We can adjust if/when needed. Please help with testing.