Hi Martin,

Your assessment is correct. Permissions are typically on the project and folder level in addition to roles.

At this time, the only other security that is a little more granular is tied to Study, specifically securing datasets. So unless your custom module is designed to emulate the Study module, the only way to prevent anyone from accessing those specific tables is to deny them any access to that folder or project, even as a reader.

For more information on LabKey security, please visit the following links:

https://www.labkey.org/wiki/home/Documentation/page.view?name=security
https://www.labkey.org/wiki/home/Documentation/page.view?name=configuringPerms
https://www.labkey.org/wiki/home/Documentation/page.view?name=studySecurity

Regards,

Jon

Hi, Jon.
Thank you for your answer

So I was thinking....i can filter the displayed values via custom webparts (using Javascript API, eg. QueryWebPart).
This way users see only the rows I want them to see.

And the only real problem is that users are able to click their way to the exposed table (via lookup in query webpart which redirects them to details about the specific item -> and then all they need to do is click "Show grid"

(or simply type the URL - which can be guessed even if I didn't let them know it exists)

both ways redirect them to page with URL like this:
http://localhost:8080/labkey/query/FOLDER_PATH/executeQuery.view?schemaName=coredatamodule&query.queryName=SampleTypes

with whole table data exposed. this seems unfortunate to me.
can't this be made forbidden? (access to this url)

I need them to be able to read (or submit) information from the table, but also want to be able to select which information exactly. There should be no way for them to access the whole table.

I intend to provide manipulation with tables ONLY via custom webparts.

Am i aiming for the impossible?

Best regards,
Martin

Hi Martin,

So if you need to hide the table, beyond making a custom schema implementation in Java, this might potentially work for your needs:

1. Create one folder with all the schemas in it and make them private.
2. Create another folder which exposes selected schemas via linked schemas (See documentation - https://www.labkey.org/wiki/home/Documentation/page.view?name=filterSchema).

The end result is that the application would be built in the second folder while the hidden schemas in the background would be hidden in the first folder.

Will this work for you instead?

Regards,

Jon

Thank you very much, Jon.

It's a good idea, unfortunately, after some studying I think linked schemas wouldn't work for me. If I understood correctly, this way I'll need to manually create a new linked schema for each new client (because filters cannot be generated dynamically) and as far as I know, you cannot create linked schemas programmatically.

The other problem is that some information (table rows) might be available to let's say 3 clients.
I use many-to-many binding tables to keep track of these relations and display only the rows I calculate should be displayed.
I cannot see a way to integrate this with filters.


I'm interested in custom schema implementation in Java, as you mentioned.
Could you tell me something more about this? Point me to the right direction? (I am new to interacting with Labkey via Java)

My idea is that, let's say I can add a column "Folder" to each table and simulate destinations that rows should "belong" to.
When displaying whole table (under the default URL mentioned in previous message), i will first filter table based on user permissions and this way he will only see rows belonging to folders he has at least Reader permissions in.

Or, absolutely sufficient would be to somehow block displaying the entire table under the URL - it's funny but this is really all i need:). Or to dynamically define filters to displaying that table.
Or block that URL (at least to non-admins) somehow or hide all columns from displaying after navigating to that URL.

Are those options possible within a single Java module or do I need to temper with LabKey source code?

Thanks again,
Martin

Hello,

Can you say a little more about your scenario? You basically want row-level control over read access, based on createdBy? If so, here's a trick we've combined with linked schemas to accomplish something like that. In our case I needed more access than just the single user, so this example is one step more complicated:

- we have a table of data with a column for 'project' (think of this like the client) and a createdby field
- we have a second table with 2 columns: 'user/group' and 'project'. this table has rows that list which user(s) or group(s) have access to each project.

It sounds like your source table has a createdby column, mapping back to a Labkey userId? In our case, createdBy, plus a subselect between the project and the table above will produce a whitelist of user/group IDs with access to that row. If you only care about the createdBy user having access, this whole second table thing can be ignored.

In Labkey SQL, there is an isMemberOf(int) function. this is the key. wrap your data table in a query like:

select * from myTable t WHERE isMemberOf(t.createdby)

or

select * from myTable t WHERE isMemberOf(t.createdby) OR (select count(*) from mappingTable m WHERE m.project = t.project and isMemberOf(m.userid)) > 0

then share this query, which will only ever have the rows belonging to the current user. you can tweak the WHERE clause to match the behavior you want.

Note: if you're willing to learn, a custom java TableInfo would let you introduce dynamic filters as well.

-Ben

Hi, Ben.

Your solution is pretty clever and functional, thank you very much:)
There is just one more thing related I can't make work.

I have Folder A, hidden from clients. Module with defined schema containing all the tables is activated only in this Folder A.

Folder B is for clients. Here I created linked schema with queries written in a fashion similar to your suggestion.
So...If I want to read my custom tables in Folder B, no problem, rows get filtered and clients see only what they are supposed to.

If I want clients to also insert data to my custom tables from Folder B (to Folder A), I thought "Submitter" role to Folder A would be sufficient. However, this doesn't work. They need "submitter" + "reader" on Folder A to be able to insertRows. (and giving them reader permissions to Folder A would ruin all my effort:)

Isn't this bug?

I remember that Submitter role worked OK for inserting to lists. Is there a difference when inserting to module-defined schema?
(this module is activated only in Folder A and nowhere else)

Martin

Hi Martin,

Is your user just submitting or also reading the data it just created as well?

Regards,

Jon

yes, he might submit and read from the same table, but the permissions are not based on what he submitted, but basically on a group membership (permission given by administrator)

(he also should be able to read data he created, because these rows will be tagged with the group he belongs to)

martin

Hi Martin,

A group membership would still boil down to the permissions given to that group.

So if you have a user who you need to be a Submitter on Folder A and they're expected to also read the data there as well, Reader access to Folder A would have to exist somewhere for that user - either individually or as apart of a group.

Also, with some roles (e.g. Author and Submitter), the role will need to be supported by the code that's supplying each specific kind of data. This is because it's often somewhat complicated to know exactly what data is "owned" by each user.

It does seem like that the Submitter permissions would be reasonably supported for a module-defined schema, but a fair amount of new feature coding would be involved to make this happen.

Regards,

Jon