Copy table (or copy page with tables) should respect filters

[joost_mineur]

Dear Codans (@coda_hq)

The following is not really a bug, but it can be such a big problem, that I feel your attention is required.

For my doc, I have the copy option disabled, which works great and it is absolutely required to secure my document. I also use the locking options to their fullest extend and I also use a lot of filters. With these 3 options, I can make sure my users see what they should see and, more importantly, hide what they should not see.

I am aware of the fact that these options are not meant for absolute (data) security, but they go a long way and if the doc is setup properly, it works pretty good.

Unfortunately, there are a couple of things that can compromise this badly. Sometime last year, a lot of ‘improvements’ where made when copying tables or pages. When copying (within the doc itself, but in particular when copying to another doc, an option box appears allowing for making a view of the table (within the same doc) or asking whether you want to copy to blank tables with only the table headers, copy to table(s) with only the visible rows or copy to table(s) with all rows - visible and invisible (filtered). This last option has me seriously worried, because a user copying a filtered table from a locked page gets, in his private copy, access to all rows when the filters are cleared.

In my opinion a copy of a table from a locked page should go without these options and only copy visible rows (or perhaps don’t allow to make a copy at all).

I really hope you can address this issue, because I am sure that many makers are not aware of this.

There are two other very important issues that compromise docs in unexpected ways.

1. the canvas column does not respect locking settings, with the result that anyone with acces to a canvas cell, regardless of which table the canvas cell belongs to, has direct access to ALL tables in the document by typing “/table” . Filters, if any, can be cleared, user roles can be altered, financial data can be changed, etc. etc. I can’t imagine that it was meant to work that way.

2. when looking at a filtered sub table (beautiful feature), for example showing the line items of a proposal, you only see the line items belonging to the current proposal (if setup properly). But when you open a modal of one of those subtable line items, you can scroll through all line item in this subtable (by using the little counter at the bottom of the modal). I have discussed this with support, but I am not sure if or when this will be fixed. There is a workaround, but it not very convenient and it hurts the proper working of other parts of (my) document.

There have been some rumors about a future feature allowing for more fine grained page authorization(s), but if the things mentioned in this post are not addressed, they are not going to be of much help.

I am aware Coda doesn’t shared it’s roadmap, but I hope you will make an exception for the things discussed in this posting, because (for many docs) they are critical.

To all Coda users reading this post: if you agree with the above, please like this post so Codans will recognize the urgency.

Greetings, Joost

[Evan_Price1]

I will just add to this, filtering out data so certain users do not have access to it does not even work to prevent non-technical users for two reasons,

• When the doc is loading (which can be 30 seconds or more for large docs) all the rows are visible and can be opened
• When using the global search all rows are searchable regardless of filtering.

I am aware that the advice on this forum is that filtering does not offer any security, but I did not realize how it effectively offers no security!

[joost_mineur]

Hello @Evan_Price1 ,

Thank you for your reply.

Based on questions I have seen in this community (and other places), I am convinced that too many doc makers are not aware of all these things, so I feel this is a good place to discuss these things.

Even though Coda is not a database, most documents have (data)tables and I hope Coda will address some of these issues over time.

A couple things come to mind:

1. make it (for the docmaker) optional to turn off global search in each document (searching from the doc list might overrule that, but that one does not search in tables, but only in the canvas of all pages of all docs (including hidden pages)).

2. don’t show tables until they are fully loaded (and filtered)

These 2 would be a big help to keep data a bit more private.

More fine grained (either standard or as optional settings for doc makers):

1. Global search should respect filters (like the table search box does)
2. Global search should not search on hidden pages (and perhaps this should apply to searching from the doc list as well).

The point is not just security, it also prevents for individual rows to be shown (found) out of context, like sub table rows that are meaningless without their top record. There are enough search possibilities doc makers can build themselves if they want their users to find something by searching through sub tables, but showing the result in the proper context (like searching for line items, but showing the top record upon finding something.

I hope more doc makers wil share their feelings about this subject.

And it is not like I can’t use Coda the way it is, but it is restricting the way I use it and with whom I can share my document. It also forces me to put some tables in a separate document, but this limits the relationships I can set between rows and makes me duplicate all kinds of lookup tables, with the extra risk of keeping these lookup tables synced. And yes, I know there is cross-doc, but that is not realtime and has it’s own set of problems.

Greetings, Joost

[Evan_Price1]

Thanks for laying it out in detail, I think you are absolutely correct that many would not be aware of these limitations.
I for one use Coda very extensively, and yet I came to find out about them from colleagues inadvertently circumventing them and letting me know - not ideal!
I say this always with the caveat that I’m not a developer and software development always seems a lot more involved than it appears from the outside…but these don’t intuitively feel like difficult issues to solve and would really help with some form of granular permissions and data/content management until more comprehensive solutions are developed (which I really hope are in the pipeline!?)