Add more mod actions (always set status, depublish attachments)

[pajowu]

• 🚸 Always allow mods to change request status
• ✨ Allow mods to depublish attachments

[pajowu]

The publish_document task exists early if the document is still pending (not changing the public value of the document). This could lead to some weird behaviour if the document is not yet fully processed, but depublished in the meantime. I'm not sure what the best solution here is. Should we change the task to retry later or just accept it, as this should hopefully not happen?

[krmax44]

The publish_document task exists early if the document is still pending (not changing the public value of the document). This could lead to some weird behaviour if the document is not yet fully processed, but depublished in the meantime. I'm not sure what the best solution here is. Should we change the task to retry later or just accept it, as this should hopefully not happen?

Not quite sure if I understand correctly. The publish_document task checks if the document is currently processing: https://github.com/okfde/django-filingcabinet/blob/3b1dc92d89da48af9851e37a22ac1310922b9c73/src/filingcabinet/tasks.py#L49-L50

[pajowu]

Yes exactly. In this case, the tasks just does nothing. If someone creates a document from an attachment and then shortly after that depublishes the attachment (while the document is still processing), the approved-field of the attachment would be set to False, but the document would not be set to private. This would lead to a public document for a non-public attachment

[krmax44]

Ah, I see. Maybe we could use Celery's task linking to run the publishing/depublishing task after the processing task (if a processing task exists)?

[stefanw]

Task linking could be an option, would be the first of that in the code base. Another option could be a signal from filingcabinet like document_processed or document_published (or both). Request or attachment code could listen and then decide to reverse a publication if the possibly associated attachment (or the request?!) is not public. But this could be also an excellent source of confusion if actions can be undone by some unrelated code bits.