FormVox 1.4.4 on Nextcloud 34 — public form links return 404 for forms stored in Team Folders (Groupfolders)
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 6
- Forks
- 5
- PR merge metrics
- No merged PRs in 30d
Description
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.
Steps to reproduce
I'm reporting a reproducible bug with the FormVox app when forms are stored inside a Team Folder (Groupfolder).
1.Create a Team Folder (Groupfolder) mapped to a LDAP group.
2.As a member of that group, create a form inside the Team Folder.
3.Generate the public link for the form.
4.Open the public link in a window or preview → error 404 (Something went wrong Form not found).
Server configuration
Nextcloud Server: 34.0.3.2 (Docker, nextcloud:34-fpm image, nginx reverse proxy, MariaDB 11.4, Redis) FormVox: 1.4.4 PHP: 8.5.9 User backend: LDAP / Active Directory + SAML SSO (ADFS) Team Folder access granted via LDAP/AD groups, plus a Circle ("Team Folder owners")Bug description
A form (.fvform file) created inside a Team Folder returns HTTP 404 with no server-side exception when accessed through its public link:
/apps/formvox/public/{id}/{hash}
However, the same form is fully accessible through the authenticated API for a user who is a member of the Team Folder:
/apps/formvox/api/form/{id}/... responds normally.
The same operation works perfectly when the form is stored in a personal folder instead of a Team Folder.
Evidence
The form file is confirmed to be stored in the Team Folder storage:
oc_filecache: path = files/IT - Applications/eva-vr-dsit-montaudran.fvform, storage = 153
oc_storages: id = local::/var/www/html/data/__groupfolders/1/
Server logs (loglevel 0 / DEBUG) show no exception at all for the public request — only the deprecation notice OCP\AppFramework\IAppContainer is deprecated. The 404 is returned cleanly.
In the same log window, the authenticated API call /apps/formvox/api/form/{id}/presence (as an LDAP user, member of the folder) responds without error.
Suspected cause
The public route is served in an anonymous context (no logged-in user, user: -- in logs). In FormService.php, findUsersWithGroupFolderAccess() is expected to resolve a user who can access the Groupfolder in order to load the file via that user's folder. In our setup — where the Team Folder members come from LDAP/AD groups and a Circle — this resolution appears to return no usable user in the anonymous context, so the file cannot be resolved and the endpoint returns 404.Expected behavior
Public form links should resolve forms stored in Team Folders (Groupfolders) for anonymous visitors, as they do for forms stored in personal folders.Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the anonymous /apps/formvox/public/{id}/{hash} route and FormService.php, especially findUsersWithGroupFolderAccess(). Compare how the public endpoint resolves files in personal folders versus Team Folder storage, and check the authenticated API behavior described in the report. Done means an anonymous public link resolves a Team Folder form instead of returning 404.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100