Concepts

Item Writing assigns Registrants to Sessions of Exams. Over time many Sessions may be created for an Exam. Each Session will have its own roster of Registrants. Some clients require that Sessions that identify a grouping of Registrants be removed from the system for confidentiality reasons. However, it is still required to keep all of the registrant responses, so that aggregated Item Statistincs can be created.

To handle this, Item Writing has Archive Sessions. When an Exam is created and Archive Session is automatically created for the Exam. Over time other Sessions will be created for the Exam. When the User deletes those Sessions, all the Registrants for those Sessions along with their response records are transferred to the Archive Session. This way the Archive Session preserves all the responses, but removes the confidential grouping information.

Item Writing supports two authentication modes, Forms and Windows.

Forms Authentication mode uses a login page to prompt users for their Login ID and password in order to access Item Writing. All users in the system are required to have a Login ID and Password setup through Security Entry.

Windows Authentication mode uses the users network credentials to validate their access to Item Writing. When navigating to the Item Writing web application, the user is prompted for their network login and password. If correct they are allowed access to the Item Writing application. All users in the system are required to have a Login ID that matches their network Login ID. No password is required to be setup for these users. Login ID is setup through Security Entry.

CE Supports two types of Item Banking. Level 1 Banking where there are multiple Exam and Item Banks and a single shared Bank for Attachments, Authors, Competencies etc. Or Level 3 Banking where there are multiple Exam and Item Banks and multiple shared Banks.

CE has many different types of objects. An object can be an Item, Exam, Candidate, Address Type, User, etc. Item Banking separates these objects into smaller groups of records. Reasons for segregating the Banks are:

• Different Clients/Departments - some records might be used only specific clients or departments. To prevent their use by other departments or clients, they are kept in separate Banks.
• Security - To limit exposure to records, Bank Security can be setup to limit User access to certain Banks.
• Legacy Data - Legacy data might be migrated into CE that users will want to keep separate from production data.
• Import Data - Data that is imported into CE users might want to keep separate until it is vetted or fully checked.

Users can have Bank access restricted:

• None - No access to the Bank.
• Browse - The user has read only rights to the Bank. Meaning they can view records and maintenance pages but cannot create new records, expire records or make any changes to records.
• Full - The user has full rights to the Bank, meaning they can view records, create new records, expire records or update existing records.

Regardless of Bank Level 1 or Bank Level 3 Item Banking, certain object types are always Shared. When an object type is Shared it means, regardless of Bank Security, Users can access and maintain records. It also means regardless of what Bank the user has selected to work with, these object type records are avaialable to work with. Shared object types are found on the System menu and are: Address Type, Bank, Competency Type,Contact Type, Country, Country Region, Email Type, Ethnicity, Gender, Item Meta Type, Reference Type, Security Roles and Security Users.

The difference between Level 1 Banks and Level 3 Banks is in the data that is separated by Item Banking. Object records are either Shared or they are Banked. When an object type is Shared it means, regardless of Bank Security, Users can access and maintain records. When an object type is Banked it means that the data is segregated by Bank and it is affected by Bank Security.

In a Level 1 Bank most object types are shared and not controlled by Item Banking. Only Item and Exam type records are affected by Item Banking.

In a Level 3 Bank most object types are Item Banked. Even though some object types are shared across multiple Exam/Item Banks, they are not shared throughout all Banks. Each Exam/Item Bank (at level 3) has a parent bank at level 2 which is a shared bank. This shared bank shares all of its object records amongst all of the child Banks underneath it.

In the sample below, the Shared bank (in red) is shared by its child banks underneath it Import and Production (in orange). The Client 3 bank (in blue) is shared by its child banks underneath it Production (in green).

User Bank Security is maintained using Security Edit Banks.

In Level 1 Banking, the security is maintained for the Banks at Level 1 in the tree. User rights are managed by Bank only for the Item, Item Group, Exam and Term entry tools. All other object type data is shared and not affected by Bank Security.

In Level 3 Banking, the security is maintained for the Banks at Level 3 in the tree. The security shared data in the parent bank (Attachment, Author, Candidate, Competency, Copyright and Reference) is inherited from the Level 3 Banks. Meaning if a level 3 Bank has Full rights, then the shared parent bank at level 2 has Full rights. User rights are managed for the shared parent bank and for the Item, Item Group, Exam and Term entry tools.

Click for more on Tree controls.

Item Writing maintains many different types of object records. Examples are: Items, Exams or Candidates. These different objects have many fields to describe the data. For example Candidates have Last Name and First Name, while Items have Answer, Value and Competency. While many fields are explicitly defined, many clients require their own custom fields tracked for the various object records. As these fields are not defined within the stock Item Writing system, Item Writing uses Custom Fields to track this information.

On every Item Writing object there are custom entry screens where information that was not specifically tracked in Item Writing can be maintained. See Attachment Edit Notes and Custom, Author Edit Notes and Custom, Candidate Edit Notes and Custom, Copyright Edit Notes and Custom, Exam Edit Notes and Custom, Item Edit Text and Notes and Reference Edit Notes and Custom. These pages give the user the ability to maintain the data stored in these Custom Fields.

TDA can further customize the entry pages to have specific names for the fields (instead of Custom 01, Custom 02, …) as well as validate entries to numeric, date or selected lists of valid values.

For many object records (Item, Exam, Candidate, …) in CE, CE does not delete records (which removes them from the database), rather it expires them (meaning the records still exist, but by default they are hidden from view).

CE tracks two values per object:

• Effective Date - the date in which a record first becomes available for viewing and use. By default, all new object records have an effective date of yesterday. Meaning if a record is created on July 15th, the initial Effective Date is July 14th. Effective Dates can be set to a date in the future, delaying when a record can become available for use. For example, creating new Competencies that the user does not want available to link to Items yet.
• Expiry Date - the date in which a record is no longer available for use. By default, all new object records have an expiry date of December 31st, 2100. Effective Dates can be used to manually expire a record so that it no longer is available to work with or view. When users delete object records, the Effective Date is set to today, so that the record is no longer available to work with or view.

Expired records are not removed from the database. By the default they are not shown in entry grids. In order to view or edit these records, special filters on the gird page are used to show these records. For example, on the Attachment Entry tool there is a special filter to Include Expired Record in the grid view.

To restore or unexpired an expired record, first the user must be able to see it. So, check the Include Expired Records check box. Then, edit the record, setting the Effective Date to a date in the past and the Effective date to a date in the future and save. The expired record is no longer expired and will, by default, be visible in entry and selection grids.

CE supports two main types of items:

• Multiple Choice - where the Item has two or more options that the registrant can select from, CE supports two, four and five options Items.
• Constructed Response - where a value is stored to indicate the Registrants performance against the Item. A typical example would be an Essay Item with a maximum value of 15 points. A valid entry could be any value from 0 to 15 points. Also negative value can be entered.

CE supports record locking. Record locking is the technique of preventing multiple users from editing a record at the same time. This is to prevent inconsistent results. An example would be User 1 opens an Item to change the Competency from “A” to “B”. User 2 opens the same Item after user 2 started editing it. User 2 attempts to change the Angoff to 0.5. User 1 saves their change then User 2 saves their change. Because User 2 retrieved their data before User 1 committed their change, their screen shows the Competency as “A” instead of “B”. When User 2 saves their Item, the Competency then reverts back to “A”.

To prevent this CE locks a record the moment a user begins editing the record. Every time the user navigates to another edit page for the record or saves their work, they refresh their lock on that record. When the user starts to edit or view another record or navigates to another tool in the system or logs off the record lock is released.

When a user selects a record that is locked, a warning message appears on their screen, all of the entry controls are disabled and the Save button in hidden.

Record Locks are specific to the users session not the User ID. This means two people can log in as “Administrator” and CE will track their locks separately.

The default duration of a record lock before automatic release is 30 minutes. This is configurable in the web.config file.

There are circumstances where a user might persist their lock of a record inadvertently. These include closing their browser, instead of logging off. Having their computer shut down or having their network connection drop. In order to clear their Record Locks use the Record Lock tool.

In CE, each User has permissions (rights) to the various menu options and reports. When they log into CE, CE checks their permissions and hides menu options they have no access to or restricts their functionality on menu options they have browse permissions to.

Users can have one of three levels of permissions:

• None - No access to the menu option or report.
• Browse - The User has read only permissions to the menu option, meaning they can view records and maintenance pages, but cannot create new records, expire records or make any changes to records. The User can run the reports.
• Full - The User has full rights to the menu option, meaning they can view records, create new records, expire records or update existing records.

The User security is set on the Security Forms page. The permissions set for the User are known as Security Rights.

Roles can also be setup within CE. A Role is a set of permissions. Users can then be added as Members of the Role. When a User is a Member of the Role, they inherit all the permissions of that role.

For example a Role of “Lookup Administrator” could be setup that grants permissions to the Author, Competency, Copyright and Reference entry tools, but not the Exam or Item entry tools. Any User who is a Member of the “Lookup Administrator Role” will inherit the permissions to the Author, Competency, Copyright and Reference entry tools.

Security permissions are supersetted between the User permissions and the Role permissions conveyed by membership. As an example, there is an “Item Admin” role that has permissions to Item Entry, and “Exam Admin” role that has permissions to Exam Entry. A User who has permissions to Candidate Entry is made a member of both the “Item Admin” and “Exam Admin” Roles. The means the User now has permissions to Item Entry (from Role), Exam Entry (from Role) and Candidate Entry (form their Rights).

Security always takes the highest permission. If a User has Full permissions granted from a Role and Browse permissions granted the User receives Full permission since it is higher.

The Attachment, Item and Exam objects in Item writing track a Status and Substatus field. These fields serve three main purposes:

1. To logically group these objects together. This helps with filtering on objects when selecting them. This is more a function of the Substatus field.
2. To help track the life cycle of these objects. When objects are initially created the have a Draft/In Development Status. As the Attachment/Item/Exam is proofed, reviewed, etc. it progresses to Field Testing and ultimately Active Status.
3. To help manage linking of these objects together. Business rules are in place in the system that prevents Draft / In Development Attachments and items being linked to Active items or Exams. That way objects that are not finalized and may be pending further review are not linked to objects that are finalized.

The different objects have different Status levels. Each Status has different Substatus lists associated with it. Whenever an Exam, Item or Attachment is inactivated, the Status is automatically set to Inactive.

The Substatus values are dependant on the Status values. Each Status value has a different Substatus list associated with it. Substatuses have no impost on system business logic. Substatus lists are customized by TDA. Contact TDA for customized Substatus values.

The Track Changes feature enables Users to keep track of the changes made when editing the content in a rich text editor. Changes are tracked when e.g., applying text formatting to a text selection, entering new content, deleting existing content, etc. Additionally, on selecting a tracked change a little pop up with details about it will appear at the bottom right corner of the browser.

Further, the tracked change(s) can be accepted or rejected, either on a change by change basis or for the entire text.

The Track Changes functionality entirely relies on HTML to show, recognize and manipulate the tracked content. Upon user interaction Track Changes adds and/or modifies the HTML output with additional tags and attributes which represent the actual tracked change.

Attachments, Items, Item Groups and Exams can be reversioned.  By default, all new Attachments, Items, Item Groups and Exams are created as Version 1 with a Version 1 ID value pointing to their ID. Reversioning an object creates a copy of that object in the same Bank. The new object has a Version = Version + 1 with its Version 1 ID still pointing to the original version 1 record.

Example: Attachment “Eiffel Tower ” ID = 25, Version = 1 is reversioned. The original Attachment has 25 is Version1ID = 25 because it is the first version of the Attachment. The reversioned record will get the next available Attachment ID automatically generated by the system. For sake of this example, assume it is 201. So the new Attachment record would by ID = 201, Version = 2, Version1ID = 25. If the version 2 record is reversioned, then assume the next available ID = 320, so the new record would be ID = 320, Version = 3, Version1ID = 25.

All three versions of this Attachment are tied together by their Version1ID value being the same.

The Attachment, Item, Item Group and Exam grids by default only show the most recent version of the records. To display prior versions of the records, click the Include Prior Versions check box in the title bar.

When editing Attachments, Items, Item Groups or Exams, users can navigate to other versions of the records by using the Select Version drop down on the blue info bar on the edit page. If there is only one version of the records, the Select Version drop down is disabled.