How to have a document file be "owned" by a page.

[mjmare]

AFAICT whenever I upload a file to WT it will be dumped into the Media/documents folder (or some subfolder).
A user can reference the document with the DocumentChooser widget from any page. Makes sense in the general context of HTML pages. One could say that the document is not owned by any page.

Now I'd like to have a page "own" its documents. IOW documents uploaded within the page's context are stored in the page instance or in tight connection with that page, and are not selectable from other pages. When the page is deleted, I want the documents to be deleted as well.
Hope this makes sense.

I think my solution derives from the fact that I don't like the lack of structure of the documents folder.
Maybe the Wagtail way dictates some other solution. Any suggestions welcome!

[mjmare]

No takers?

[thibaudcolas]

@mjmare I think you can achieve some of what you’re after either with collections (one per page or part of the site) as a user of the CMS, or by configuring Django’s on_delete for your fields as a dev?

Collections are meant to be something users set up without necessarily being tightly integrated with pages, but I imagine you could do more as a dev to auto-create collections for documents matching pages.

[thibaudcolas]

I don’t think collections can be hidden in the UI. I guess it depends what you mean by "protected" here – documents could be visible elsewhere, unless you wrote custom code to restrict which collections of documents are available across different parts of the site.

[mjmare]

I'd like the document file to be completely controlled (saved, updated, deleted) by a specialised page model. I do not want it to be selectable in a collection or chooser. The page model would handle the file's metadata and index the document and create a preview perhaps.
Maybe that is not the Wagtail Way?

Some background: in my organisation we have several hundred "quality documents" (meaning mostly instructions on how to do things), mostly .docs and .pdf. In our current "quality management system", a Plone CMS site, every document is a Plone file object with metadata (title, slug, version, short description, responsible persion, revision interval), the file itself, and a file preview (series of images). Within the Plone site one links to the Plone file object, not the file itself. I'd like to replicate this in Wagtail.

[thibaudcolas]

What you’re describing here seems quite different to me to what you had described first. The background you describe is the same as how Wagtail handles documents, with a Document model (or custom model) instance storing a reference to the actual file as well as metadata.

I’d suggest you look further into the capabilities of this default Document model, and yes if you want to completely lose the document organisation features then you might be better not using that at all, instead re-implement this with a Django FileField.

[mjmare]

@thibaudcolas You think? I'll probably go with the Filefield. Didn't realise that was an option in WT, since it is not mentioned in the docs.
I'll investigate further.

[thibaudcolas]

👍 Wagtail is heavily based on Django, so yes generally the idea is that everything Django supports should work there too.