Hi
We have a G/L database (although this might relate to other databases too) and need to restrict access by user to specific categories of G/L accounts.
This will be accounts allocated to these users as they are responsible for the cost.
Other users will have no access to any accounts and some to all accounts.
How might I go about this? Is there a setting for this in the User Profile?
Hi @StuartH,
I think you are after the permissions on a dimension. Which are setup within burger menu Administration / Databases / Select your database Name / Users (Which is a tab)
Then in there, look to the immediate left of the Default Period selected for a user. There is a little Padlock icon. Pressing that, lets you select a dimension - in your case, G/L Accounts dimension which I am hoping is a dimension?, then for that user, select which accounts you allow them to see by settings up an “Equals to” rule, selecting the accounts from the […] button list.
I use this method for our G/L database. Then it restricts all the values down to that selected list of accounts for that user.
It’s a little bit of a pain, but I just got the accounts department to setup a spreadsheet of the names along the top and the accounts down the left column, then put a X in the cells where those names are allowed those accounts. They maintain that sheet, and if there are changes, they email me over the spreadsheet.
Maybe in a future enhancement, Phocas might give us a way to Sync this kind of spreadsheet to use as an Input to a list of security permissions like this one. Although the G/L is a specific case where this kind of updating is a bit of a pain, especially when there are loads of users and accounts to allow permissions to… hmm 
More of Rich’s ramblings, sorry
Back on topic, the users who need all accounts, you of course don’t need to bother with the Padlock permissions, only the few users who are only allowed certain accounts.
I also restrict some people from seeing data about salaries by selected “Not Equal” to type rule, against certain expense codes. Hope this leads you down the road you are after and not up the garden path? 
Warm regards,
Richard
Perfect, this is what I hoped was there. Permissions like this are always a pain and time consuming to set up and maintain but as you say, important for a GL database.
Glad you can do dynamic filters though as presumably therefore I could also do ranges.
I have two columns added to my GL table in our ERP system, one for Accountable and one for Responsible. The fields contains people who own the cost in those codes.
These show as dimensions so as I update a GL account to be assigned to a person it should automatically show in their report so I should get away with just filtering for their initials.
In the other database we need this for the user is a Sales Person who needs to see only their customers. I would therefore filter for their Sales Team or their Sales Person Code. Once set up it shouldn’t need changing unless they moved team.
From what you’re refering too about an Sync, I agree an import would be useful but maybe tie it to a “Role” based system where you can identify someones job (e.g. Sales Person) and that role has specific access privaleges.
Great point on being able to import a list for managing access. I would call that “data driven security”.
You might already have those restrictions set up in your ERP and you don’t want to have security configured in two places.
Just to expand on this a bit, you can use a couple of variables in these restrictions. You can use either {{user:Territory}} or {{user:Group}}. This allows you to filter the DB based on the values of those fields on the user. This can be useful in some scenarios. For instance, I just added a bunch of new users (salespeople). Each of these salespeople needed to be restricted to their own sales ID. After importing these new users from a CSV, I could have manually set these restrictions up, but that would have been a pain. When I did the import, I imported their Sales ID into the Territory field on each user. Then I just did bulk update for these users, and set a restriction on the Sales ID field to {{user:Territory}}. So two quick steps, import, then bulk update, and all these people were setup with the appropriate restrictions.
Another case would be when this same restriction applies across multiple databases. If this person’s restriction value changes for whatever reason (in our case, if they move to a new location, they sales ID may change), you would either need to update each database with the new values, or using these variables, you can update the value once, and the new restriction applies across all the database where this restriction was setup.
Also, if you were to clone a user to setup a new user, if you have the value set in one or more database, you would need to update each of the restrictions. But if you use the variable, you can just update the value once when you clone the user.
Hopefully that all makes sense.
I’m interested in this angle Aaron, but really no idea what fields you’re referring to when you say Group & Territory?
When you setup a user, you can define a group and territory for the user. They’re over on the right hand side of the “User” tab when editing a user.
Both of these fields are ones that can be imported when you import users from a CSV file as well.
Ah, interesting, i’ll explore this with my IT team.