I have an app that lists and categorizes documents. As an admin I use a choice component to flag documents for users by their organization’s name. So I have columns like “Review” “Completed” Etc.
As admin, I have a choice component that allows me to select a document, and then select the same status for multiple organizations. So it might look like this:
I want users to be able to access the same choices and modify them, but only for their organization. They shouldn’t see or be able to select the names of other orgs.
I’ve tried two approaches that work so far as limiting the choice that is shown. For example, using a filter based on the user table to only show the choice that matches their organization’s name. I also tried using visibility to have two different views based on wether they were admin or not admin and then having the not admin window use a different “source” that was just their organization’s name, but writing to the same field as the admin window would do.
in both instances, doing that resulted in selecting or deselecting in the non-admin view would overwrite the existing values and write just the single org name or empty the field.
That wouldn’t work for my use case, I don’t think. First of all each user within an organization would end up seeing different values. Also,if the user changes their org’s status (unselecting review and selecting compete, for example) both that user and I need to see the same data.
In other words, what I need is: as Admin I can set the status for all orgs. And all orgs can change what I set, but only for their org.
These columns would consider whether the signed-in user’s org is included in the review or completed list. The equivalent of this not using code is split text + find element index.
Create two JavaScript columns called “New Review” and “New Completed”.
What these things do is: check if the signed-in user’s org is included as an element in the review or completed list. If not, add it to the list. Else, remove it from the list.
The equivalent of this is a combo of split text + find element index + append array (if not exist)/remove element from array (if exist) + joined text.
Now, on the front end, create a button bar with 4 actions.
Action Name
Review Included
Completed Included
Action to Execute
Add to Review
false
can be anything
Set the “New Review” column to “Review” list
Remove from Review
true
can be anything
Set the “New Review” column to “Review” list
Add to Completed
can be anything
false
Set the “New Completed” column to “Completed” list
Remove from Completed
can be anything
true
Set the “New Completed” column to “Completed” list
Now, as this is getting super long, a big potential improvement is this case: when the user is in a “Completed” stage, setting “add to review” would also remove that org from the completed list. Vice versa for “add to completed”.
Thanks all. @ThinhDinh thank you for the detailed solution. I was hoping there was a mostly native solution, but I will dive it to this. But just to confirm: It sounds like there is no way to use the choice component to do what I’m trying to do? Does it seem like expected behavior that if you apply a filter to the choice component to limit what data from the source column is seen by the user, that when the user makes a choice, that it overwrites the data in the target column, rather than appending it as it would if the filter were not applied?
@Darren_Murphy I thought about row owners and decided it couldn’t work. My data is structured just like this
So if I have a role of Org3 for several users and I make that role a row owner of “opus” only org3 users can see opus. But I need everyone to see opus; just don’t want them to see choices in the other columns that aren’t the name of their org. The alternative of having several rows of Opus, one for each role, wouldn’t really work either. Am I missing something?
I probably need to think about this a bit more and maybe have a play around with it, but my immediate thought is that I would structure it differently.
Instead having those Review/Completed columns in the Documents table, I’d have them in the Orgs table. And instead of a Joined List of Orgs in each, I’d have a Joined List of DocumentIDs. Assuming that you have Row Owners applied to your Orgs table such that users in separate Orgs cannot see rows of Orgs they don’t belong to, then this would automatically achieve your goal.
