User role with update permission set to false can still upload/sort/delete files on page

[trych]

Describe the bug
If there is a panel page that disallows a user to update the page via update: false, all the fields are disabled, but the user can still upload (and sort, and delete) files to a file section.

To Reproduce
Steps to reproduce the behavior:

1. Create a page blueprint that disallows to update the page via

options:
  update: false

2. Add a files section to it.
3. Navigate to the panel page of said page.
4. Use the add button (or click the empty files field): it allows you to upload files, you can also delete files and change their sort order.

Expected behavior
The upload should be disabled, as one would expect that updating a page also includes changing the files belonging to the page.

Kirby Version
Kirby 3.6.0-rc.4

Desktop (please complete the following information):

• OS: 10.13.6
• Browser: Chrome

[distantnative]

The upload should be disabled, as one would expect that updating a page also includes changing the files belonging to the page.

I think this is rather a point of discussion. I would perceive this not as a bug but a disagreement with the current implementation.

[trych]

As files are children of a page, I consider them part of the page and I would assume that they cannot be changed, especially not deleted when I am not allowed to update a page.

I think it also feels very wrong when I visit a page as a user with no permissions and cannot edit any field but I can happily delete all the files that I find on the page.

[distantnative]

I can see your point. The counterpoint is that there are specific files permissions. Could be weird as well when you think you've set them right but a very different permission setting suddenly affects these as well

[trych]

Well file permissions are (if they are not globally) per file template, aren't they? This does not really help me, if I want to disallow upload and deletion of files on a certain type of page, but allow the upload and deletion of the files of this type on another page.

There really needs to be a way to lock a page's files sections, so users without permissions cannot mess with them, no matter the file template that is used. Especially since changing the files will change the page's frontend appearance in many cases. And from a naive backend dev perspective, I would assume that would be handled by a page's update permission.

Edit: But thanks for adding the discussion label, I'm also curious what others have to say about this. :)

[bastianallgeier]

I think this is one of the parts where our permission system really needs to get better/clearer. The update permission for pages is really just about the fields. I.e. you can set update to false and the title or url can also still be changed. Those are separate permission options as well. So we need to find a better way to block all options for a page, including the files and children.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[trych]

So, as this was automatically closed as "not planned", while it is apparently planned according to @bastianallgeier, should this be re-opened. Or is there already another issue for it?

[lukasbestle]

The issue was closed because it was stale (no activity). Your comment means that the issue is still relevant to you, so of course we reopen it.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. This is for us to prioritize issues that are still relevant to our community. It will be closed if no further activity occurs within the next 14 days. If this issue is still relevant to you, please leave a comment.

[trych]

This would still be relevant for me. :)

[distantnative]

We talked about this again at length in the team and this is really more an enhancement/feature request that we need to move over here https://kirby.nolt.io/528 for now as we really need a better structure for us to keep track of bugs in the existing functionality.

[trych]

@distantnative Thanks for the feedback on this.

I must say I find it very frustrating that something that has been registered as a bug here for more then a year is just moved to the bottom of the kirby.nolt pile where nobody will see it and nobody will care. It just means, it's not gonna happen.

From my user perspective this is a bug, as something does not work as I expect it. I understand that this can be seen differently, in which case I wish that at least documentation would be more clear on this (although I haven't re-checked that right now, so I don't know its current status).

[distantnative]

It just means, it's not gonna happen.

If you check the roadmap on Nolt right now you'll see that there are things already flagged as in Kirby 4 with just a few votes. For us, Nolt isn't just about votes that define what gets implemented. Also, we talked about the topic of permissions a lot as we want to see where we take them with Kirby, so that's a more general discussion that is important for us and in no way forgotten just because we don't treat this as bug.

But talking about it also made us realise that we need to be stricter for our organisation what's a bug and what's a request for enhancement, feature etc. so that we can treat (critical) bugs with more care as they're less drowning in requests.

[trych]

But talking about it also made us realise that we need to be stricter for our organisation what's a bug and what's a request for enhancement, feature etc. so that we can treat (critical) bugs with more care as they're less drowning in requests.

That sounds like a good thing, and since you seem to have discussed this in detail, I trust that you know what you're doing. I still fail to see how the Nolt thing is of much use, I stopped using it altogether because I don't feel like it leads to anything, but if you guys find it helpful, fair enough.

Anyway, thanks again, appreciate the explanation.