Granting access of specific user to specific (multiple) docs

Granting access of specific user to specific (multiple) docs - database

I'm building a small project with database. I have a user table which has two columns, user_id and name, The second table stores the id and name of some documents: it also has two columns doc_id and doc_name. I want to grant access of specific user to specific (multiple) docs.
For example:
user1 can access doc_2 and doc_3 Only.
user2 can access doc_1 and doc_2 Only and so on.
Users and forms keep changing (eg. after some time i need to add a new doc, and add access to existing or new user to that new doc).
Do i need to change database design? (for example add a column in docs to store name of each user who can access it? ) If this is so, can you tell me what changes i should do?
OR
Is it possible to do by creating views? In this case, do i still need to change the database design? If this is the case, can you tell me an example view please? In this case, will i need to create view for each user? For example if there are 100 users, i will need to create 100 views?

You need a third table (I'll call it user_doc). You need 2 main columns; user_id and doc_id.
You then insert one row for each document and user combo that has access permissions.
If their user_id doesn't appear in the user_doc table with the relvelant doc_id, they don't have permission.
A sample query to get a list of all docs a specific user has access to:
SELECT doc_id FROM user_doc WHERE user_id = #UserId
or to find all users with access to a specific doc:
SELECT user_id FROM user_doc WHERE doc_id = #DocId

You need to have a PERMISSIONS table with relationship between Users & Documents. The columns could be PERMISSIONS_ID,USER_ID (Refer User), DOC_ID (Refer Document). Every time access has to be given to a user for a document this table needs to be populated.

Related

Restricting the content of a table

Im trying hard to find a way to restrict the access of a user to a particular table. Im working with views now but i cant create what i want...and i dont know if its possible.
Now, what it accomplish was to limit all access to a table..and create a view with the content the user should be able to see...but its not what a want, really.
What i was think:
When i logon with the user XXX, it should be able to visualize the database X_DB...and the table X_TABLE...
BUT when this user selects this table..he only will see the content i defined previously...not the entire content of the table.
I was able to select it into a view..but im cannot make all of it part of one process...
Is that possible?
Thank you

Given that you have 20 databases, one per each client, add your client as a user to just the database you want them to access.
If you want to consolidate all of your databses to a single database, then I suggest that you add "Client" table containing clientId (primary key) and clientName fields, and then modifying the rest of your schema by adding foreign key fields and relationships so that the other data is related to the proper client. Then you can easily provide access to data to clients based on their clientId in conjunction with views and stored procedures.

Creation of views based on roles in salesforce

If i assign two users to two roles,let's say CSM and sales rep. If I am the sales rep and I go to the campaigns tab and click on the Direct mail view to view records of type Direct mail,I will get a result set. Now if the CSM user tries to access the same view by clicking on the Direct mail view again he should be able to access a different set i.e different set of records of the type direct mail. How do I achieve this. This is of top priority in my task now.Thanks in advance!!

You could create two views with the same name then make them each visible to the appropriate set of users.
You need to create two Views, one that corresponds to each of the groups. For simplicity, you can name the Views the same thing so long as the Unique Name is, obviously, unique. I would recommend something like Direct_Mail_Sales and Direct_Mail_CSM for the unique names.
Set up the criteria for the views however you'd like.
When you get to the bottom of the configuration for each view, make sure to select "Visible to certain groups of users" and select the corresponding Role from the list. This will make sure that the view is only visible to the appropriate role.
Since The views have the same name, it will appear to the end user to be the same view.

Compare two views in salesforce

I am looking for a way to compare two views in salesforce. I want to create a visual force page that lets a user select two views associated with the Account object and show all the accounts that appear on both views.
I am struggling pretty hard here, I can't figure out how to get the results from the views, but I am hoping there is a way to get all accounts that match the filters for each view.
Here is my SOQL query:
Select Id, Name, Owner.Name FROM Account WHERE
Id IN ( SELECT AccountId FROM Opportunity WHERE RecordTypeId = :RecordType1ID AND StageName IN :StageOneList )
AND Id IN ( SELECT AccountId FROM Opportunity WHERE RecordTypeId = :RecordType2ID AND StageName IN :StageTwoList )
This is the basis of the VF page I have made so far. It is possible to filter the Account with Account Owner and a drop down list from province. The idea is, many people in the organization have already created views with the accounts filtered as they need it. Instead of including every possible account field as a filter, I would like a drop down list of the active users views associated with Account, and then they can select Opportunity 1 and Opportunity 2 and have a list of Accounts matching.

I assume you mean views as in the available views in the dropdown box on a standard tab for an object? If so I don't believe you can query the results from them directly although you can query the Account object using a SOQL statement where you provide the filter.
My suggestion would be either create a set VF page that has 2 drop downs to switch the SOQL query that is used to return the list of accounts being displayed (would mean you have a set of predetermined views and updates to them require code updates) or give more details of your use case and we may be able to provide other suggestions.

It sounds like you just need to compare the results of the filters here. My suggestion would be that you're really trying to do something that should be done with reports, not with views.

Put two enhancedList components on the page.

Restrict access to certain rows in table based on user

In SQL Server, how do I restrict access to certain rows (hide data) in tables based on the users identity?

The basic / normal way to do this would be:
prevent that user (or group) from accessing the base table
define a view on top of that table that shows only the rows these users are supposed to see
give those users SELECT permission on the view

How to model this one-to-one relation?

I have several entities which respresent different types of users who need to be able to log in to a particular system. Additionally, they have different types of information associated with them.
For example: a "general user", which has an e-mail address and "admin user", which has a workstation number (note that this a hypothetical case). Both entities also share common properties like first name, surname, address and telephone number. Finally, they naturally need to have a (unique) user name and a password to log in.
In the application, the user just has to fill in his user name and password, and the functionality of the application changes slightly according to the type of the user. You can imagine that the username needs to be unique for this work.
How should I model this effectively?
I can't just create two tables, because then I can't force a unique constaint on the user name.
I also can't put them all in just one table, because they have different types of specific information associated to them.
I think I might need 3 seperate tables, one for "users" (with user name and password), one for the "general users" and another one for the "admin users", but how would the relations between these work? Or is there another solution?
(By the way, the target DBMS is MySQL, so I don't think generalization is supported in the database system itself).

Your 3 tables approach seems Ok.
In users table have only ID, username, password,usertype.
In general users table have ID, UserID (from users table), other fields.
Same thing for admin users.
Usertype field will tell you from what table to search for additional info
if(usertype==admin)
select * from admins where userid=:id;
else
select * from general where userid=:id;

Two tables. USERS with user names, first, last, etc. ROLES with roles, and a link back to the user name (or user id or whatever). Put a unique constraint on the user name. Put workstation nbr, email, phone, whatever else you need, in the user table. Put 2 columns in the ROLES table -- USERID and ROLE.

You should decide how much specific information is being stored (or likely to be stored in the future) and make the decision based on that. If there are only a handful of fields for each user type then using a single table is alright.
USERS table (name, type, email, password, genfield1, genfield2, adminfield1, adminfield2)
Make sure to include the type (don't assume because some of the fields particular to that user are filled in that the user is of that type) field. Any queries will just need to include the "AND usertype = " clause.
If there are many fields or rules associated with each type then your idea of three tables is the best.
USERS table (ID, type, name, password)
GENUSERS (ID, genfield1, genfield2)
ADMINUSERS(ID, adminfield1, adminfield2)
The constraints between IDs on the table are all you need (and the main USERS table keeps the IDs unique). Works very well in most situations but reports that include both types of users with their specific fields have to be done in two parts (unioned SQL or subqueries or multiple left joins).

You can solve it with one 'general' users table containing the information thats available for all users and 1 table for every specific user type. In your example you will then need 3 tables.
Users: This table holds only information shared between all usertypes, ie. UserId, Name, Address, etc.
GeneralUsers: This table 'extends' the Users table by providing a foreing key UserId that references the Users table. In addition, information specific to general users are held here, fx. EmailAddress, etc.
AdminUsers: As with GeneralUsers, this table also 'extends' the Users table by providing a foreign key UserId referencing the Users table. In addition information specific to admin users are held here, fx. WorkstationId, etc.
With this approach you can add additional 'specializations' if the need arises by simply adding new tables that 'extends' the Users table using a foreign key reference. You can also create several levels of specialization. If for example admin users are general users as well as admin users then AdminUsers could 'extend' GeneralUsers instead of Users simply by using a foreing key to GeneralUsers instead of Users.
When you need to retreive data from this model you need to which type of user to query. If for example you need to query a GeneralUser you will need something similar to:
SELECT * FROM GeneralUsers
LEFT JOIN Users ON GeneralUsers.UserId = Users.UserId
Or if querying an admin user
SELECT * FROM AdminUsers
LEFT JOIN Users ON AdminUsers.UserId = Users.UserId
If you have additional levels of specialization, for example by having admin users also being general users you just join your way back.
SELECT * FROM AdminUsers
LEFT JOIN GeneralUsers ON AdminUsers.UserId = GeneralUsers.UserId
LEFT JOIN Users ON GeneralUsers.UsersId = Users.UserId

I most definitely would not do a model where you have separate tables as in GeneralUser, AdminUser and ReadOnlyUser.
In database design, a good rule of thumb is "Down beats across". Instead of multiple tables (one for each type), I would create a SystemUsers table, and a Roles table and define a join table to put SystemUsers in Roles. Also, I would define individual roles.
This way, a user can be added to and removed from multiple roles.
A role can have multiple permissions, which can be modified at any time.
Joins to other places do not need a GeneralUserId, AdminUserId and ReadOnlyUserId column - just a SystemUserId column.
This is very similar to the ASP.Net role based security model.
alt text http://img52.imageshack.us/img52/2861/rolebasedsecurity.jpg