IntraVox Users can open editor but saving fails with HTTP 400 when using Team Folders

[todesberg]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Environment
Nextcloud: 34.x
IntraVox: 1.6.1
Team folders: 22.0.1
Setup
IntraVox content is stored in a Nextcloud Team Folder.
The Team Folder is not additionally shared via the Files app.
No Advanced Permissions (ACLs) are configured.
The Team Folder is assigned to the following groups:
IntraVox Users
IntraVox Admins
Only IntraVox Admins have write permissions on the Team Folder.
IntraVox Users have read-only access.
Expected behavior
Users that belong only to the IntraVox Users group should:
be able to browse the documentation,
see the navigation,
not be able to edit pages,
not see the Edit button.
Actual behavior
Users that belong only to IntraVox Users:
can browse all pages,
can see the navigation,
can open the page editor,
but saving any page fails with HTTP 400,
creating a new page also fails with HTTP 400.
Administrators can edit and save pages without problems.
Server log
When saving a page as an IntraVox User, Nextcloud logs:
[updatePage] InvalidArgumentException:
Failed to write updated page data
At the same time Nextcloud reports:
Undefined array key ...
lib/private/Share20/ShareHelper.php
followed by
foreach() argument must be of type array|object, null given
Additional observations
During troubleshooting we observed some inconsistent behavior:
Initially normal users could not see the navigation.
After adjusting Team Folder permissions, the navigation appeared.
At one point even administrators temporarily lost the ability to edit the home page (home.json).
After some time this resolved itself without further changes.
The only remaining issue is that IntraVox Users can open the editor although they should not be allowed to edit, and every save request fails with HTTP 400.
Questions
Is this expected behavior?
Should the editor be hidden for users that only belong to IntraVox Users?
Could this be related to Team Folders on Nextcloud

Server configuration

Web server: Nginx

Database: Maria

PHP version: 8.5

Nextcloud version: 34.0

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your Nextcloud installation folder

Nextcloud configuration

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your Nextcloud installation folder

Browser

Browser name: Firefox /Edge

Operating system: Windows 11

[Rikdekker]

Thanks for reporting. We will address this in the next version. 1.7.0 is just released. This is not yet part of it

[Rikdekker]

Fixed in v1.8.0, now live on the App Store — thanks for the detailed report and the server logs, they made the root cause clear. 🙏

What was wrong: permission reporting used only Nextcloud's raw permission bits, which on a read-only Team Folder without Advanced Permissions still reported write — so the Edit button showed, the backend guard didn't fire, and the save then crashed at the filesystem with HTTP 400 (plus the follow-on core ShareHelper error).

What changed:

• Write/create/delete permission is now derived by combining the permission bits with the node's own isUpdateable()/isCreatable()/isDeletable(), which reflect the mount's real writability. So the Edit button is hidden for read-only users, and a forced write returns a clean 403 instead of a 400.
• Reading navigation/homepage no longer tries to create the language folder for read-only users — that explained the intermittent 'navigation not visible until permissions were adjusted'.

Verified end-to-end with a user who is only in the read-only group: page loads, Edit hidden, save → 403, no ShareHelper error. Closing as fixed.

[todesberg]

Hi,   I've updated to the new version but read-only users still see the edit page button. They get a 403 if they try to write something. Is it possible to hide the button for read-only users (Intravox User group) entirely?   "Rikdekker" ***@***.*** – 7. Juli 2026 um 09:09 

  Closed #70[1] as completed. —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

Links: ------ [1] #70

[Rikdekker]

Thanks for testing and reporting back @todesberg — you were right, the button was still showing. I found (and fixed) the root cause.

Two things were going wrong for a read-only Team Folder member (a group mapped as read on the folder, no Advanced Permissions):

1. The button and the save disagreed. A page's canWrite was computed from the page folder, which a read-only Team Folder reports as writable, while the actual save checks the page file. So the button appeared but the save 403'd. canWrite is now gated on the same file the save writes to, so the "Edit page" button (and page settings) hide when you can't actually write.

2. A caching leak. Page permissions were briefly cached in a shared cache, so an editor's "can edit" could be served to a read-only user for a short while. Permissions are now computed per-user on every request and never shared.

I verified it on a test instance with exactly your setup (Team Folder, Advanced Permissions off, an "IntraVox Users: read" group): the read-only user now gets no Edit button, while editors still do.

The fix is on main and will ship in 1.8.1. No frontend/JS change was needed, so it takes effect as soon as the app updates. Could you confirm once 1.8.1 is out? Reopening isn't needed from my side, but happy to if anything's still off.