hi bront,

ive struggled with many of the same issues in our modules. it is fairly easy to make a'security through obscurity' solution, where you do something like only exposing a filtered query over a raw table (essentially your suggestion); however, because a given folder within LabKey is generally either all-or-none for read permissions (with study datasets being an exception) that generally means the user could read the raw data if they could find it, either unintentionally (like being shown the wrong UI), or intentionally (like digging through schema browser or the wrong kind of webpart).

there are 2 better options, i think:

1) Linked Schemas. We had this feature added to support the scenario where you have a folder with raw data (like a core facility that runs an instrument), and another group of users who needs to see a subset of the raw data (like a client who views data filtered on userId). in this scenario you have one container with the raw data. In a second container you go to schema browser and created a linked schema. you define the source container and also which queries to expose. If you combined this with your original idea of making a query that filters on UserId, then I think you have a genuinely secure solution. Linked Schemas can be defined from XML, and we have a few examples checked in. See employeeData.template.xml in the EHRComplianceDB modules (or ctl+shift+n, then template.xml in intellij).

2) because you saw you're writing a java module, i'll throw this answer out there: when I need to solve this problem now I virtually always make a custom UserSchema and modify there. You can make your own custom permission/role, which will then appear in the normal folder permissions UI. For example, I have a lot of scenarios where I create a 'Data Admin' type role, which is used to enforce the ability to edit specific reference tables. See VariantDBUserSchema for one of the simplest examples. CustomPermissionsTable is something I wrote for this you're welcome to try. You add an additional permission that will be tested for each of the standard actions (Read, Insert, Update, Delete). I would use this scenario instead of option 1 when you have data that most naturally lives within a single container, but you have a class of users that should have elevated edit permissions relative to others. in the case of a lab, you might have lots of people entering/editing the data; however, you only want a few people able to modify reference tables or lists of allowable values.

-ben