I have a database that groups contracts by Market and Type. We want to deploy only sections of the database to the general users. Is there a way to create a new database and use views to select the proper data from the original database? They want a lot of different ways and hidden views was not working for me (probably lack of knowledge on my part). I’d like a way to present specific data to users. Thanks
Subject: Can you access a different database?
The context of a view is only within the view’s database. By this, I mean that you can select only documents from within the same database as the view. You can reference views in one database from another database by embedding it in a form, for example, but this does not solve your problem.
If you want to show only certain documents to users, you should consider one or both of the following techniques:
Readers fields.
Categorized views.
Both of these topics are covered in detail in Designer help.
Subject: RE: Can you access a different database?
Thanks for the reply. Ok, I already use the categorized view; market then type, both categorized. I’d like to restrict so sales reps can only see the type=sales for their market. There are 21 markets and 8 types in the database. Reader fields may work, but we have thousands of docs that would need to be updated. What am I missing?
Subject: RE: Can you access a different database?
Readers fields is how I would go.
Yes, you’re going to have to “data scrub” but to me if you want to restrict who see’s what it’s the only way to go since smarter people could create their own views. Use the View > Go To to see things you don’t want them to see.
Subject: RE: Can you access a different database?
I have limited designer skills…can you use a groups in the reader field? Can the reader field be hidden when the document is opened for display, but show when open for edit?Thanks
Subject: RE: Can you access a different database?
Last question first, yes you can have a readers field that is hidden when the document is displayed:
Rather than put “groups and names” in your Readers field, it’s best to put roles. That is, if a person has the “Marketing” role they should be allowed to see any documents where the Readers field has Marketing (the actual role will have square brakets around it, so it will be “[Marketing]”
I would advise you make a copy of the database and try this on a development server if it’s your first time doing it.
Here is what you want to do:
First you’re going to set-up your ACL before we actually touch the documents.
(1) In the ACL go to the Roles and create a Role for each Classification you will need. E.g. Marketing, Sales, Management. Also create a role called Admin (or DBADmin) so anyone with this role can see everything in the DB.
(2) After you’ve create the roles, then work through ACL groups and names and assign the role that person or group should have (you can have more than one)
(3) If you’re replicating the DB onto other servers make sure the servers have the role Admin
(4) Also go into the Advance tab and make sure enforce consistent ACL is in checked.
Now that you’ve setup the ACL - you can set-up the documents
On your form, on a blank line at the end of the form (or at the top) for the documents create a field called DocReaders (it can have any name ).
The Type is Readers and make sure you check off that it can have multiple values.
On the hide tab - check the HIde if True and set the value @True (i.e. always) [For testing you might want skip this step)
I would make it a computed field
The Next Question is to determine WHO should be able to see any document. Maybe you have a keyword field people select. Based on it’s value that should set the role.
If you’re luck it’s a 1x1 relations with your roles. Marketing means it should have the role [Marketing], Sales then [Sales], etc. Of course you want to make sure that this keyword field cannot be left blank.
You calculation could be (“[”+keywordfield+“]”):“[Admin]”
The last part “[Admin]” is to make sure at they very least those with the Admin role can see the documents.
Save the form - create some new documents and see Look at the document properties to see if they have the right roles.
Finally you need to datascrub any existing documents as they won’t have the Readers field yet and you don’t want to have to open every document in your database manually.
option 1 create an agent and it has @Command([ToolsRefreshSelectedDocs]); in it.
option 2 - create an agent with a bit more smarts like:
@if(Form = “theFormWeChanged”; “”; @return(“”) );
@if(@IsAvailable(DocReaders); @return(“”); “”)
Field DocReaders := (Code you have in your DocReaders Field)
The Second agent makes sure we only update the required documents and those which do NOT have a DocReaders Field.
Select all your documents and use which ever agent you like.
Test the document security. If all works as expected then repeat and apply to production.