Firstly, apologies if there is already an entry in the forum pertaining to this subject.
I am trying to design a single database, that will be used by a number of different ‘sites’.
I would ideally like the user to be able to select a site at startup to basically put the database into a ‘site state’ and then be able to see views with that site’s information; create forms that have that site already entered etc.
I have considered a number of options: There will be approximately 5 views that each site will want to see their information in:
Create a copy of each view for each site - then have a navigator page to select the site. That’s a lot of views.
Dynamic view selection - so in each of the 5 main views, have a button that the user selects their site for
There are a number of issues around this. I have read other posts that say if you play around with dynamic selection conditions, it can give other users strange results when they too are using the database.
I want to try and avoid creating dedicated views for each separate site, as this db could potentially be required nationwide.
My notes experience is currently limited, so bear with me.
Any suggestions/things I need to keep in mind would be GREATLY appreciated :o)
Yes - creating roles for each site does sound like a good plan. I’m not certain how the views would work in this case - could I put hard-coded selection criteria that showed different documents depending on the role (site) ticked?
Could you assign one of 5 roles to each user (i.e. through 5 access groups) and put those roles in reader fields in the documents ?
That way you only need one set of views, but users will only see records for the site that their role belongs to.
I believe that what Graham is suggesting is that you use one set of views for all of the sites and what each group of users sees would be limited by their role (which would be in the reader’s field for the documents pertaining to their site. An [Admin] role would be in all reader’s fields to give admistrators access to all of the documents.
For example, I have built, in the past, a website database where regional managers needed the ability to build content into the database for sales documents pertaining to offices in their region. They had the ability to compose these documents and had, on the form, a field called SalesOffices, which was a readers field. SalesOffices is a checkbox field that contains a list of all of the roles for SalesOffices in that region (the region is selected by the manager and is prepended when checking the role so region1 roles would be region1Office1, region1Office2, etc. This provides the sales managers a way to specify which office can see the documents.
The trick is to put one role into a Readers field in the document. The view would hold all records, but users won’t be able to see the records that belong to the other roles. In effect, each group would see different documents in the same view.