Editors without publish permission can easily change images on live pages.

Issue Summary

Editors without publish permission can easily change images on live pages.

Steps to Reproduce

1. Suppose we have a page defined like this:

class SamplePage(Page):
    image = models.ForeignKey(
        'wagtailimages.Image',
        null=True,
        blank=True,
        on_delete=models.SET_NULL,
        related_name='+'
    )

    content_panels = Page.content_panels + [
        ImageChooserPanel('image')
    ]

1. As an administrator, create a new group with permission to add (without publish) pages in a particular directory.
2. Also, give this created group, the permission to add images.
3. Create a new user in that group.
4. Login as the created user and upload an image and create a SamplePage and submit it for moderation.
5. As an administrator, approve it and publish the new SamplePage.
6. Login as the created user again, Now you can easily change the image on the live SamplePage !!! And no moderator can prevent you to do that !!! In other words, you can ruin the whole page when it is live.

This is a real bug I think. Because, as an administrator, I don’t want people without publish permission, to be able to change the live pages whenever they want.

[HsnVahedi]

Thanks a lot for sharing your concerns. @ababic

You are completely right about the importance of being able to manage media centrally. It has to remain in wagtail.

But I beileve giving developers the ability to use a new way of managing media for some of their images/documents/… fields, makes wagtail really powerful.

in your use case, what is the real concern?

I want to have a complete CMS in which a lot of editors (unknown people who moderators might not trust) could create content. I don’t want any of the editors to put some image on a live web page without moderators approval.

1. How would we make content editors aware that they are using an ‘old’ version of an image/document somewhere? How would we encourage them to keep content up-to-date (if at all)?

1. How would image revision history be managed (in UI terms)? I’ve seen sites with 5,000+ images in the library. Keeping every version (original + all revisions) of every image, both in the database and in file storage, could easily become a burden.

I think answering to these questions is really hard (even if I would have understood them correctly). As you’ve mentioned, keeping versions of images/documents/… is really hard and complex. I have discussed a much simpler approach in this issue which doesn’t require keeping versions.

How would we also support simpler use-cases where centrally managed images/documents is preferred?

I do believe supporting the current way of managing media is really important. Wagtail should support the current way as well as a new way of referencing images/documents/… from pages.

Would this be an option in the chooser UI? Or perhaps a flag on the image/document itself?

I’m not really sure. But it has to be scoped to pages. I would suggest using some intermediate class type like Orderable s.

The best route is almost always to create a third-party app first, where things can evolve organically, not tied to Wagtail’s release process. If you have avenues you’d like to explore, may I suggest trying this approach?

It would be a great honour if I could create such a third-party app for wagtail. But I don’t know when that would be possible for me, so don’t count on me.

[ababic]

Thank you for the thorough reply @HsnVahedi.

Here’s a solution that might work… Like we have a ‘lock’ mechanism for pages to prevent editing, we could technically do the same for images and documents, and lock/unlock permission could be given only to moderators.

With this in place, you could probably utilise existing hooks to identify and lock the relevant images at the time a page is published (depending on the owner). OR you could maybe specify at a collection-level whether media uploaded to that collection should be locked automatically when uploading media to them.

What do you think?