Second Attachments PR - Githubissues

Draft because this is still incomplete, but better than nothing.

Quick rundown

The Attachment model holds the attachment file, but is in itself not attached to anything. Actual usable attachments are subclasses of this model with an attached_to field to point to their owner. This allows for Attachments to many different kinds of other models, should we want to attach files to Review or Wmo objects in the future. The Django docs on subclassing models are recommended reading for a good understanding of this.

Attachment slots are what they sound like. They are created by checkers, are held by the Stepper object, and render as a place to put an attachment.

Attachment views

The Attach view is used to attach a new file to an object. There are different URLs for Proposal and Study attachments, but these simply point to the same view with a small modifier. If a kind is passed in the URL, this will be enforced in the form. This is the case for filling "required" slots. If no kind is passed, this is probably an extra file and the user is free to choose a kind.

The detach view is like a Delete view, except that it calls Attachment.detach(), which only deletes the attachment if it is no longer attached to any other models. Otherwise it simply removes the given ManyToMany relation.

The update view isn't too special at this point. If an Attachment is only attached to one object, it should just update the attachment as it does now. However, if the attachment is attached to multiple objects, it should create a copy and set its parent relation to the old object. This is not implemented yet, but is necessary to not mess with historical objects. I'm 90% sure about how this will work from previous revisions of this branch but bear with me while I test a little more.

Attachment kinds

In previous implementations these were far more elaborate, but I've moved away from putting logic in them. We still could, but right now they're just places to put strings, defaults, and help texts relating to different kinds of attachments. Which is fine.

What I still need to do

The main yet-to-be completed feature is Attachment revisions in AttachmentUpdateView as described above. This needs implementation and testing with regards to proposal copies and revisions.

What still needs doing but not necessarily by me

Permissions on AttachmentDownloadView
Port the old Filename generation
Update checkers to add the slots when required
Update documents_list for the review_detail_sidebar
Error messages for missing attachments. This should be straightforward, we can loop over stepper.attachment_slots and check for any slots which are required but have no attachment.
Some CSS niceties, maybe some more flavour/help text

In conclusion

It's hard to believe that I've ended up with the core of this feature being less than 500 lines or so. But it took a lot of rewriting overly complex ideas I had to get to this point. I probably should have published something earlier, I dithered a lot on this so sorry about that.

If something looks weird please keep in mind this is a little rushed and there's probably vestigial code lying around from previous revisions. I would not recommend an in-depth review at this point, but this branch is definitely ready to receive further feature PRs into it.

DH-IT-Portal-Development / ethics

Second Attachments PR #716