System Models 

The gadget spec URL could not be found

Whenever a new application is created by the developer using the Studio, the system automatically creates a set of system models and places them in the system folder that is accesible from the root application folder. The automatically generated system models are Global, Company, User, AppRole, RoleSubscription, UserLoginModel, UserChanges, UploadStats, ProcessInstance, ProcessAudit, Version, Activity, Metadata and ReportPreference. Each of these system models serves a specific purpose. 

This model is used to maintain the application specific configuration details such as application name, application logo, authentication, mail configuration, log level etc. The system will automatically create an instance for this model. It's like a singleton, so only one instances must be present in this model for an application. Hence, the developers should not create a user interface to allow the end users to create instances for this model. However, they can design user interfaces to modify the instance created by the system. 

When a user logs in for the first time after an application has been deployed, a first time login screen will be displayed. The logged-in user can update the application name or upload an application logo using this screen. In the coming release, the super admin or an application admin will be able to update the application specific configuration details using the "settings" administrator option.

This model is used to maintain the company details such as company name etc. This model is a child to the "Global" model. In the current version, a new company cannot be created using a user interface. The system automatically creates the required company details based on the domain name in the mail id used for login. Once a new company instance is created, then the user can update company details such as company name using a form. For example, if the mail id used for login is admin@orangescape.com, then an instance in the "Company" model will be created automatically with the following values for the model parameters: 

SheetName: Company_orangescape.com

SheetId: orangescape.com

This model is used to maintain the user details along with the user privileges. Some of the key parameters in this model are:

IsAdmin - This boolean parameter can be set to true to provide the super admin privileges to a user. A super admin will have access to perform all of the administrative tasks such as application administration, user administration, process administration and data administration.

Disable - This boolean parameter can be set to true to make a user inactive. The users can use this parameter to filter either active or inactive users.

ApplicationAdministration - This boolean parameter can be set to true to provide the application administration privileges to a user. However, it must be noted that the application administration functionality hasn't been implemented yet.

UserAdministration - This boolean parameter can be set to true to provide user administration privileges to a user. A user administrator will be able to create users, manage users, manage role subscriptions and bulk upload users.

DataAdministration - This boolean parameter can be set to true to provide data administration privileges to a user. A data administrator will be able to use the data viewer and data uploader to view the data stored in the database and perform uploads directly.

ProcessAdministation - This boolean parameter can be set to true to provide the process administration privileges to a user. However, it must be noted that the process administration functionality hasn't been implemented yet.

Every model will have two user model references (CreatedBy and ModifiedBy), which can be used to identify the user who created an instance and the user who updated the instance. This implies that every single model in the application is a child of the user model. The queue (inbox) created for any model is similar to a parent/child form where the user model is the parent and the transaction model for which the queue is created is the child model. Hence, to create filters for the queue, a parameter can be created in the user model with a list of valid filter values. 

This model is used to maintain the application roles. This model is a child to the "Global" model. Application roles need not be created manually by the user. These roles are automatically created by the system based on the role assignments in the workflows implemented using the process design perspective.

Application roles are nothing but user groups. The system allows to group users and specify privileges at group level. This makes it easier to maintain privileges. The users belonging to a role acquire the privileges specified for a role.

This model is used to maintain role subscriptions. This model is a child to the "User" and "AppRole" model. There are two different ways to maintain role subscriptions: either assign a role to the user (Manage Users screen) or a user to the role (Manage Roles screen). User administrators can maintain role subscriptions using the built-in user management screens.

It also serves another important purpose -- an instance must be created in the "RoleSubscription" model for every new user that is created. Only the "PrimaryUser" reference parameter needs to be set to the userid of the new user being created.

This model is used to audit the login/logout information of the users. This model is a child model to the "User" model. Every time a user logs in, a new Instance will be created in this model. The last login details will also be maintained in the "User" model. 

Every model has a one-to-one relationship with the "ProcessInstance" model. This model is used to maintain the actitivity details of an instance. Whenever the work (instance) is forwared from the current activity to the next activity in a workflow, the new activity details are updated in the process instance. The process instance can be used to determine the current activity of an instance.

Some of the key attributes maintained in the "ProcessInstance" model are:

InstanceAssignedTo - This parameter can be used to determine the user/users belonging to a role who are responsible for completing the activity. 

RootProcess - This parameter can be used to determine the root process for any activity in the workflow. The root process for an activity will be maintained in the "RootProcess" parameter for every instance in this model; unless the instance is for the root process itself, in which case this parameter will be empty.

ParentProcess - This parameter can be used to determine the parent process for an activity in the workflow. A workflow that has an OR activity branch has multiple paths for the work to be completed. A workflow that has an AND activity branch has multiple paths that must be taken for the work to be completed. In the above two cases, whenever the system encounters such branching activities i.e. identifies two or more paths for a work to be completed, a new instance will be created in the ProcessInstance model. Each branch's starting activity will be maintained as the parent process for every activity in that branch.

PendingProcess - This parameter can be used to determine the current activities that are pending for user action.

This model has one-to-many relationship with the "ProcessInstance" model. The "ProcessAudit" model is used to maintain the audit infomartion for every transition in the workflow. Every time the work is forwarded from one activity to another activity in the workflow, an instance is created in this model and audit infomation is written to it.

This model can be used to maintain different versions of the application. It has to be noted that this funThe objective of this model is to have more than one version of the applicatin. But its not implemented so as of now its no use.

This model is used to maintain the report preferences such as charts, themes, dimensions, measures and filters for the aggregate reports created by the users.

These models are used for user management. Whenever a new user is to be created, a draft is first created in the "UserChanges" model and then the user details are saved in the "User" model. Similarly, whenever the details of an existing user is to be edited, a draft is first created in the "UserChanges" model and then the user details are saved in the "User" model. This provides the user with the option to discard the changes, if required. The history of all the changes made to any user instance is available in the "UserChanges" model.

The built-in user management functionality has a bulk upload screen for CSV user import. "UploadStats" model is used to maintain the statistics for every user upload.