I have the usual situation wherein I am creating projects to represent different labs, but I need to expose ALL of the underlying labs' data to an over-arching Admin role (without the admin having to navigate into the separate projects).
- main project (Admin)
- lab1
- lab2
- lab3
I've been experimenting with the Demo module and have exposed the Person table via registerProvider, so that the labs can access and manipulate the data via JavaScript, but I need some help to expand on that.
I want to maintain the current security level for the labs (so they can only access and modify their data), but expose ALL of the data to an Administrative role where the data can be viewed and modified via JavaScript.
Any suggestions on how to set up this schema or examples in other modules would be most welcome.
Many thanks,
bront
e.g.,
DefaultSchema.registerProvider("demo", new DefaultSchema.SchemaProvider(this)
{
public QuerySchema createSchema(final DefaultSchema schema, Module module)
{
DbSchema dbSchema = DbSchema.get("demo");
return QueryService.get().createSimpleUserSchema(dbSchema.getQuerySchemaName(), null, schema.getUser(), schema.getContainer(), dbSchema);
}
}); |
|
Jon (LabKey DevOps) responded: |
2015-04-16 11:49 |
Hi Bront,
You should be able to do this by using a non-standard ContainerFilter.
Although it isn't exposed as an option in the UI, you can add a URL parameter that shows data from all containers that the user has access to.
If you do the following, you should see all the folders:
1. Go to a container-specific data grid.
2. Click on Views -> Folder Filter -> Current folder and subfolders
3. Then edit the URL to replace the "CurrentAndSubfolders" value with "AllFolders" to expose all of the containers.
Give this a try and let us know if this works for you.
Regards,
Jon |
|
bront responded: |
2015-04-16 15:10 |
Jon,
That's fantastic. I have never noticed that command before (in fact, I had to take a few minutes to find it).
So, I should be able to leverage this via the JavaScript API, correct? I will test.
I may leave this thread open for a couple of days until I get this sorted.
Many thanks,
bront |
|
Jon (LabKey DevOps) responded: |
2015-04-16 15:11 |
Hi Bront,
That is absolutely correct. We'll leave this thread open as you test this out in the meantime.
Regards,
Jon |
|
Jon (LabKey DevOps) responded: |
2015-04-21 13:09 |
Hi Bront,
Just following up with you on this issue. Did the solution work out for you?
Regards,
Jon |
|
bront responded: |
2015-04-21 13:28 |
Jon,
You couldn't have written at a better time. I am currently working on this.
Yes, I think this is going to work perfectly for us.
However, I just upgraded to 15.1, and I am running into a problem. Do you mind if I hijack this thread in a slightly different direction?
Suddenly, or so it seems, the following simple bit of code is returning either "Cannot read property of GetProxy' or just a straight 404. I am in my custom module. The tables are visible in the schema. Any idea what could be going on?
x = Ext4.create('Ext4.data.Store', {
schemaName: 'mySchema',
queryName: 'myTable',
autoLoad: true
});
So… a few possibly related questions...
1. How should I import ext4 into my asp?
resources.add(ClientDependency.fromPath("clientapi/ext4"));
-or-
resources.add(ClientDependency.fromPath("Ext4"));
2. For stores, should I be using:
Ext4.create('Ext4.data.Store...
-or-
Ext4.create('LABKEY.ext4.data.Store...
3. Also, I am still exposing the tables via the code in the first section… I have since added mySchema.xml file under resources/schema. It's very simple and based on the demo module. Is this required? Does the .xml file give me finer control? Better security?
Many thanks,
bront |
|
bront responded: |
2015-04-21 13:40 |
OK…
Looks like :
resources.add(ClientDependency.fromPath("clientapi/ext4"));
and
x = Ext4.create('LABKEY.ext4.data.Store', {
schemaName: 'mySchema',
queryName: 'myTable',
autoLoad:true
});
… are now working. Shall I assume this is correct?
The question about the use of the mySchema.xml file still stands. I'd appreciate any help or any resources that might clarify what that file can/should do.
Again, many thanks,
bront |
|
Jon (LabKey DevOps) responded: |
2015-04-22 22:22 |
Hi Bront,
The Schema XML file isn't required, but highly recommended. The file allows the platform to use canonical casing for the column names. Typically a database will often throw away the original upper/lower case name, so things like splitting CamelCase columns into individual words (e.g. OneTwoThree appears as One Two Three with spaces in-between). Additionally, we do require the Schema XML for our own modules (especially for automated tests). 3rd Party Modules might not be as restrictive to need it, but we still recommend using it since it also allows things like basic metadata to be utilized (e.g. Date Formatting, Column Labeling, etc).
Regards,
Jon |
|
bront responded: |
2015-04-23 09:52 |
Jon,
Excellent. Thanks for that succinct overview of the schema XML file. I will work on implementing it.
bront |
|
|
|