How it works

The IJC schema items (data trees, entities, fields etc.) are defined in the IJC_SCHEMA table in the schema's database. Each schema item has it's own row in this table. When IJC connects to a schema it reads all the items for that schema from it's IJC_SCHEMA table and loads them for access for each user. Some organisations might wish to limit access to some items based upon each user's role within the company.

Some items can be hidden from particular users. In fact, it is better to think of it as allowing particular items to be visible to the most relevant users of those objects to reduce over all complexity. You can do this by defining a role which you want to use for such a purpose. Lets assume we want to create a role named 'ROLE_CHEMIST' which we can then assign to all of our chemist users and a role named 'ROLE_BIOLOGIST' for our Biologist users. We can then make certain data trees visible only to Chemists and Biologists users as appropriate. When the setup is complete IJC will only make relevant data trees accessible to users who have the roles that allow them access. Lets see how to do this.

1. Creating the roles

In order to access the relevant system tables, this must currently be done directly in the database. Connect to the RDBMS with your favourite tool. See the Using the database explorer tip from the user guide if you want to use the Database Explorer that is provided in IJC for this.

The role(s) must then be inserted into the IJC_AUTHORITIES table. Do this like this:

You can create and name, any number of extra roles you want, but you must not delete or modify the 6 existing standard IJC roles: ROLE_USER, ROLE_EDIT_DATA, ROLE_EDIT_SCHEMA, ROLE_ADMIN , ROLE_EXPORT_DATA and ROLE_EDIT_SCRIPT. . The RANK property affects the order in the 'User management' interface that the roles appear in IJC. Before you set this value for your new role, you should check the existing values that are already in use in the table and not duplicate.

2. Associating the role to the user

You should have at least one IJC user available for each role. Whilst connected as admin and if you have not already done so, create a new user 'ChemistA' and 'BiologistA'. If you have not done so, you will first need to set up a security policy. Once complete, open the 'Security settings' in the 'Schema' section of the schema editor and look at the 'User management' tab. Click on the 'Add User...' button and you should see you ROLE_CHEMIST/ROLE_BIOLOGIST roles that you can assign to one of your users. Add or edit your users as appropriate and give them the new roles in addition to ROLE_USER (but not ROLE_EDIT_SCHEMA). Once the users are created, assign the role ROLE_CHEMIST to ChemistA and ROLE_BIOLOGIST to BiologistA by selecting update settings and then ticking the relevant role for the user.

3. Associating the role to the schema item

Now create 3 data trees in the schema for this example - this can be done directly in IJC schema editor (r-click,new). Initially we are going to restrict access to two data trees to our chemists and one to our Biologist, then we will share one data tree between each. First identify the appropriate data trees in the IJC_SCHEMA table. This query will help:

Make a note of the SCHEMA_ID and the ITEM_ID for two datatrees that you wish to filter for chemist only access. Now insert two rows into the IJC_SCHEMA_AUTHORITIES table, using the syntax below, that associates ROLE_CHEMIST with those particular data trees (of course you will substitute your values for <schema_id> and <item_id>):

Now login as the user ChemistA who has been assigned the role ROLE_CHEMIST. All 3 data trees are visible, 2 are assigned and one which is currently unassigned defaults to visible. Now login as the user BiologistA who has been assigned the role ROLE_BIOLOGIST. Only 1 data tree is visible which is currently unassigned. The ROLE_CHEMIST has been associated with 2 data trees hence any user without that role i.e. BiologistA will only see the 1 unassigned data tree.

Now insert one row into the IJC_SCHEMA_AUTHORITIES table, using the syntax below, that associates ROLE_BIOLOGIST with the currently unassigned data tree (of course you will substitute your values for <schema_id> and <item_id>):

Now login as the user ChemistA who has been assigned the role ROLE_CHEMIST. Only 2 data trees are visible which are the 2 assigned to ROLE CHEMIST. Now login as the user BiologistA who has been assigned the role ROLE_BIOLOGIST. Only 1 data tree is visible which is the 1 now assigned to ROLE_BIOLOGIST.

Now insert one row into the IJC_SCHEMA_AUTHORITIES table, using the syntax below, that associates ROLE_BIOLOGIST with one of the data trees that is also assigned to ROLE_CHEMIST (of course you will substitute your values for <schema_id> and <item_id>):

Now login as the user ChemistA who has been assigned the role ROLE_CHEMIST. Only 2 data trees are visible which are the 2 assigned to ROLE CHEMIST. Now login as the user BiologistA who has been assigned the role ROLE_BIOLOGIST. Only 2 data tree is visible which are the 2 now assigned to ROLE_BIOLOGIST. Effectively the Chemist and Biologist have a private data tree each and share access to a 'public' data tree.

More advanced issues

Filtering data trees is the most obvious application of this functionality. However, any item in the IJC_SCHEMA can potentially be filtered using this mechanism, except for the schema item itself (see above). For instance, individual entities and fields can be filtered if you need. But be cautious if you work at this level, as data trees are dependent on the entities they use and entities are dependent on some of the fields that they own. For instance, its probably a bad idea to filter fields that are involved in relationships, are primary keys or whose values are required for inserting new rows. And filtering out relationships is probably a very bad idea indeed! In some rare cases some of these can be sensible things to do, but not usually. Do test carefully. Its quite easy to filter out a field and have a data tree disappear because it is dependent on the field for some reason! If you make a mistake just delete the offending row from the IJC_SCHEMA_AUTHORITIES table.

The above description assumes you are using database based security. If you are using a different approach such as LDAP then most of this still applies. You need to perform steps 2 and 3, but as the actual roles are defined in LDAP then step 1 is not necessary. However the roles you use (obtained from LDAP) still need to be configured according to steps 2 and 3 for this to work.

Problems?

If you have any questions or comment then please report them to the IJC forum .