I’m trying to take advantage of Fibery’s permission features, but I’ve run into a couple of roadblocks that I’m not sure how to solve.
Setup
Database 1: Tasks
Database 2: Subtasks
Permissions: No one can view a Task or Subtask unless they’re assigned to it
Issue#1:Subtask users can’t see the parent Task
Subtask assignees still need visibility into the parent Task for context - descriptions, links, files, comments, etc.
Right now, they can’t see any of it unless we also assign them to the parent Task, which defeats the purpose of keeping Task-level and Subtask-level visibility clean and accurate.
Question:
Is there a way to let users view a parent Task if they’re assigned to one of its Subtasks without giving them access to every Task?
Issue#2:Contributors lose access after reassigning
If a contributor updates an entity (task/subtask) and then assigns it to someone else, the entity disappears from their view immediately - meaning they can no longer access or edit it if they realize they need to make another change.
This is creating a workflow problem because contributors often pass a Task/Subtask along and then realize something they want to adjust, but can’t access it anymore unless we re-assign them the entity.
Question:
Is there any way to tap into the activity log - or any other mechanism - to allow a user to retrieve or at least view entities they’ve recently touched, even if they’re no longer the assignee?
Something like “recently edited by me” visibility, or any rule that keeps the entity accessible after they’ve interacted with it?
Issue #1
Create a new field in the task database and let it equal parent task assignees and subtasks assignees in one collection (I think we can do this using formulas). This field should control access. If you can’t use one calculated collection, then rollup assignees of subtasks to the parent task instead and control permissions using assignees and the rollup.
Issue #2
I think the problem is actually your flow of work here.
If collaborators need access to more than just tasks they’re explicitly assigned, then I don’t recommend access be tied to the assignee field. What’s the criteria where a collaborator should be able to tweak something when they’re no longer assigned? Is it for certain projects? Is it for certain task types? I’d look for the real common denominator there since assignee is not it.
That said, you can create an automation that logs all assignees to a separate user field and have that field control access. I just don’t think that’s good data.
I’m running into chaos with the current setup and could use some guidance.
Right now, the automation updates the Members field, but it overwrites whatever was there before. That means teammates keep losing access to entities they previously had access to, which obviously isn’t ideal.
So after digging in further, it looks like updating Members via functions just isn’t possible.
Members is a Collection field, and collections are limited in Fibery functions - there’s no way to merge or manipulate them the way you’d expect.
I’d really appreciate any feedback on this approach, because honestly, I’m not 100% sure this is the best way to go about it.
And for anyone from the Fibery team who might be reading: please, please take a look at how Coda handles functions. Working with Fibery’s functions is brutally painful compared to Coda. Coda is in a league of it’s own when it comes to functions.
Here’s the script I ended up with
// Helper to always return an array
function toArray(val) {
if (!val) return [];
if (Array.isArray(val)) return val;
return [val];
}
// Set your Task database type here (e.g., "Task" or "Project Management/Task")
const TASK_TYPE = "Task";
const MEMBERS_FIELD = "Members"; // Adjust if your field is named differently
async function run() {
for (const subtask of args.currentEntities) {
// Get the parent Task reference from the Subtask
const taskRef = subtask['Task'];
if (!taskRef || !taskRef['Id']) {
// No parent Task, nothing to update
continue;
}
// Fetch the latest Task entity with its current Members
const taskEntity = await fibery.getEntityById(TASK_TYPE, taskRef.Id, [MEMBERS_FIELD]);
// Normalize fields to arrays
const subtaskAssigned = toArray(subtask['Assigned']);
const currentMembers = toArray(taskEntity[MEMBERS_FIELD]);
// Build a set of current member IDs for quick lookup
const currentMemberIds = new Set(currentMembers.map(u => u && u['Id']));
// For each assigned user in the subtask, add to Members if not already present
for (const user of subtaskAssigned) {
if (user && user['Id'] && !currentMemberIds.has(user['Id'])) {
await fibery.addCollectionItem(TASK_TYPE, taskRef.Id, MEMBERS_FIELD, user['Id']);
}
}
}
}
return run();
Another issue with this approach is the flood of notifications it creates for the team. Both automations are running purely for permissions, and nobody needs alerts about these actions.
Is there any way to suppress or hide these notifications?
No, there isn’t. You would probbaly need to use an automation to keep a person linked to the Task (via an additional people field) even after being unassigned
