Admin Overview
This topic lists the main procedures needed to set up a RecordsManager system. The order in which these procedures are listed serve as a rough sequential guideline of how to configure your RecordsManager system. Very often, however, you will need to move back and forth among different procedures.
System administration can be concurrent with system useYou can reconfigure the database, add new forms, change settings, and carry out other administration tasks even after users have started working with the system. Any admin changes you make will be reflected on the user side as soon as the user interacts with the system. |
Configure the RecordsManager database and the Home Page
You can start building a database from scratch or you can use RecordsManager's sample database as a starting point. The sample database is available when you first open RecordsManager. You could modify the data structure as little or as much as you like, and change the formatting to suit your preference.
The main procedures for configuring the database structure are:
The app's data structure is composed of one or more repositories. Each repository will have a hierarchy of data tables. It is within a data table that records relating to that data table are stored. For example, a Department data table will contain department records, whereas a Company data table and a Person data table will contain the records of, respectively, companies and persons. In the data table hierarchy, the Department data table could be a child of the Company data table and the parent of the Person data table. When entering data for Department records, for example, the user of the app can choose the company (from all the available companies) to which this department belongs.
When you create data tables and configure the app's data structure, it will be these kinds of relationships and linkages between database components that you will be setting up. As a result, the data structure will provide a network of relationships that enables related data to be listed and reported. For more information about data tables and data structure, see the following topics: How the App's Data Is Structured, How Data Is Stored, Repositories, and Data Tables.
|
Since each data table will contain records of a single type (say, of a Department), you must configure the fields of data table so that these suitably define the records of the data table. For example, a Person data table (in which Person records are stored) can be defined to have fields such as: FirstName, LastName, Email. You can specify various aspects of each field, such as datatype or an entry list from which the user can choose a value (useful, for example, when selecting a US state). You can also configure validation rules for individual fields and for records as a whole; this would warn users about possible errors in data entry. See the section Fields for details.
|
Data entry forms are the forms in which users will enter the record data. So you must design these for each data table so that record data can be entered into the respective data tables. Each time a user clicks the button to enter a new record for a data table, the appropriate data entry form will be displayed. that what the user will interact with. Other types of forms also server important purposes: list forms (to display record data in a custom format), report forms (to show reports with tables and/or charts generated from the data), export forms (to generate XML and CSV outputs from the available data), and email forms (for email reminders). Each data table has its own set of different forms. One major advantage of using data table-based forms is that access to each type of form can be set separately. As a result, you can design some forms to show data that only some users are authorized to see and/or edit. You can also design other forms that do not show certain data. Reports of the data in a data table are presented by using a report form of that data table. Similarly, other types of forms are used for other types of presentations. The various types of forms are described in the section Forms.
|
One or more filters can be defined on each data table. A filter restricts the display of records in a data table on the basis of some criterion (or criteria) relevant to that data table. For example, for a Contracts data table, you could create a filter that shows only contracts that expire in the current year. Such a filter would be built, for example, by checking the ExpiryDate field of records in the data table. After a filter has been created, it can be used during configuration as well as data entry, for example, to restrict lists. See the section Filters for information.
|
When users log in to the system to either enter data or retrieve information, they see a Home Page, which is their entry point into the system. Essentially, the Home Page provides access to the various data tables of the system. The Home Page Form is what an administrator uses to design the Home Page. See the section Home Page Form for information about designing the Home Page.
|
Set up system users and their roles
These procedures determine who will use the RecordsManager system and in what capacity. You should check whether the roles that are defined in the sample dataset suit your requirements. For the beginning, it might be best to use just the two predefined roles, Admin and All Users. After you become familiar with your data and its structure, the system, and your users, you can develop roles to suit your requirements.
Besides specifying which users can log in to the RecordsManager app and their respective login credentials, you must also define what access rights each user has and the role/s each will play. For example, does a user in the IT Department have access to only technology contracts—or legal contracts as well; or, is a certain user allowed to have an administrator role, which entails access to the app's configuration settings? These access rights are determined by the roles (see next step) given to each user. See the sections Users and Roles for details.
|
Create different roles according to your organization's needs. For each role, define (i) the data tables to which access is allowed, and (ii) the forms to which access is allowed and, where necessary, the type of access allowed (for example, read/write or read only), (iii) the reports to which access is allowed, (iv) whether export of data is allowed. After roles have been created, give one or more of these roles to each user (see previous step). See the sections Users and Roles for detailed information.
|
Global settings and reminder mails
At an early stage in the development process, you should have a look at what global settings for the app are available and consider how you can best use them. Reminder emails are probably best left to the end of the configuration process, but it would be useful to at least quickly look through the documentation about reminders in order to see what is involved.
The Settings page provides a number of styling, content-formatting, print formatting, and other settings that can be set for the entire app. We recommend that you go to this page and see what settings are available and how you can use them. The Image Library setting and Reminder Email settings should be noted. Also note that, when you configure certain items, such as forms, you can specify local settings and override the global settings that are defined on the Settings page. You can define global settings at any time: before database configuration, after database configuration, and even after system use has started.
|
In systems like a contract management system, it is important to take certain actions before specific dates (say, a contract renewal action before the contract expiry date). The system can automatically send reminder emails to the appropriate person or persons a given number of days before such key dates. See the section Reminder Mails for information about how to set this up.
|
Restoring the database to a previous state
You can restore your database to a state it was in at some time in the past. To do this, you must create copies of the database at suitable intervals. Each of these is a checkpoint. You can select any checkpoint to restore the database to the state it was in at the time the checkpoint was created. See Database Restore Checkpoints for information.
Using alternative RecordsManager databases
You can use an alternative RecordsManager database for your RecordsManager system. Create this .sqlite database in RecordsManager as outlined above and copy it to the same folder as the original RecordsManager database. On your MobileTogether Server, this folder is named production_data and is located in the same folder as the RecordsManager solution.
RM solution
production_data
|
|-- RM databases
Note that the RecordsManager databases are not in the same folder as the RM solution, but are one level farther in the filepath, inside the production_data folder. Also note that the relative path production_data in the RecordsManager solution will be resolved relative to the Server side solution's working directory, which is defined in the Settings tab of MobileTogether Server.
After you have (i) deployed the RecordsManager solution to MobileTogether Server and (ii) saved the alternative SQLite database/s in the correct folder (see above), you can create a link in MobileTogether Server to start RecordsManager with the alternative DB. Do this as follows:
1.In MobileTogether Server, go to the Workflows tab and locate the original RecordsManager solution in the container where it has been deployed and select its check box (located to the left of the solution's name)
2.Select Create Link at the bottom of the page (to create a link to the solution).
3.Give the link to the alternative solution a name.
4.Give the sqlitedb parameter a value that is the name of the alternative database, for example, as in the screenshot above, RecordsManager-GB.sqlite.
5.Specify the container in which the link should be saved.
6.Click Create Link.
Once the link has been created, users can click it to start RecordsManager with the alternative DB.
| Note: | If, after a link has been created, you remove the sqlitedb parameter or change its value in the dialog above, then you must also remove the solution's persistent data in order to switch to the new DB. You can remove a solution's persistent data in MobileTogether Server by going to the Workflows tab and clicking the Clear button in the solution's Persistent data column. |
RecordsManager documentation on the Altova website
After you have set up the database and the users of the database, administrators and users of the system can be directed to the Altova RecordsManager documentation, available at the following Altova website locations:
•Documentation for administrators (includes information about DB configuration, data entry, and system use): https://www.altova.com/manual/AltovaRecordsManager/altovarmadmin/index.html
•Documentation for users (includes information about data entry and system use): https://www.altova.com/manual/AltovaRecordsManager/altovarmuser/index.html