Disabling edits on Document elements

[jvwong]

Description

Q: What is the name of the feature?

A: Disabling edits on Document elements

Q: What does this feature enable the user to do?

A: Provide for a stable representation of the elements in a Document

Q: What information must the user provide to use the feature?

A: Author confirmation via Document submission

Q: What are the applicable constraints, e.g. compatibility or performance?

A: Edge cases and considerations:

• Handling Documents with submitted (but not public) status due to blocking (e.g. blank nodes)
• Handling updates or corrections
• Relationship with versioning, DOIs, downstream data representation

Q: How does this feature affect each class of user (persona)?

A:

• Editor: Satisfies the concept of "publishing" a record, enabling it to be tied explicitly to another object (i.e. publication)
• Computational biologist: Provides data for which reproducible analysis can be performed
• Curator: Author curator will transition from "editing" to "viewing" mode for their record

Specification

Mockup

Status: initiated
Showing warning message about submitting. This would be a problematic record (not public).

Status: submitted

Details

// TODO - Frankly, most of the information in the submission popup (tweet, explore) is in the Explorer view anyways.

[maxkfranz]

The model has the foundation of this feature at the Syncher level:

https://github.com/PathwayCommons/factoid/blob/unstable/src/model/syncher.js#L814-L828

It would suffice to add a lock() method on the Element class that uses syncher.lock(), if all we want to do is lock the elements/network. Then, we just lock() all the elements upon submission.

[maxkfranz]

Another consideration is the editor view if you go back to the edit link. If it's locked, then some UI feedback would be useful.

[jvwong]

Since there is more logic around status changes, need to cleanup: #1223

[jvwong]

Definition of what "disabled editing" encompasses:

• Disable
  • add or delete element
  • rename or associate element
  • drawing toolbar?
  • x/y position?
• Retain
  • meta-data update (e.g. relatedPapers)

[jvwong]

@maxkfranz I wonder if it's better fit to change the Document model editable() value?

[maxkfranz]

Currently doc.editable() is just whether the user has permission to edit -- i.e. they have the editable link.

We could change doc.editable() to be hasPermission && !isLocked().

[jvwong]

Right now, if an element is locked, can't (obviously) set fields like relatedPapers() or any other subclass setter (e.g. interaction.setNovel()).

[maxkfranz]

Notes re. locking, if needed in future:

Syncher:

• lock() operation to prevent writes, making the data r/o
• lock() needs a key, should be the same for everything in a doc
• add a list of fields that are affected by a lock, class field (each class can override the fields list)
  • e.g. position should be locked for node
  • e.g. related papers should NOT be locked for any element
  • [outline all the data fields, at least the ones that shouldn't be locked...]
  • decision: allow-list v.s. block-list
    • option 1: specify every field that gets lock() applied (safe and easy w.r.t .subclasses, new data field)
    • option 2: make a list of every field that doesn't get applied to lock() -- nice for adding new lockable data if amend the model significantly

Element:

• expose lock() on this base class

Document:

• expose lock() on doc itself
• difficult: authors can edit the title v.s. metdata refresh edits the title
  • if a lock is a lock no matter what, then refreshes/cron would also be blocked

[maxkfranz]

Decision for now:

The doc has an editable() method that is used for determining if the UI can go to the editor mode -- versus the explore view:

https://github.com/PathwayCommons/factoid/blob/unstable/src/model/document/document.js#L149

Currently, this is based on if you have the secret/password to edit the doc (i.e. you're the author who was sent the edit link). Let's add in a condition so if the doc is submitted, then it can only go to the explore view.

editable(){
    return this.syncher.hasCorrectSecret() && this.submitted();
  }

Open questions:

(1) Would this glitch out the editor once you hit submit as an author? Maybe it's fine as-is. But we need to test.

(2) Should we just use a new flag so that it's more fine-grained, more controllable/changeable in future?

[jvwong]

Related to #1197