Checklists (Classic)

Standard Treeview path: CMiC Field > Site Management > Checklists

Checklists types are defined and maintained in the Checklist Maintenance screen in Local Tables (standard Treeview path: CMiC Field > File Maintenance > Local Tables > Checklist Maintenance).

Checklists of any of these defined types can then be created. Some features of checklists are outlined below.

  1. The Checklist Status bar/status field is used to show un-submitted/submitted checklist.

  2. The [Submit] button allows users to submit the completed checklist. If it is incomplete, validation errors will be highlighted.

  1. When a checklist is submitted, the Status changes from ‘Pending’ to ‘Submitted’.

  2. The [Save] and [Save Draft] buttons will only validate the mandatory Date field in the header. [Save] will return the checklist in View mode even though it might be incomplete and [Save Draft] will return the record in Edit mode.

  3. Field security can be applied to the [Submit] button on any defined checklist type.

  4. Users can create/link an issue from/to a checklist item.

Example of Issues and Links created for Checklist Item

The checklist item is shown in the Related Objects tab.

Example of Checklist Item shown in the Related Objects tab of the Issue

Project-Specific Checklists

Checklists can also be differentiated into system-level and project-specific. This can be achieved by using the ‘Assign to Project’ checkbox in the Checklist Maintenance screen (standard Treeview path: CMiC Field > File Maintenance > Local Tables > Checklist Maintenance):

When the checkbox is checked, the following message is displayed:

When the assignment is carried out, the words ‘Project-Specific’ are appended to the checklist name:

Field security can be applied to the ‘Assign to Project’ checkbox:

Other features of project-specific checklists

  1. Project-specific checklists are based on the same mask ID as the non-project-specific checklists.

  2. Project-specific checklists are only available for use on the Treeview menu of the current project.

  3. Field security exists for the [Edit] button for each checklist type, to prevent editing by some users, if desired:

Example:

Defined checklist type = Grounds Upkeep

Prior to applying field security to the EDIT button, it is visible:

After applying field security, the [Edit] button is not visible:

Once checklist records are created for a particular checklist type, if the field security on the [Edit] button in the checklist is set to ‘Hidden’, it can’t be changed back to being visible unless all the checklist records under that checklist type are first deleted.

The ‘Assigned to Project’ checkbox is also disabled from update. These precautions prevent any updating of the checklist type layout while records already exist for that type, thereby preventing data inconsistency errors.

Checking the ‘Show Only Project-Specific Checklists’ checkbox in PM System Options allows users to see only project-specific checklists on the Treeview menu:

Standard Treeview path: CMiC Field > File Maintenance > Project System Options – General tab

The user should refresh the Treeview menu in order to see changes when assigning/un-assigning Checklists to/from the project.

Related Objects – Tab

Standard Treeview path: CMiC Field > Site Management > Checklists – Related Objects

The Related Objects tab allows checklists to be linked to other PM objects including other checklist types.

Field security can be applied to the Related Objects tab.

Locking Checklists

Checklists can be locked in the same way as daily journals. The locking setup is defined in the Locking tab of PM Systems Options:

Standard Treeview path: CMiC Field > File Maintenance > Project System Options – Locking tab

Only users with the ‘Admin’ flag checked on their CMiC Field security role (standard Treeview path: CMiC Field > Security > Role Maintenance) can edit a locked checklist.

Rules Governing Checklists

Below is an outline of the rules regarding security and editing of checklists.

  • User can edit user’s own [pending checklist] or [submitted + not locked] without having Edit privilege

  • User with Edit privilege and Admin flag checked on user’s role can edit any checklist

  • User with Edit privilege and without Admin flag checked on user’s role can edit any non-locked checklist

  • User can submit checklist if user can edit it (based on previous three rules) and unrestricted Field Security for Submit button