Manual test scenarios for LeCoOntWeb

Scenario 1 (Create a new CM)

1. User oleg.rostanin (demo111) logs in
2. User clicks on the /File/New concept map and dialog appears
3. If user clicks for the first time, default values for namespace, prefix and type are set
   1. Otherwise the values from the last time
4. If user presses Create, a new CM is created
   1. Is open in the application
   2. Added to the list of open CMs
   3. A new locked model appears in the model on the server
   4. The CM is saved in the DB
   5. If one of the values in the form is not specified - the user is informed about this
5. If user presses Cancel, the dialog disappears (default values are not changed)

Scenario 2 (Correct control availability)

1. User oleg.rostanin (demo111) logs in / Closes the last concept map
   1. Edit CM Info is disabled
   2. Save CM is disabled
   3. Close CM is disabled
   4. New Concept is disabled
   5. View menu items are disabled
   6. Popups are disabled
2. User opens a concept map
   1. CM is read/write
      1. Edit CM Info is enabled
      2. Save CM is enabled (if the CM is changed, otherwise disabled)
      3. Close CM is enabled
      4. New Concept is enabled
      5. View menu items are enabled
      6. Popups are enabled
      7. Dbl-click on the empty field opens a New concept dialog
      8. Right-click on concept opens read/write Concept Info dialog (if concept is not locked by other users, otherwise read-only)
   2. CM is read-only
      1. Edit CM Info turns to View CM info
      2. Save CM is disabled
      3. Close CM is disabled
      4. New Concept is disabled
      5. View menu items are disabled
      6. Popups are disabled (except the navigation)
      7. Dbl-click does not work
      8. Right-click on concept opens read-only Concept Info dialog

Scenario 3 (Create new concept in a CM)

1. User dbl-clck on the free field of a read/write concept map (alternatively, menu File/New concept)
   1. New C. dialog appears
      1. User fills in data
      2. User clicks create
         1. Concept is created in the current CM
         2. Concept is created in the locked concept on the server
         3. The DB remains unchanged
         4. CM is changed

Scenario 4 (Edit a concept in a CM)

1. User rght-clck on a concept
   1. Edit C. dialog appears
      1. Concept is locked
      2. User changes data (uri can not be changed)
      3. User clicks save
         1. Concept is changed in the current CM
         2. Concept is changed on the server (changes visible for the user only)
         3. The DB remains unchanged
         4. CM is changed
         5. Concept remains locked until thge CM is saved

Scenario 5 (Save a CM)

1. User clicks save concept map
   1. Model on the server is saved to the DB
   2. Concept map is unchanged
   3. Concept map remains locked

Saving concepts

1. Once a concept is saved withing a locked CM the changes are reflected in the server-side model but not saved permanently (db). Concept lock is kept untill the CM is saved/reverted
2. Once a concept is saved from another editing point changes are saved in the model and in the db
3. If a new concept is created within a locked CM it is added to the server-side model and individual search index but not saved persistantly
4. If a new concept is created withing other editing points it is added to the server-side model, common search index and saved persistantly
5. If a concept in a CM was changed by another source (e.g. in a infoItems cockpit or VV)
   1. User has to get a signs that concepts were changed
      1. e.g. some symbol displayed as a concept icon
      2. If user opens such a concept it has to be refreshed from the server
      3. Flex-application should send "refresh"-requests periodically to get informed about changed concepts

Saving CMs

1. All read-only CMs should get a flag "dirty" if the editing user saved/closed it
   1. e.g. some symbol displayed
   2. User can refresh the CM contents from the server
   3. User can request a CM lock if the editing user closed the CM
   4. Flex-application should send "refresh"-requests periodically to get informed about changed CMs
2. If the user closed a CM without saving, the server-side model has to be reverted