TeamDesk Knowledge Base & Support

Kirill Bondar  Staff  3/17/2010 4:36:54 AM

Good idea if you need to enable 3 tables out of 15. Might be bad idea if you need to enable 14 of 15 tables.

By the way, priviliges are stacked. If you are disabling table's view access there is no need to mess with the views.

walhhorn 3/17/2010 10:49:53 AM

Kirill,

I see your point. Perhaps the cleaner solution is to prompt the admin to set permissions whenever creating a new role or creating a new table. This would ensure that the admin is immediately aware of the security implications of their action and to make appropriate choices at that moment. The system could present the admin with four consolidated choices: (1) all on, (2) all off, (3) specify per table (and list all permissions for all tables), (4) specify per role.

Rick Cogley 12/11/2010 5:43:14 AM

In preparation for using the public user, I added a role to our db, with its 50-odd tables. Since the role defaults to permissive permissions, now I need to select every Table, and set Allow View = None, Allow Modify = None, Allow Add = No, and Allow Delete = None.

It would be good if, when adding a role, you could default it to no access in anything, for cases when you purposefully want the role to be rather restricted. Then you just go and specify where you want the role to access, rather than the opposite.

Regards,
Rick

Kirill Bondar  Staff  12/24/2010 12:07:23 PM

Merged with:
397 - No Access Role

gerardo garcia 12/24/2010 12:17:30 PM

The thing is that from the security stand-point, is safer to have no access when a table is created and have to grant access, rather than have all access open when a new table is created and have to restrict access, which makes more probable human error.

Kirill Bondar  Staff  11/22/2011 9:54:10 AM

Role now has "Table Access Default" switch - either "Full Access", "Read Only" or "No Access".

When new role is created, this switch controls access rights that will be assigned to a new role in all existing tables.
When new table is created, access rights for each role are set according to a role's switch.

"Full Access" is self-explanatory;
"Read Only" disables add/modify/delete and useful for Guest-like roles.
"No Access" might be useful for various "public access" roles where you need control access rights precisely and "restrict" is safest default.

Rick Cogley 11/23/2011 2:23:30 AM

Thank you very much!

gerardo garcia 11/23/2011 11:38:37 AM

Real time saver, Thanks!

Philipp Matuschka (MMB) 11/24/2011 9:09:26 AM

This is good functionality. It could perhaps be enhanced by also providing the reverse feature, i.e that tables have default access rules when a new role is added and then a fourth choice on the role "as per table defaults". Just an idea.

Kirill Bondar  Staff  11/24/2011 10:40:02 AM

Adding new role does not enable or disable existing user's access to some object - the role itself is merely a label for a set of security settings. You can set up a role, assign "default" access rights and copy this template role wherever you need those defaults - this approach could be used to implement "No Access" defaults as well.

To our opinion adding the role is not a big problem. Much bigger problem was the addition of the new table as it was enabled by default for all roles.

We are using TeamDesk internally for various tasks. One task, for example, is to provide the list of alerts for other TeamDesk applications. The list is queried via an API, the account to query the data has quite limited access to an application. The application serves other purposes as well and everytime we add new table to it we have to remember to restrict access for alert reader.

Kirill Bondar  Staff  11/24/2011 10:49:21 AM

By the way - setting table's View access to "No Access" (or "false" via Custom Formula option - these two are identical) effectively prevents all other operations including API's Create/Update/Upsert.

If you want to enable, say, modification without allowing to view the data (the only scenario you may need to do something like this is an API access) you can set up table's view access as constant expression that evaluates to false: 42=0 for example.