I've been benchmarking Humata's performance for team-based research workflows, but the shared workspace permissions are creating inconsistent test conditions. When I add team members to a workspace, their access levels seem to behave unpredictably.
Here’s what I’ve observed across three test scenarios:
**Test Case 1: Basic Researcher Role**
- User assigned "Researcher" role in "Project Alpha" workspace
- Could view all documents but could not export summaries
- However, same role in "Project Beta" could export but not add annotations
- No visible configuration difference between workspace settings
**Test Case 2: Nested Folder Permissions**
```
Workspace: Cloud_Cost_Analysis
├── Folder: AWS_Reports (view-only for Contractors)
│ └── Subfolder: Q3_Optimization (accidentally inherited edit rights)
└── Folder: Internal_Audit (admin-only)
```
The subfolder inherited incorrect permissions despite parent folder restrictions.
**Test Case 3: External Collaborator Access**
- Added client@external-domain.com as "Viewer"
- Client reported seeing documents from other workspaces
- Audit log showed correct workspace assignment but cross-workspace visibility
Has anyone conducted systematic tests on Humata's permission model? I need to establish baseline expectations for:
- Role inheritance across folder structures
- External user boundary enforcement
- Permission propagation time (observed 2-15 minute delays)
The documentation mentions "granular permissions" but provides no schema or inheritance rules. Without this, I can't reliably configure multi-team research environments.
Numbers don't lie
That permission inheritance issue in your second test case is a classic. I've seen this exact pattern in document management systems where the subfolder doesn't properly override the parent ACL.
Your third case, with the external viewer seeing cross-workspace docs, is more concerning. That suggests either a backend data isolation bug or a caching layer serving stale permission sets. Did you check if the visibility was to documents in *all* other workspaces, or just ones with similar naming conventions? Sometimes fuzzy matching on workspace IDs causes leaks.
For systematic testing, you'll need to script the role assignments and audit the API responses directly, not just the UI. The UI often polls permissions asynchronously, which masks the real permission state.
Integration is not a project, it's a lifestyle.
Yeah, the classic inheritance problem. It's less about the subfolder override failing and more about vendors shipping half-baked ACL models from the start.
Scripting the API is the only real check, but it's a band-aid. If you need to write audit scripts to verify basic data isolation, the product itself is the problem. Stale permission caching is a symptom of them treating security as a UI feature, not a core architecture requirement.
Your favorite tool is probably overpriced.