Administrative Locking

[G-Ambatte]

Checklist:

• Modify getBrew so a locked brew will return an error - PR Add administrative brew locking function #3327
• Modify EditPage so a locked brew will pop a notification - PR Add blocking notification to EditPage #3382
• Create API route to add/update/remove lock object on brew stub - PR Add lock routes #3421
• Create Admin UI page(s) to manage locks - included in PR Add lock routes #3421

---

Your idea:

On occasion, the administrators of the Homebrewery website will need to lock a brew down, so that it cannot be accessed by anyone - not even the authors. Specifically, I am thinking of legal action, such as a DMCA takedown request.

My suggestion is that we create the ability to add a new property to the document's stub in the local Homebrewery database, lock or something similar.

lock: {
  active: true,
  code: 451,
  message: 'This brew has been locked due to DMCA Takedown Request. Please contact the Administrators to resolve this activity.'
}

During the getBrew process, if the lock property exists and lock.active is true, an error should be thrown of type lock.code with an error message of lock.message.

Mock up of final error page:

I would also expect that a lock page would need to be added to the Admin pages, to allow administrators to apply and remove such locks without needing to access the database directly.

[ericscheid]

Would the author still have access to the /edit/:id resource?

What if the locked brew is currently being used as a theme source?

[G-Ambatte]

As I currently envisage it, the locking would occur during the getBrew function, which would prevent access via any method - share, edit, source, download, and presumably also as a theme source.
Theoretically, locking the brew down from any possible method of access should bring the locked status to the authors' attention quickly. In the example of a DMCA takedown request, we would absolutely not want to have the offending material being served to other documents via a shared theme source.

[ericscheid]

Being unable to edit the locked document would make it difficult for the author to fix things.

[5e-Cleric]

Being unable to edit the locked document would make it difficult for the author to fix things.

Hence why there will be a call to message the administrators... although if someone doesn't have discord or reddit this could get weird

Do you think there is worth in creating another gitter room to use as modmail? or simply redirect them to reddit and force them to make an account?

[ericscheid]

Being unable to edit the locked document would make it difficult for the author to fix things.

Hence why there will be a call to message the administrators

They will still be unable to make changes, unless the lock is first removed by administrators, necessitating some possibly tricky time coordination (considering timezones etc).

Would perhaps be better then that the editor UI pops an alert, with instructions to the author on how to contact the mods for more information (but still allow editing)

[calculuschild]

I think this should block everything except the Edit page, with a popup there as @ericscheid suggests. Don't add any barriers that would make it hard for users to fix their problem. Feels way too Kafkaesque.

[5e-Cleric]

Mockup for the UI

[G-Ambatte]

As it currently stands, the lock function needs to have options to apply a code, public and private messages.

[5e-Cleric]

As per right now, via #3421 locking works, only with share ID, as intended.

Review is yet to be implemented, and notification in edit page is done in #3382.

I suggest lock state shows up in admin brew lookup function, just to be safe.