Hi, Codans. I’ve spent many hours on this and can’t find solution.
I am trying to setup performance reviews process for my company.
I have a view that filters performance reviews by the current User(). Each performance has a few feedback and self-assessment forms (subtables with feedback summaries per each user). Those subtables are also generated from individual reviews.
Data flow: DB Individual Reviews → DB Reviews Summary Subtable - > DB Performance Reviews
I tried different formulas to filter subtables:
Subtable is relational column with custom formula: [DB Reviews Summary Subtable].Filter([Teammate]=thisRow.ReviewOwner)
or [DB Peer Reviews on Leaders Summary].Filter([DB Performance Reviews].Contains(thisRow))
Unfortunately, If user opens the row with his feedback inside his main performance review form he is able to navigate to other rows with feedbacks for others.
This is due to Detailed view (open row) has pagination that give users access to the assessments and reviews of all the company. Is there a way to limit this behaviour?
Here is the main form where user can open the row in subtable with his feedback:
Here is the pagination that ignores filtering rules:
The only workaround I have found is to use formula that checks if user is manager and if true it shows reviews filtered by the thisRow person. If user is not a manager each row of subtable will have current user() reviews. In last case pagination always show the same reviews even if there hundreds of rows.
Any ideas what I am doing wrong? Or it’s a bug?
Hi @Yuriy_Mykhasyak ,
Coda as it is today does not fit this purpose in one doc. User can access the performances via multiple entries.
Via the search box it is even easier to access all reviews.
Each user her own doc and linking this doc to a master doc via sync pages or cross doc is maybe the best way forward.
I am sorry to bring the bad news.
Thanks for the reply Christiaan.
I am trying to protect main DB with filter that checks access permissions; if user is not an admin, he will see only his rows:
If([DB Employees].Filter(Admin=true).Name.Contains(User()), true, thisRow.[Review Owner]=User())
Will this protect against search for other reviews?
For me, it looks like a coda bug that pagination ignores filtering rules. I hope coda can at least provide an option to turn off pagination in the same way we can disable comments.
Creating individual docs for each new employee looks like management nightmare. And I am not sure out HR wants to learn how to create and manage cross docs.
For now, I use the workaround to generate different rows in a subtable based on user role, but this is very suboptimal.
maybe you can ask one of the other users to use the search bar while typing the name of an other user.
Creating individual docs for each new employee looks like management nightmare
I agree, it is. Coda should make us more productive, not less productive
Unfortunately, you are correct, just tested it and global search returns the review form for the user I have no access to in the main DB.
That means there is no privacy in Coda at all. I didn’t expect that. It’s kind of a blocker for us, and after spending so much effort on setting up performance management, its shocking to learn that Coda is not production-ready for such a basic use case.
Do you think there is any chance for us to get a fix on this in the near future?
@Yuriy_Mykhasyak , I did not notice any sign that these issues do matter to the coda team in the short term (before June 2024). Nevertheless I am quite confident that one day this will be solved, maybe in an unexpected manner. I am rather optimistic because any logic in a doc that requires a bit of ‘non exposure’ is broken by the current behavior.
Thanks for your reply, Christiaan!
BTW, here is a guideline from the Coda Cross-Doc documentation: “As a best practice, keep your source table unfiltered and then apply filters to your Cross-Doc sync tables as desired.” So the full table will be synced to a new document and searchable in a new document.
That means Cross-Doc is not a solution for privacy, or I missed something.
haha, yes if you bring your cross doc unfiltered in your target table, you import the problem. This is not a solution at all. What you have in mind is not possible today in Coda. I wrote about it here. Coda will take some time, realize it when users for this reason move to other platforms and fix it. They basically have no choice.