1. 

   jjr, Member

   Hi,

   I was wondering if there has been any previous discussion or any future intent to add a new user class to MyDBR that would allow creation of reports but not full admin rights?

   As far as I can tell, there are only two user classes - user and admin, so that if I want to allow a user to create reports I have to give them full admin rights. For some of my users this is a potential issue for both security and the visibility of other elements that should be hidden from the user.

   Thanks and regards,

   Justin.
2. 

   myDBR Team, Key Master

   Justin,
   in order to create reports, user would pretty much have full access rights to the database. One could limit the access to the UI, but the database items would be still visible.

   What are the items you would want to hide from a report writer?

   --
   myDBR Team
3. 

   jjr, Member

   Hi,

   Thanks for your reply.
   Off the top of my head, things that would be great to be hidden would include:
   - Administration of users and groups; MyDBR admin, etc - actually anything in the right hand sidebar for Admin Tools, except for "Add Report", "Add Folder", "SQL Editor".
   - Reports not part of their allocated user group

   I admit that the SQL editor means they could technically get at some of the database admin data. This and the previous requirement could perhaps be solved by having a configuration for this new user class which says which tables a user group can build reports out of from the database. MyDBR could also limit the reports visible to the user group for this new user class, like is done for normal users (and unlike admins which can see all).

   Does this sound like a reasonable approach or have I missed something?

   As ever, thanks for your help and responses.

   Kind regards,

   Justin.
4. 

   jjr, Member

   Hi MyDBR team,

   Just wondering if you had any more thoughts on this? I am very willing to try any other suggestions for ways to achieve this (i.e. having some kind of way to let a new type of user create reports but not have full access to admin rights).

   I'm also happy to tweak the UI myself if you think that this is the right way to go and you can point me in the right direction please.

   In general it seems like such a new user class might be a useful feature to add - perhaps along the lines of my previous post, but I admit that this might have some knock-on development implications unless you can think of a simpler way to do it.

   Any thoughts welcome,

   Thanks and kind regards,

   Justin.
5. 

   myDBR Team, Key Master

   Justin,
   restricting access to UI is easy. The challenge is that user who has reporting rights has access to the same data via directly accessing the database. What would need to be done, is to create another user for these users. The challenge with this would be that then the report procedures would be created under different user and different databases treat this bit differently and it adds complexity of how routines are accessed.

   If restricting admin user's UI access would be enough, you can take a look at the admin_restrictions entry in the defaults.php.

   --
   myDBR Team
6. 

   jjr, Member

   Hi,
   Thanks for your reply.
   Ok, I will try and play with the admin user's UI restrictions - this looks promising in that I can do this per user.
   I can see the admin_restrictions entry in the defaults.php file, but I can't find any documentation about the syntax to use.
   Please can you point me in the right direction - I'd need to suppress all the "Settings:" options in the right sidebar of the UI.
   Thanks,
   Justin.
7. 

   myDBR Team, Key Master

   Justin,
   the restricted_actions-array lists the actions which the restrictions apply. The value for each action is the 'a'-parameter for the admin action. For example for 'Environment settings' it is 'settings'.

   Then you can either restrict the actions for individual users by adding the username to the limited_admins-array or by listing the full admins in the full_admins-array (in which case for all other admins the restrictions apply).

   Please note that this is purely for the UI, an admin user can request most of the information from the database (apart from info stored into the files).

   --
   myDBR Team
8. 

   jjr, Member

   Hi,
   Thanks again for your reply.
   I've got this working (and can see that it would be somewhat complex to create a new user for different admin rights to do this properly), so I will have a think about whether this UI fix is suitable for our needs.
   I suspect that the open nature of the SQL editor might create issues, but some of these can be overcome by restricting the 'mydbr' user on the database correctly.
   Thanks again,
   Justin.
9. 

   myDBR Team, Key Master

   Justin,
   what is it that you are actually trying to protect from?

   --
   myDBR Team

Reply

You must log in to post.