Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
master_page [2017/01/10 16:06] 127.0.0.1 external edit |
master_page [2017/03/16 11:00] (current) steveclarke [Main Menu] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Concepts ====== | + | ====== Master Page ====== |
- | FIXME concept of versioning version fields, version navigation, object life cycles | + | The Item Writing application consists of a master page with a header bar shared on all pages. The header bar appears at the top of the page and consists of a logo, selected [[bank_select_level_1|Bank]] and [[exam_entry|Exam]], a user menu (for maintaining passwords and logging out) and the main menu for the application. |
- | FIXME Status and Status rules (interaction of objects, status life cycle) | + | {{:mastertitle.png?600|}} |
- | FIXME Glossary for Expiry Effective Expiry Dates and not deleting records | + | ==== User Menu ==== |
+ | The user menu in the top right of the page is where the user logs out and maintains their password. | ||
- | FIXME Authentication modes and impact - Under support and installation | + | {{:masteruser.png?600|}} |
- | FIXME web.config discussion - Under support and installation | + | === Logging Out === |
+ | When a user has finished working with Item Writing it is important to logout for several reasons. | ||
+ | * Security - Logging out prevents another person with access to your computer from having access to Item Writing data. | ||
+ | * Resources - Logging out releases all recourses used by the user at the time out and makes them available to other system users. Merely closing the browser does not reclaim the resources until scheduled web server processes are run. | ||
+ | * Record Locking - Logging out releases all [[concepts#record locking|record locks]] of the user. When a record is locked it prevents other users from maintaining the records. Users with valid permissions may use [[record_lock|Record Lock]] to clear user locks. | ||
- | FIXME concept Roles vs Users and how inherited rights work. | + | {{:menulogout.png?200|}} |
- | FIXME Custom fields TDA Customization etc. | + | === Change Password === |
+ | On systems that are using [[concepts# Authentication Modes|Forms Authentication]], users are required to have passwords setup. See [[security_edit_user_general|Security Edit User]]. The user may maintain their password using the **Change Password** menu option. | ||
+ | {{:menuchangepassword.png?200|}} | ||
+ | Under certain password options, the user may have their password expire, requiring a change or be forced to change password upon login. In all cases the user is navigates to the **Change Password** page. If the user navigated to **Change Password** using the user menu, the **Cancel** button is visible. If they were required to change their password, they must change their password before they can do anything in Item Writing. | ||
+ | {{:changepassword.png?600|}} | ||
- | ===== Banks and Bank Level ===== | + | The user must enter their current password in the **Current Password** field, then enter their new password twice (in the **New Password** and **Confirm New Password** fields). The current password must be correct, the new password and confirm new password must match and follow the rules listed on the page. When all conditions are met, click the **Submit** button. |
- | 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: | + | {{:changepasswordmatch.png?600|}} |
- | * 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, [[security_edit_banks|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: | + | ==== Selected Bank ==== |
- | * None - No access to the Bank. | + | Much of **Item Writing** requires the user to [[bank_select_level_1|select a Bank]]. Selecting the Bank filters the records returned on the various entry and selection grids. The selected bank is always visible on the master page's header bar. |
- | * 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. | + | |
- | === Shared Object Types === | + | {{:masterbank.png?600|}} |
- | 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 [[security_edit_banks|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_entry|Address Type]], [[bank_entry_level_1|Bank]], [[competency_type_entry|Competency Type]],[[contact_type_entry|Contact Type]], [[country_entry|Country]], [[country_region_entry|Country Region]], [[email_type_entry|Email Type]], [[ethnicity_entry|Ethnicity]], [[gender_entry|Gender]], [[item_meta_type_entry|Item Meta Type]], [[reference_type_entry|Reference Type]], [[security_entry_role|Security Roles]] and [[security_entry_user|Security Users]]. | + | |
+ | ==== Selected Exam ==== | ||
+ | When working with [[exam_entry|Exams]] in **Item Writing** all of the interactions with the Exam require having an Exam is selected. When the Exam is selected using Exam Entry, the selected Exam appears on the Master Page header. The Exam is a hyperlink which, when clicked, navigates the user bank to the Exam Entry page and reselects the Exam. | ||
- | === Level 1 Banks vs. Level 3 Banks === | + | {{:masterexam.png?600|}} |
- | 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 [[security_edit_banks|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 [[security_edit_banks|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. | ||
- | ^ State ^ Object Type ^ | ||
- | | Shared| [[attachment_entry|Attachment]], [[author_entry|Author]], [[candidate_entry|Candidate]], [[competency_entry|Competency]], [[copyright_entry|Copyright]] and [[reference_entry|Reference]] | | ||
- | | Banked| FIXME links to Item, Item Group, Exam and Term | | ||
- | 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. | ||
- | ^ State ^ Object Type ^ | ||
- | | Shared among child Exam/Item banks| [[attachment_entry|Attachment]], [[author_entry|Author]], [[candidate_entry|Candidate]], [[competency_entry|Competency]], [[copyright_entry|Copyright]] and [[reference_entry|Reference]] | | ||
- | | Banked| FIXME links to Item, Item Group, Exam and Term | | ||
- | 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). | + | ==== Main Menu ==== |
+ | Item Writing has a main menu bar on the master pages header bar. The menu is shared on all the pages of the Item Writing application. The menu options available to users is based on User permissions that are maintained on [[security_edit_user_general|Security Edit User]]. | ||
- | {{:level3banks.png?200|}} | + | {{:mastermenu.png?600|}} |
- | + | ||
- | === User Bank Security === | + | |
- | User Bank Security is maintained using [[security_edit_banks|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 FIXME links to 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_entry|Attachment]], [[author_entry|Author]], [[candidate_entry|Candidate]], [[competency_entry|Competency]], [[copyright_entry|Copyright]] and [[reference_entry|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 FIXME links to Item, Item Group, Exam and Term entry tools. | + | |
- | + | ||
- | + | ||
- | ===== Record Locking ===== | + | |
- | 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. | + | |
- | + | ||
- | {{:recordlocked.png?600|}} | + | |
- | + | ||
- | 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|Record Lock]] tool. | + | |
- | + | ||
- | ===== Versioning ===== | + | |
- | [[attachment_entry|Attachments]], [[item_entry|Items]] and [[exam_entry|Exams]] can be reversioned. By default, all new Attachments, Items 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 [[concepts#Banks and Bank Level |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, lets 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 lets assume the next available ID=320, so the new record would be ID=320, Version=3, Version1ID=25. | + | |
- | + | ||
- | ^ID^Version^Version1ID^ | + | |
- | |25|1|25| | + | |
- | |201|2|25| | + | |
- | |320|3|25| | + | |
- | + | ||
- | All three versions of this Attachment are tied together by their Version1ID value being the same. | + | |
- | + | ||
- | ==== Selection Grids ==== | + | |
- | The Attachment, Item 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. | + | |
- | + | ||
- | {{:examentryspecialfilters.png?600|}} | + | |
- | + | ||
- | ==== Viewing Prior Versions while Editing ==== | + | |
- | When editing Attachments, Items 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. | + | |
- | + | ||
- | {{:examversion1.png?400|}} | + | |
- | {{:examversion2.png?400|}} | + | |