Yes, I know nothing in Coda is truly undiscoverable. But there’s a big difference in needing skills to find data and anyone can stumble upon it by accident. Crossdoc wasn’t an option when we started the build because cross doc was extremely unreliable. Even now, rebuilding with crossdoc we are having issues with syncs not occurring for several hours and Coda support can’t explain why. Sync says it occurs, but data isn’t changing. And we all know if something breaks in crossdoc, you have to start over and reimport the table and then lose all buttons. So it’s expensive to build docs that rely on crossdoc heavily. It has been improving, but still flawed. So you have to weigh the pros and cons. When we started build, client needed something that worked and using filters to hide data and using hidden pages and where the search bar was located (that no one ever even noticed it) got the job done. Now, geez all someone has to do is type in the right word for the column holding the payroll data and they can see everyone’s pay rates. And search isn’t working right (in my opinion). For example, I keep a table with software keys. I wanted to search for the key and I typed it into search. It was some string of letters and numbers, no spaces. Coda returned tons of data none of which was the key. For example let’s say the key was 1 BZQ23495SIY then coda returned everything with SI or si. Really? That was so not helpful. There was so much junk in the search that even if my result were in that list I couldn’t see it. I would expect Coda to ONLY return something that contained the entire “word”. I can set up webhooks but in this case, the client collects a very long list of data for one record so building that webhook is a pain. Currently rebuilding their entire doc into multiple docs for different users. But keeping my fingers crossed because so far, every doc built for them with crossdoc winds up with some bizarre issue. One doc wouldn’t sync data to one table for an entire day. Why? Was set to hourly sync and I manually told it to sync at least a dozen times. It said it synced seconds ago, but it wouldn’t give data. Seems there was some Coda bug and our doc just so happened to have all the things necessary to have that bug. I have two docs syncing from the same table. Both set up the same day. One of the syncs in one doc works, the other sync in the other doc to the same source table wouldn’t sync at all. Deleted it several times and re-added it and it finally synced. Took two days to get it to work because I’d give it hours to do it’s first sync just to make sure before deleting it. If cross doc sync is going to just stop for no reason that would disable the client’s business. It needs to work reliably and if it’s set to 1 hour sync, it needs to sync every hour and it needs to COMPLETE the sync by actually sending the data not just saying it did.
So…yeah, I know the correct way to set up the docs, but there’s still some buggy issues with cross doc so at times, we build docs knowing data isn’t completely unobtainable, but relying on our clients lack of knowledge on HOW to get to the hidden data. Would it pass certain regulations? No, but does it need to in my case? Also no.
Just a quick tip: You can use the User() function with an IF statement to conditionally show data based on the logged‑in user. For example, if you want to show the wage recipient’s name and salary only when the logged‑in user’s name matches the record’s employee name, you could use a formula like this: If(thisRow.[Employee Name] = User().name, thisRow.[Salary], “”)
This formula checks whether the current row’s employee name matches the logged‑in user’s name and, if so, displays the salary; otherwise, it shows an empty string. You then simply have to hide the help column in each layout. You could do the same for the user name. This way, only “empty entries” could be found via the search.
A “deeper” option would be to use a canvas columns instead of text (Name) or number columns (salary), which for each row uses the formula “If(thisRow.[Employee Name] = User().name, [Salary] ”)” (or name) and then enter the number/name directly into the formula instead of an auxiliary column. Unlike user-based filters, which users can bypass using the search function, this dynamic display is tied directly to the logged-in user, and cannot be circumvented. Perhaps at the most by extremely visceral users who know how to rewrite the source code of the page using the Discover function.
Yes, that would be easy. But unfortunately, this client’s requirements won’t allow something that simple. We have to allow certain records to be visible by certain people but only until something changes, then those are only visible by one person. So there are complicated filters that determine whether or not a record is visible. And then on the tables with invoicing information or payroll information, there are filters that hide those rows from users based on whether or not they are in a “group”. Then pages and tables are locked appropriately. But it seems the new search bar completely ignores data that is filtered out and the user’s can see all the data just by searching.
I cannot stress enough the new search bar is NOT WANTED by many of us freelance Coda builders. We want to be able to turn it off. Or at the very least it should RESPECT filters, hidden tables, hidden pages, etc. It does none of those things.
I know that is an old thread, but as somebody who worked in IT system audits (ISACA), I have no idea what justification would apply to leaving the option to display the hidden documents up to the SEARCHER unless (and only when) the searcher is also the OWNER of the those hidden files. I hope that it I am just misunderstanding what I am reading above.
Misunderstanding, underthinking, overthinking… it’s just wrong user logic for many of the Coda makers and probably good part of the IT world. There are ways to solve it but don’t expect to be solved. At least Coda doesn’t have intention on sharing how or when.
So even calling them “hidden files” is misleading if not idiotic. Practically speaking, those files are stored in what can be called a “Community Repository” for everybody to reuse them. I understand eatables can be fun but snacking on them at Coda on the clock is excessive.
@Ben_Lieber1 is there any update on this? I really appreciate the effort to improve doc discoverability, but the issue with hidden docs is still a challenge. The last update on this was back in January, is there any plan to address it further?
