Users have site identifiers that identifies the site (a.k.a. division, territory) that they belong to. A user's site restricts the user to manage (i.e., view, add, edit and delete, based on module based permissions) information that belong to the same site that he or she is member of. The site information is stored in several tables in the 'site_id' column in the database and a siteId attribute in the classes. A database record with a null site_id and object with siteId is -1 refer to items for which site information is not recorded. For information on how sites affect user permissions on various objects refer to the section on Territories.

Contact and User (access table) Site Dependency

The access table has a column site_id to store the site that a user belongs to. As you may be aware, all users, and by inference, the records in the access table relate to a contact record. It is mandatory that the value of the site_id in the access table be the same as the value of the site_id in the corresponding contact table. Keeping the the values consistant requires additional maintenance because it reduces the way the tables are normalized, however, this decision has been taken keeping in mind several performance and response time issues.

Contact and Account (organization table) Site Dependency

The Organization table has a column site_id to store the site that an account belongs to. By inference, the records in the database that relate to the organization table belong to the same site as the organization. It is mandatory that the value of the site_id of account contacts in the contact table be the same as the value of the site_id in the corresponding organization table. Keeping the the values consistant requires additional maintenance because it reduces the way the tables are normalized, however, this decision has been taken keeping in mind several performance and response time issues.

Site information in other tables

Several other tables like usergroups, actionplan, etc have a site_id. For e.g., the user_group table stores site_id and this information is used to restrict the membership of the group, the actionplan table has a site_id that restricts whether it can be associated with a specific, ticket, account or lead (contact). If new tables that you may add require that site information be stored, we urge think of two options, (1) if the site information can be inferred from a related organization, contact or access table do not add a site_id column to the table unless performance (i.e., response time due to additional joins) degrades performance, (2) if the table is used to store administrative data (e.g., usergroups, categories, etc.,) that does not relate to relavant tables that store site information, add the site_id column.

Checking user access permissions on Site related information

User objects are cached in the application and this cached information is compared against all required records using the overloaded isRecordAccessPermitted(...)1, 2 method in the CFSModule.java class. To insure that the validation is secure it is neccessary that the object not be validated against a visible siteId parameter in the URL. This is in addition to UI validations that prevent site related business logic from being violated. This additional check is required as data in ConcourseSuite CRM can be made persistant using means other than the UI, such as the XML-RPC API.