This document has been prepared by Marine Learning Systems Inc. for the exclusive use of CSMART

Contents

Introduction 

This document describes changes required to the Scheduler to better accommodate CSMART planning processes. This document has been created following a 5 day description phase including multiple discussions with relevant members of CSMART. Discussions were focused around solutions envisaged by Nils Borre. MarineLS have distilled these down into requirements  and have suggested a work plan which can be completed in phases. These are prioritised in order to provide, what MarineLS perceives as, the biggest benefits early in the rollout. 

The document is split into two sections. The first acts as a summary of the new features required and how these could be split into work packages. The second section explains the solution and requirements in more detail as described by Nils Borre. These will be used for reference during specification of each feature.

Each feature is priced independently. Should a significant amount of features and work be approved for development discounts can be provided up to 10%.

Terminology

Resource: A location or personnel member. Some of these can only be scheduled to one thing at a time e.g. a person can only be scheduled to one thing, whereas an external hotel can have multiple bookings at the same time.

Resource Type: A category of Resources e.g. Classrooms, BRM1 Instructors, ERM1 Assistants.

Event Template: A saved template holding information about the length of an Event and which Resource Types should be scheduled within it. This may be related to a course, conference, or some other such group of timed activities.

Event Instance: An Event Instance has been scheduled and requires specific Resources to be allocated to it.

Module Template: A collection of Resource Types associated with a specific time block. This can be either within an Event Template or as an individual Module Template.

Module Instance: A collection of Resources (which may correspond to the Resource Types from the associated Module Template) which has been scheduled into a specific time slot. If the Module is part of an Event Instance the time slot will be derived from this.

SECTION 1 - New Feature Requirements and Proposed Work Plan

Limitations to current Scheduler

Many of the requirements are derived from pain points experienced using the current Scheduler. These include:

• The basic calendar view does not show information readily enough. It is necessary to click on a particular day and then through to specific Events in order to see information required for scheduling. This is time consuming and difficult to manage.

• The 52 week calendar takes a long time to load.

• Resources are scheduled individually rather than grouped into a particular activity within an Event. From a user perspective, an Event Instance exists as a single object. It is created using a Template which specifies the Resource Types required at certain times during the Event. When the user allocates a Resource to a Resource Type the systems makes the individual Resource bookings based on Template timings. Resource bookings are not grouped to a specific activity so if the user wants to change the timing of an activity within the event they must change every Resource booking individually. It is suggested Events contain Modules which can group Resource bookings, as explained in the Events and Module section.

• Event Instance details, such as Resources, participants, schedule, can only be viewed per single Event Instance. This makes it difficult to understand the impact of scheduling and Resource booking changes on other Event Instances.

• The user cannot create Event Templates on screen, instead CSMART must build a script to send to MarineLS for creation.

• The user cannot edit Resource Types and allocate Resources to these. Instead requests must be sent to MarineLS.

New Requirements

• The user should be able to manage Event Templates, Resources and Resource Types within the User Interface. See Basic Editing Interfaces#heading=h.34lve8xoymoy

• The user should be able to make bulk changes to Event Instances. Several different methods are proposed for doing this. See Editing Event Instances

• More fine grained scheduling capabilities including Modules and activation dates for Resources and Event Templates

Proposed Work Packages

Based on MarineLS’ understanding of the pain points with the current Scheduler and the new requirements outlined above we propose this project is broken down into smaller feature packages prioritised by the need and benefit gained. 

Each feature package will have a more in-depth analysis and specification of the problem at hand to determine the most functional and  best value solution to implement.

The proposed feature packages are:

1. User Interface Changes

2. Editing Resource Types

3. Editing Event Templates

4. Editing Event Instances

5. Resource Activation/Hiding

6. Module Structure

7. Other

8. Participant Shuffling

This phased approach has the following advantages:

• The number of changes required makes it very difficult to understand the whole scope at the level of detail necessary. By breaking down into smaller, related feature packages it will be easier to focus on the detail required for each section

• Benefits will be delivered as soon as each stage is completed

• Requirements can be more readily assessed throughout the project rather than committing far in advance of development only for business needs to subsequently change

• Cost commitments can be spread over a longer period

• By addressing the areas of greatest benefit first it may negate the need for some of the lower priority items

Disadvantages are:

• More scope for requirements to change throughout project so up-front cost predictions are more challenging

• Depending on the order features are delivered in there is potential for throw-away work if requirements change, or completed features need to be reworked based on later developments

User Interface Changes

A new User Interface (UI) is required to present the information needed for scheduling in a more efficient manner. Following long-term use it appears the Scheduler system is predominantly used for holding and presenting information and making short term changes where needed while long-term scheduling is conducted by Nils Borre on an infrequent, manual basis. These short-term scheduling changes are difficult to manage in the current view since information is not presented on-screen in an easy summary view and instead takes several clicks to reach Event information from the main calendar view.

As such, the following UI changes are proposed:

• Utilise an Outlook/Google Calendar style calendar interface with a 5 week view as standard.

• Events should be shown along with basic information such as name, operating line etc.

• It must also be possible to reach a weekly view showing more detailed Event information such as Resource bookings across Events or within a single Event.

• It will be possible to schedule and change Resource bookings within this weekly view. This will be an interim step to allow better Resource scheduling prior to the Module structure being developed in a later stage.

• It will also be possible to filter the calendar view to only show Events and Resource bookings based on specific properties such as operating line or Resource.

MarineLS believes that making these changes to the UI will provide the most immediate benefit and may actually reduce the need for some of the other requirements. We recommend an in-depth analysis of CSMART’s current use of the system and the exact problems being faced to ensure any new UI is matched to the needs of the business. Detailed mockups and workflows will need to created and validated with CSMART however an initial estimate from our current understanding is:

Comments

Discussions have been focused on a particular view envisaged by CSMART, and this estimate is based on creating that specific view. Possible savings could be found during specification by fully analysing the workflows and information views required for CSMART scheduling.

This estimate also assumes that the underlying structure of the system remains unchanged and Event Templates, Resource Types and Resource bookings will be managed in the same way without the use of Modules. This will simply develop a new UI presenting this information in a different manner.

Adding Modules later on would be done by adding one level of hierarchy (Event - Module Instance - ResourceType - Resource) or replace the ResourceType with Modules and adapt the interface to edit Modules instead of ResourceTypes within an Event or within the new Module Instance.

It is also hoped that by showing Resource bookings in a more usable manner it may go someway to satisfying the Module structure requirements since it will be possible to see all Resources within and across Events and adjust easily without the need for Modules.

User Interface Mockups

Click here to see current progress.
To make modifications, login to invision with username: craig@marinels.com, password: DudeChillingPark
Click here to download PSD. (If caleb is tasked with mockups Jeannie can help set up photoshop)

I have also included the zipped fullcalendar event (with example events added) / resource demos here.

Mockups Completed

-Event Month View
-Event Week View

-Event Day View

-Event List view

-Event Information Popover

-Resource Day View (WIP - will need to be reviewed/updated)

-Edit Event Panel
-Add Event Panel

Mockups Left to Complete

-Resource Views
--Week view that displays which and when resources are used

--Week view that displays which and when resources are used for a specific event* (which will be replacing the “edit event -> schedule”).

Open

--1-3 day resource view

-Add / Edit Event Templates (Phase 2?)

Editing Resource Types

CSMART cannot make changes to Resources and Resource Types within the user interface. They must request changes from MarineLS. This reduces flexibility of the system and makes it harder for CSMART to manage scheduling changes throughout the year. 

The editing functions required are the following:

• Adding, Editing and Deleting available Resource Types

• Editing and Deleting available Resources including assigning Resources to Resource Types (note users are added to the system using the LMS. This will remain unchanged.)

While these have been grouped together, each of these features could be developed independently. Estimates for each are:

Comments

This estimate assumes that the underlying structure of the system remains unchanged and Event Templates, Resource Types and Resource bookings will be managed in the same way without the use of Modules. This development will simply add new user interfaces to enable the desired editing features.’

Edit Event Templates

In the current Scheduler CSMART must provide Template changes as a script for MarineLS to load into the system. This reduces flexibility of the system and makes it harder for CSMART to manage scheduling changes throughout the year. The requirements are:

• It should be possible for the user to add, edit and delete Event Templates within the user interface. 

• It should then be possible to edit an existing Template and set an “activation” date for a Template change so only Event Instances after the activation date will be changed e.g. I edit the BRM1 Template and set the activation date as 1st July. The system will update all BRM1 Event Instances from 1st July onward to use the new Template. Event Instances prior to this date will remain the same. 

Edit Event Instances

Some more advanced editing features are also desired to allow Event Instances to be updated. The requirements are:

• Ability to change an Event Instance by switching the associated Event Template to a different Template (previously Switch Event Template)

• Ability to bulk change Event Instance fields by selecting one or more Event Instances within the calendar view e.g. I want to change the Resource assigned as a BRM1 Assistant on several different Event Instances. I can select all the required Instances and change the Resource for all of them.

These features could be developed independently. Estimates for each are:

Comments

This estimate also assumes that the underlying structure of the system remains unchanged and Event Templates, Resource Types and Resource bookings will be managed in the same way without the use of Modules. 

Resource Activation/Hiding

Personnel are  assigned to Resource Types based on their ability or qualifications to carry out certain tasks e.g.  BRM1 Responsible, BRM1 Assisting. These Resources will often have specific dates when they become able to carry out these tasks and thus become available for scheduling purposes. It should be possible to allocate a Resource to a Resource Type in advance so that they will appear available for scheduling from a particular date, but not before.

Comments

If CSMART would like this to be configurable by a CSMART user this task will require previous development of Editing Resource Type features in order to deliver a usable UI. If not this feature could be developed as a back-end configuration without the need for UI. The cost of this task remains the same in either option.

Module Structure

In the current Scheduler Resources are scheduled to Event Instances based on the Resource Types required in the Event Template. Specific Resources are then scheduled for the required times specified in the Template. Each Resource booking is an individual booking.

It is proposed that a new model is used for Resource booking which makes use of Modules, a sub-activity scheduled within an Event. Resources would then be booked against Modules rather than as individual bookings from the times specified within the Event Template. More details can be seen of how this model should operate in Section 2 - Events & Modules.

Existing Event Instances and Templates would then need to be migrated into the new model.

This is a fundamental change within the system and it is believed that improvements to the UI may go some way to improving the Resource booking functions anyway. Significant analysis of workflows would be required to specify this feature further however an estimate for implementing this structure is as follows:

Comments

Changing to this Module structure will require rework of much of the UI within the Scheduler. Any UI changes carried out ahead of this work will therefore need to amended leading to some throwaway work. However it is hoped that UI changes and other improvements may negate the need for this Module structure in any case.

Other

There are some additional miscellaneous feature requests which can be developed aside from the wider changes:

Export Agenda

Additional Permission Levels

Notifications

Changing OL and EmployeeID of a Participant

Notes from External Operating Line Demonstration

The below notes represent Scheduler requirements uncovered by the demonstration of External Operating Lines held on Feb 24 2016 with John Ritchie and Tara Peters. All of these are low priority and not expected to cause critical issues however if we are making changes to the Scheduler as part of this wider work it may be feasible to consider these additional requirements as part of this. These are assumed to be not-required unless further guidance is provided by CSMART.

• It would be nice to be able to filter the Allocation and Instructor Billing Reports to be able to filter out External OLs.

• Improvements to Resource Type drop-downs could mitigate the risk of having long drop-down lists when more External OLs are added. Not seen as a critical issue and Admins will just work with the long list.

• Additional filtering on Reports so that External OLs only see information related to their courses and offerings. It is currently not seen as a major problem since these reports are viewing only.

• Improvements to Open Allocations so that the system restricts External OL Admins from using these. It is currently anticipated this will be dealt with by communication to External OLs and monitoring by CSMART.

• Add a hover reminder to the Criteria tickbox. This step is not very obvious in the workflow so further instruction should be given.

Next Steps

The next steps required in order to begin the updates are:

1. Validate feature list is correct

2. Agree implementation approach i.e. is phased approach appropriate

3. Agree priority order

4. Approve Initial Estimates for high priority features

5. Begin Specification of first feature

SECTION 2 - SOLUTION DETAILS

This section outlines the solution outlined by Nils Borre during discussions with MarineLS. Estimates given in Section 1 have been broadly based on this solution however there may be opportunities to simplify this solution as more in-depth problem analysis is undertaken during the design of each feature. As such this section is intended for reference in support of estimates and for use during later specification and design discussions.

General

The focus for the new UI will be the calendar like views which will contain the most actionable items (edit/manage/view). To maximize the available real-estate for the calendar views (monthly, weekly, agenda) should take the max. horizontal browser space. The current Scheduler has filters to the left of the existing yearly view. 

All filters should be put on top of the views.

Calendar Views

The existing (yearly) calendar view has a limited use to plan events. Colour coding according to event count and filtering is not a representative view about when and which event has been scheduled.

This is why a monthly view, similar to Google Calendar, will be introduced and would replace the yearly view entirely. A monthly view also comes with a performance benefit - only one month worth of data needs to be loaded at once instead of a whole year.

Monthly View

The monthly view contains a full month (4+ weeks) with information about the event instance name, icons (‘Show Postponed Decisions’, ‘Show Unpublished Events’) and colour coding for available seats of scheduled event instances. Bi-directional arrows ‘<’ and ‘>’ at the top are used to navigate through months. Clicking on an event instance will open a popover with detailed information about that event instance (e.g. start-/end-date, event instance owner, participant assignments, OLs with remaining seats,...).

Dependent on the user role, the following buttons are available in the event instance popover:

• ‘Edit’: CSMART admin only

• ‘Manage’: Operating Line Coordinator. Same dropdown button for an OL coordinator who coordinates multiple OLs

• ‘Shuffle Participants’: CourseAdmin and CSMART admin

One day displays up to 4 parallel event instances. If 5 or more event instances are scheduled for the same day, a clickable count indicator (e.g. ‘+6 more’) is displayed below the first 3 event instances (pushing the 4th event instance into the ‘+x more’ popover). Clicking that ‘+x more’ indicator displays a popover with a list of all event instances for that day on the monthly view with start date and event instance name. 

Clicking on an event instance in the popover opens a second popover to display the event instance details (see description above). 

Notes: 

• The second popover is the same as if the user was directly clicking on an event instance in the monthly view

• There will be a lot of event instances in one month and not too much real estate to accommodate additional information per event instance. It is necessary to ‘drill’ into event instances to see more details. Hint: The Weekly/Agenda View displays more information per event instance

Monthly View as CSMART Admin

CSMART admins are able to edit an event instance by clicking on the ‘Edit’ button inside the event instance detail popover (similar to the existing UI). If a CSMART admin is also OL coordinator, the event instance colouring (green/red) applies to event instances and they are able to manage participants as OL coordinators.

The ‘Shuffle Participant’ button is active if there are more than one parallel event instance of the same type exists and are scheduled within the same week.

Monthly View as Course Admin

A course admin has the same abilities like a CSMART admin, except they can’t publish or delete an event instance.

Monthly View as Operating Line Coordinator

OL coordinators (incl. external) almost get the same monthly view - all event instances are colour coded according to whether they are able to add participants (green) or an event instance they would be able to manage is full (red). If the event instance can’t be managed, the event instance is coloured blue.

OL coordinators see the same popover for event instances as CSMART admins when clicking on an event instance. A ‘Manage’ button replaces the ‘Edit’ button . The ‘Manage’ button allows the OL coordinators to add participants to the event instance. OL coordinators able to manage multiple OLs get a drop down button to select the OL to manage participants for (existing behaviour in the current Scheduler).

Note: 

• OL coordinators don’t have access to the the Event View, only Manage Participants View. This is the difference between ‘Edit’ and ‘Manage’.

Monthly View as Viewer

The Viewers are users who are assigned to an event instance as a resource (i.e. instructors). This will let the resources view event instances they are allocated as a resource. Every view in the Scheduler is read-only for user role Viewer. The following views are available to ‘Viewers’:

• Monthly view

• Event (Instance) View (of one event)

• Agenda view

• Reports?

Discussion Notes:

• Do we want colour coding of some kind? NO

• Event Instances from same Event Template have the same colour? NO (there are too many - stick to the colouring of the existing Scheduler) 

• Colour coding according to which events have seats left (e.g. via tag with number of seats left)?

An example of a possible Monthly View:

Open

Weekly/Agenda View

The current Scheduler implementation offers a list view of all event instances within a date range by selecting days in the yearly calendar. The new Scheduler will have a similar functionality at the so called Agenda View. The user will be able to select a date range to list event instances ordered by their start date (additional filters can be applied).

For example, if a user selects a day in the Monthly View the date range for the Agenda View would be set to the full week of the selected day (i.e. select Tuesday would set the date range to Monday-Sunday). The date range can be changed at any time updating the Agenda View.

One item (event instance) in the Agenda View displays more information in its collapsed state than one item in the Monthly View. Every Event Instance in the list is expandable to display details of the Event Instance.

Information Displayed on Collapsed Event Instance

• Start and end date (no time)

• Event Instance name

• Colouring and available seats (if available)

• ‘Edit’/’Manage’ button (if available)

• ‘Shuffle Participant’ button (if available)

• Icons for ‘Show Postponed Decisions’ and ‘Show Unpublished Events’

Information Displayed on Expanded Event Instance

The same information is being displayed like in the popover detail of the Monthly View.

Single Event Instance View

A single Event Instance is displayed as week representation (1 day per column) - called Single Event Instance View. If an Event Instance lasts up to 7 days and doesn’t span across any weekend, the week view starts on Monday (even if no Resources are booked on Monday). If an Event Instance spans across a weekend and is between 1 - 7 days long, the start day of the Event Instance will be displayed in the first column. This would ensure to view the whole Event Instance without paging.

The columns would display the scheduled Module Instances incl. information like Resource Types, booked resources, start/end time. 

Modules can be updated by selecting Resources for Resource Types inside the Module. A popover would present drop down lists of Resources for any Resource Type.

Availability of Single Event Instance View by Role

• CSMART Admin: edit Event Instance 

• Course Admin: edit Event Instance

• Operating Line Coordinator: not visible. Instead, they will have access to Manage Participants

• Viewer: read-only

Filters

A filter on the left hand side of the window will remain similar to the existing filter of the current Scheduler implementation and is available for most views (e.g. monthly view, week/agenda view,...). Filter elements not available for a particular view are hidden (out of scope). For example, editing an event instance won’t have the option to filter by Operating Line or Event Template. However, filters like Resource Type or Resource are available at that level.

The icon and filter check box ‘Show Unmet Criteria’ will be removed because after release v3.3.0 the Criteria must be accepted every time a participant is being added. This means that no information about ‘unmet criteria’ per Event Instance is available anymore.

The following chapters describe which filter options are available at which view and for which user role.

Note: 

‘Show Unmet Criteria’ doesn’t exist anymore because OL coordinators need to acknowledge the ‘criteria’ for every participant they add separately and not per event instance anymore.

Filter for Monthly View

Filter options by role:

• CSMART Admin: all available filter options - ‘Operating Line’, ‘Event’, ‘Resource Type’, ‘Resource’, ‘Show Postponed Decisions’ and ‘Show Unpublished Events’

• Course Admin: all available filter options like a CSMART admin

• Operating Line Coordinators: has a limited filter options - only ‘Event’ and ‘Operating Line’ is available. The filter option ‘Operating Line’ is initialized with the first Operating Line the user is able to manage after user logon

• Viewer: all available filter options like a CSMART admin

Filter for Weekly/Agenda View

Filter options by user role:

• CSMART Admin: all available filter options - ‘Operating Line’, ‘Event’, ‘Resource Type’, ‘Resource’, ‘Show Postponed Decisions’, ‘Show Unpublished Events’, ‘Date Range’

• Course Admin: all available filter options like a CSMART admin

• Operating Line Coordinators: has a limited filter options - only ‘Event’, ‘Operating Line’ and ‘Date Range’ are available. 

• Viewer: all available filter options like a CSMART admin

Initially, the ‘Date Range’ filter option is set to the current week. For example, today is Jan. 3rd, 2018. Set the Date Range to Jan. 1st - Jan. 7, always starting on Monday of the current week.

Filter for Single Event Instance View

At this view level the following filter options are out of scope and therefore not available:

• Operating Line

• Event

• Show Postponed Decisions

• Show Unpublished Events

Filter options by user role:

• CSMART Admin: limited filter options due to scope - ‘Resource Type’, ‘Resource’, 

• Course Admin: all available filter options like a CSMART admin

• Operating Line Coordinators: view is not available for this role

• Viewer: view is not available for this role

Inherit Filter Options Between Views

Switching between Monthly View and Agenda View should maintain the same filter options. Changes to the filter options in either of the Views should be carried over to the other View (except ‘Date Range’).

For example, if filter options are changed in Monthly View and the user switches to the Agenda View, all applied filters should be applied to the Agenda View. 

Moving from Single Event View ‘up’ to Monthly View or Agenda View will discard the filter options set in the Single Event View. However, available filter options from Monthly View or Agenda View will be applied moving ‘down’ to the Single Event View when opened.

Edit Resource Types

There are two editing functions required 

• Add, Edit and Delete available Resource Types

• Edit and Delete available Resources including assigning/removing Resources to Resource Types

Add, Edit and Delete available Resource Types

The resource view of the main Scheduler page will have a button 'Resource Types' for CSMART Admins only. This 'Resource Types' button directs to a new page that displays all existing resource types.

Filter mechanism (To be decided)

UI Screen (Work In Progress)

List of Resource Types would have the following columns

• CoreGroupName (sortable, default ascending)*

• DisplayName   (sortable)

• IsInstructorRole (sortable)

• IsLocation   (sortable)

• SchedulingStyle  (sortable)

Available action for a resource type 

• Edit   : Opens up a modal page of 'Edit ResourceType view' (see development note below)

• Delete : Deletes resource type 

Other functionality on the Resource Type

The follow actions would be offered on the Resource Type view

• Add New resource Type: Add a new resource type 

     Input required on form:

       [DisplayName]

       [

Development Note

• This is a pure Angular feature, so no legacy code should come here.

• All new service call functionalities will live in the Angular SchedulerDataService;

• Add New Resource Type : check [CSMARTService.CreateResourceType], Angular Reactive forms would be used 

• Edit Resource Type: check [CSMARTService.UpdateResourceType], Angular reactive forms would be used

• Delete Resource Type

• If a Resource is moved from one Resource Type to another, or removed from one Resource Type and the Resource is still assigned to another Resource Type, we need to check the code if a Booking.ResourceBookings.ResourceType must be updated or not.

  • The Resource Type of a selected Resource in a Booking must match with the Resource’s Resource Type and the Booking.ResourceType. Is this a requirement?

Editing a Resource Type affects all existing Event Templates and Event Instances and reports.

If a Resource is being removed from a Resource Type, it won’t be available for any scheduling anymore. However, if the Resource has already been scheduled, it will ‘stay’ scheduled.

Editing and Deleting available Resources in ResourceTypes  

[Description comes here]

Notes/Discussions:

• Show count of Resource Types a Resource is assigned to and warn if a Resource is removed from the last Resource Type assignment because it will get deleted(?)

  • Do we want to allow Resources not attached to any Resource Type? Action: TBD

• Deleting a Resource Type which contains Resources which are not attached to any other Resource Type will be deleted - warn about that. Action: TBD - delete Resource/make Resource an orphan?

Edit Event Template

This UI is a version of Single Event Instance View.

The first iteration of editing Event Templates is using no Modules. Use the existing structure of Event Templates with Resource Types. In a subsequent development phase the UI elements for Resource Types will be replaced with Modules which themselves will contain Resource Types. Additional changes for the DB and object structure will be needed to support Modules.

The existing DB and object structure needs some adjustments to accommodate the Edit Event Template feature. Currently, the Scheduler needs 2 Resource Types whereas it should use only 1 Resource Type multiple times. The reason for the current setup is that a Resource Type can’t be added to an Event Template multiple times. The workaround was to create 2 Resource Types which hold the same Resources (i.e. Full Mission Bridge 1 and Full Mission Bridge 2). This allowed to add 2 Resource Types to the Event Template.

Edit Event Template will allow multiple same Resource Types per event and therefore need some adjustments to some DB and model structures.

(done) Discussion Needed:

• What if an Event Template needs to be updated because it contains an error/needs a small change. Should it be possible to edit an Event Template without creating a copy? We don’t introduce a full versioning system. Some changes may affect existing Event Instances (i.e. changing the LMS course of an Event Template). 

  • Answer: Always create a new copy, no matter how small the change is. Hiding and publishing event templates will make it possible to deal with changes.

• Day vs Week view - ask Nils which views he needs. Is a Day view necessary or is a Week view enough? 

  • Answer: Day view is not necessary. Week View is enough (=Single Event Instance View)

• Type of Week view - (edit/view Event Templates and Event Instances) - resource view or Google Calendar style? 

  • Answer: Google Calendar style

Development Notes: 

• An Event Template will have an optional reference to the Event Template it has been copied from (update EF models via Migration). An Event Template doesn’t have a reference if it has been created from scratch.

• EventTemplate.DefaultBookingTimes will be calculated automatically (currently, this  is a manual process via client command ‘updateTemplateDefaultBookingTimes’). One time span pair per day with start=minTime([all default Resource Type time spans]); end=maxTime(all default Resource Type time spans). Currently used to initially create BookingTimeSpans of an Event Instance. 

• EventTemplate.DefaultResourceTypeBookings 

• EventInstance.BookingTimeSpans: Every time a Resource time span is updated the BookingTimeSpans are updated too (as part of UpdateEvent service call).

• Currently, one Resource Type booking time per day is possible. Update EF models to support multiple booking times per day and Resource Type. Currently, we do a lookup by Resource Type for a BookingTime. Add identifier to EF model? Update UI to use new identifier to address the BookingTime (Event Template and Event Instance). 

Manage Event Templates Page

The main Scheduler page will offer a button Manage Event Templates for CSMART Admins only. The Manage Event Template button opens a new page with a list of all Event Templates. A filter to display Event Templates according to ‘Display Name’ (text search) and ‘States’ is available. By default, apply filter for Event Templates which are in States ‘New’ or ‘Published’. A button Filter is available to update the Event Templates list for any changes in the filter options.

The list of Event Templates displays the following columns:

• Event Template Display Name (sortable, default: ascending)

• Short Base Name (sortable)

• Course Path / Course Name(?) (sortable), use n/a if the Event Template doesn’t reference an LMS Course

• Effective Date (sortable) (implemented in a later phase)

• Expiry Date (sortable) (implemented in a later phase)

• State (sortable)

• Drop down button with possible actions according to the State of the Event Template

Actions for an Event Template:

• Edit (if current State is ‘New’): Open the Edit Event Template View

• View (if current State is ‘Published’ or ‘Unpublished’): Open the Edit Event Template View in read-only mode

• Copy: Copy selected Event Template and set copied Event Template display name to ‘[display name of original Event Template] (copy)’. After that, the copied Event Template can be published, edited or unpublished (=deleted)

• Publish (if current State is ‘New’): makes the Event Template visible and usable in the Scheduler

• Unpublish (if current State is ‘New’ or ‘Published’): Remove the Event Template from any further usage (i.e. create Event Instance) and listings.

Features in Event Template Editor

• An Event Template has a ‘State’ property for the following ‘States’

  • New: changes to the Event Template are possible. Can’t be scheduled as Event Instance

  • Published: No changes to the Event Template possible (read-only). The Event Template can be scheduled. Can be 

  • Unpublished: terminal state - hides the Event Template from any lists so it can’t be scheduled anymore. Event Instances that reference the unpublished Event Template can still access the Event Template (read-only)

  • Workflow of States: New → Published → Unpublished

  • Development Notes

    • Migration (DataMotion) of existing Event Templates

      • IsHidden == false → Published 

      • IsHidden == true → Unpublished 

      • The property DateAdded of the State is set to DateTime.UtcNow

    • Every State item will have at least

      • DateAdded

      • State

      • User making this change

• Create a copy of an existing Event Template

  • A copy of an Event Template contains all Resource Types, scheduling times and other properties (i.e. metadata) from its ‘parent’ Event Template 

  • All properties of a copy can be edited except for LMS Course Mapping. The referenced LMS Course can’t be changed. Once the Event Template is published, the Event Template becomes read-only - no further changes are allowed

  • The Event Template copy will reference the Event Template it has been copied from. The existence of a reference makes the LMS Course Mapping property read-only)

  • The copy will be in state ‘New’, initially

• Create new Event Template from scratch

  • All properties of the Event Template can be edited before it is published. This includes editing the LMS Course Mapping of the Event Template. Once the Event Template is published, it becomes read-only - no further changes are allowed. 

  • May be too much trouble for this - usually the LMS Course Mapping never changes for an existing Event Template

  • The new Event Template will be in state ‘New’, initially

• Publish Event Template

  • Once an Event Template is being published, the Event Template becomes read-only and cannot be changed anymore. The only way to ‘edit’ the Event Template is to replace it with a modified copy and hide (unpublish) the ‘old’ Event Template

  • Add a new state published to indicate that the Event Template is published

• Unpublish Event Template

  • Set ‘State’ into ‘Unpublished’ and never can be published again

  • Remove the Event Template from all drop down lists in the Scheduler (filters, reports, add Event)

  • Discussion Needed

    • Once an Event Template is unpublished, the Event Template doesn’t show up in any drop down like filters or reports. Event Instances which were created by the now unpublished Event Template can’t be filtered by or reported on

• Colours set for Resource Types are used to colour booking time spans in the Event Template editor (and Event Instances)

• The event length is automatically determined by calculating the number of days which contain Resource Type time spans - earliest time span until latest time span and all days in between. It is possible that no Resource Type is needed on a day (empty day). In such a scenario the empty day is included in the event length if time spans ‘sandwich’ the empty day. That is, the previous day AND the day after the empty day contain time spans for Resource Types

• The editor view will have columns like ‘Day 1’, ‘Day 2’,..., ‘Day x’. If more than 7 days are used, navigation arrows are available to view/edit days outside the currently visible day range (usually 7 days at a time). It is not possible to add Resource Types to days before ‘Day 1’. ‘Day 1’ is the earliest day for an Event Template (or Event Instance)

• The filter has one filter option - Resource Type which is placed to the left of the day columns - no other filter options makes sense at this level

• All scheduled Resource Types in the Event Template are listed to the right/left(?) of the day columns. A count per Resource Type will let the user know how many resources of a specific Resource Type is required to schedule this Event Template. For example, if 2 of the same Resource Type are booked in parallel or overlap in time span (i.e. Resource Type FMB), 2 Resources of this Resource Type are needed to fully schedule an Event Instance

• Add a Resource Type by dragging a time span onto a day column. This will open a popover to select the Resource Type used for this time span (via drop down)

  • Resource Types don’t have default time spans (unlike the current Scheduler) - the time span of every day is determined by dragging a time span onto the day column (like Google Calendar). Or by clicking into a day column which opens the popover to select/change the time span and Resource Type (similar to Google Calendar)

• Move/extend/reduce time span for a Resource Type within a day or across days

  • Default granularity is 5min (if space permits)

  • Workflow 1: Drag & Drop - any changes will be applied without confirmation

  • Workflow 2: Click on a time span to open a popover which allows editing the time span (Resource Type, from time, to time, day column for ‘from’ and ‘to’ times). Buttons to apply or cancel the action are provided (no confirmation needed). An ‘x’ in the top right corner allows to close the popover cancelling any changes (no confirmation needed)

  • (Same) Resource Types can overlap in time

  • Development Note

    • The day column drop down lists for ‘from’ and ‘to’ times of a time span are limited to 30 days

    • ‘from’ and ‘to’ times are drop down lists (5 min. increments) in 24h format (i.e. 00:00, 08:15, 16:05, 24:00)

    • Check if there is enough vertical space to allow 5min. granularity in the day column view (the popover in Workflow 2 allows 5 min. granularity in the dropdown lists)

• An ‘x’ icon in the top right corner of every scheduled Resource Type can be used to remove a specific time span from the Event Template. If all time spans for a Resource Type are removed, the Resource Type is removed from the list of scheduled Resource Types

• Changes to an Event Template are not saved right away and therefore must be actively persisted via Save button (with options Save and Save and Close). A Cancel button is available to undo any changes. Save and Cancel need a confirmation dialog to execute the operation. The Save button is only active, if changes have been made. The Cancel button is always active to be able to close the editor.

• (Phase 2) An Event Template has an activation date and an optional expiry date

  • Once an Event Template expires, it will be no longer available for scheduling Event Instances 

  • Moving Event Instances from one Event Template to another Event Template is separate from the actual Edit Event Template UI/workflow (see ‘Activate Event Template’)

• Delete/Unpublish an Event Template

  • Currently, we only hide (IsHidden=true) an Event Template if it should get deleted. Mark as deleted is not implemented yet. This may change in the New Scheduler and the Event Template will have a ‘State’ property to indicate different states like ‘published’, ‘unpublished’, ‘deleted’ (note: unpublished is equal to ‘hidden’/’deleted’)

  • Already scheduled Event Instances won’t be affected by deleting/unpublishing its referenced Event Template

  • It should be possible to update all Event Instances to ‘move’ over to a new Event Template referencing the same LMS course (see ‘Activate Event Template’)

• Event Template Metadata

  • Display Name for the Event Template must be specified (don’t enforce unique names). Display name is case-sensitive

  • ShortBaseName (required and must be unique)

    • Development Notes: Changing this property would affect an Event Instance if it was updated

  • Event Template length in days. Read-only and is calculated from scheduled Resource Types (earliest Resource Type timespan to last Resource Type timespan)

  • CKEditor to edit the following properties

    • EmailTemplateTextForOperatingLine 

      • Development Notes: Changing this property would affect all its Event Instances

    • EmailTemplateTextForParticipant 

      • Development Notes: Changing this property would affect all its Event Instances

    • EmailTemplateTextForStandbyList 

      • Development Notes: Changing this property would affect all its Event Instances

    • Criteria

    • Details

    • Notes

  • Colour

  • DefaultMinSeats

  • DefaultMaxSeats

  • NotificationIntervalShortId 

    • Development Notes: Changing this property would affect all its Event Instances (future only). 

    • Use drop down menu to select the interval

    • Default selection: default10,default8,default2,default1

  • LMS Course Mapping 

    • Select LMS course from drop down menu (populated by Core courses)

    • Event Instances use the Event Template’s LMS course to register/deregister participants

    • Development Notes:

      • Scheduler courses should be marked via Link Attribute, so not all LMS courses are listed

      • Read all LMS courses found via Org Path from app.config which are marked with specific Link Attribute

Multiple Time Spans for the Same Resource Type

The question is whether it is possible to add multiple time spans for one Resource Type on one day. Assume the FMB is used twice in one day (sequential)

(done) Discussion Needed:

• New requirement to use one Resource Type more than once a day with different time spans (i.e. morning and afternoon)
  The current implementation allows only 1 time span per Resource Type and day - independent on how many times it is added to the Event Template. If you have the same Resource Type added multiple times to an Event Template, they all use ONE time span per day. However, this will change with the new Scheduler implementation. For example, a Module for coffee break may be applied multiple times per day on different times. 

  • If the same Resource Type is needed a second time, add the same Resource Type again. It is possible to drag & drop Resource Types across days and eventually add multiple same Resource Types to one day

  • How do we group the Resource Type bookings? Answer: There is no grouping of Resource Types - if 2 same Resource Types are used on the same day (or even overlap), the user needs to manually select the Resource used for all time spans in an Event Instance separately

  • For example: 

Resource Type List on the side:

• RT (A)

• RT (B)

Resource Type A is being used twice on Day 4. This indicates that the Resource Type A is needed twice for the Event Template. Scheduling Resources for an Event Instance is a manual process.

• What if a booking time is removed (i.e. Day 4, Row 4)? Answer: Reducing the booking times from 2 to 1 on Day 4. This would reduce the need of Resource Type A to 1.

Development Notes: 

• Indicating Resource conflicts may have performance implications? Answer: Some investigation in the code resulted in no concerns for performance concerns

• Need an algorithm to calculate DefaultBookingTimes for the Event Template (=per day)

• Need function to calculate the scheduled Resource Types and their booking time spans

Activate an Event Template [in progress]

It should be possible to set an ‘activation’ date for an Event Template so only Event Instances after the activation date will be updated to use the new Event Template. Event Instances which have been already scheduled past the expiry date can be manually bulk-changed to upgrade to the new Event Template

For example, edit the BRM1 Event Template and set the activation date as 1st July. The system will update all BRM1 Event Instances from 1st July onward to use the new Event Template. Event Instances prior to the activation date will remain the same. 

Any Resource Type and scheduled Resource will be moved to the Event Template, if available. Resources which are not used by the new Event Template free up. If a Resource conflicts with another scheduling, it is necessary to manually resolve the conflicts at a later time. The update of the Event Template doesn’t provide any workflow to resolve conflicts during the conversion. New Resource Types in the updated Event Template will need to be manually scheduled in every Event Instance.

Needs Discussion: 

• There is currently no feature to indicate Resource conflicts. This could be added as icon in the Scheduler view - Triangle with exclamation mark to indicate Resource conflicts? 

• An Event Template can be activated to replace another Event Template if both Event Templates are pointing to the same LMS course. The reason is that moving participant assignments from one course to another would require re-registering everyone. If this is OK with CSMART, we could allow that

• Should the Min- and MaxSeats of the Event Instances be changed according to the new Event Template? If the Event Instance already has participant assignments, overbooking could occur (new Event Template has less MaxSeats)

Edit Event Template Within Old Scheduler UI (minimal option)

Because the new Edit Event Template UI is a large project and may take a lot of time before it may be released, a temporary (minimal) solution is described below. This option has limitations to what can be done.

Initial Estimates

• Edit Event Template with Old Scheduler UI: 1.5-2 weeks + QA

• Client command option (offer CSMART a way to execute some client commands with sanity check before publishing an Event Template): 2.5-3 weeks + QA

Workflow

1. Create a new unpublished Event Instance from an Event Template you would like to create a copy from

2. Edit Event Instance (don't publish)

3. Make any changes

4. Save as new Event Template (via additional button in edit Event Instance

Settings Which can be Changed for the new Event Template

• Resource Types 

  • If multiple Resource Types are added, only one Resource Type is used for the Event Template

  • No selected Resources will be stored for the Event Template

• Event Details

• Criteria

• Notes

• Max Seats (=DefaultSeats)

• Scheduled Times 

  • If a Resource Type is selected multiple times and different scheduling times are set for those Resource Types on one day, the Event Template will contain scheduling times for only 1 Resource Type. There is no guarantee which one will be chosen (see Odd Behaviours below for more details)

Settings Copied Into the new Event Template Without Change (because there is no UI available to make the changes)

• CoursePath

• CourseId

• Length (in days)

• ShortIdBaseName (this must be unique - autom. generate unique name by adding numbers?)

• DefaultMinSeats

• NotificationIntervalShortId

• EmailTemplateTextForStandbyList

• EmailTemplateTextForOperatingLine

• EmailTemplateTextForParticipant

• Colour

• DisplayName (this must be unique - autom. generate unique name by adding numbers?)

• Resource Type Scheduling Type

Settings Which Won't be Stored as Part of the Event Template (not part of the Event Template at all):

• Event Owner

• Multiple Resource Types

• Cost Type

• Operating Lines

• Resources selected for a Resource Type

Odd Behaviours

• You have to select a Resource for the Resource Type. Otherwise, you can't set a booking time for that Resource Type

• If multiple same Resource Types are selected - which booking times do we take for the Event Template?

  • We could restrict the 'save' button to not allow multiple same Resource Types?

  • We could take the first (note: sort by property? Id?, Resource Type? This is not intuitive

Create and Edit Event Instance [in progress]

To create an Event Instance the user selects the day when the event should start in the Monthly View. The popover dialog windows will have 2 drop down menus - one for selecting an Event Template, the second to select a Resource if this is to become a Resource based Event Instance . 

Selecting an Event Template will create a new Event Instance from the selected Event Template.

The Single Event Instance View will allow the user to assign Resources for the Resource Types.

All booking times will be displayed as blocks in the calendar like view which can be moved/deleted, add new Resource Type time spans,...

Assign Resource for Resource Type Booking

Selecting a Resource for a Resource Type booking will set the Resource for that one booking. However, if all booking times for one Resource Type are either ‘Postponed’ or ‘None’, selecting a Resource for one Resource Type booking would update all Resource Type bookings with the selected Resource.

If a selected Resource for a Resource Type is changed and not all Resource Type bookings are set to ‘Postponed’ or ‘None’, only update the specified Resource Type booking.

(done) Needs Discussion:

If a Resource Type is used multiple times in an Event Instance, do they have different booking times? Or are the booking times always the same? Answer: The booking times can be different

Edit Event Instances [in progress]

Some more advanced editing features are desired to allow Event Instances to be updated. The requirements are:

• Ability to change an Event Instance by switching the associated Event Template to a different Event Template (previously Switch Event Template)

• Ability to bulk change Event Instance fields by selecting one or more Event Instances within the calendar view e.g. I want to change the Resource assigned as a BRM1 Assistant on several different Event Instances. I can select all the required Instances and change the Resource for all of them.

These features could be developed independently. 

Comments

This estimate also assumes that the underlying structure of the system remains unchanged and Event Templates, Resource Types and Resource bookings will be managed in the same way without the use of Modules. 

Resource Activation/Hiding [edit]

Personnel are  assigned to Resource Types based on their ability or qualifications to carry out certain tasks e.g.  BRM1 Responsible, BRM1 Assisting. These Resources will often have specific dates when they become able to carry out these tasks and thus become available for scheduling purposes. It should be possible to allocate a Resource to a Resource Type in advance so that they will appear available for scheduling from a particular date, but not before.

Comments

If CSMART would like this to be configurable by a CSMART user this task will require previous development of Editing Resource Type features in order to deliver a usable UI. If not this feature could be developed as a back-end configuration without the need for UI. The cost of this task remains the same in either option.

Events & Modules

More control is required in creating and scheduling courses, Resources and other time sensitive activities within the CSMART Scheduler. 

Currently Resources are scheduled within an Event based on the Event Template and the Resource Types required within that Template. Each Resource is then scheduled against the associated time individually. 

For example, an Event Template has the following Resource Types:

• BRM1 Responsible

• BRM1 Assisting

• Simulator Room

The Event Template is set so that these Resource Types are required between 10.00-11.00 and 14.00-16.00. When an Event Instance is scheduled using this Template a specific Resource is allocated to each Resource Type. The system will then book these Resources during the required times.

To allow simpler scheduling and adjustment of bookings Resources should be allocated to Modules. These Modules are used to group the Resource bookings into a single Instance which can be used to manage the scheduling of all Resources assigned to that Module, as opposed to having to update each one individually.

Modules

A Module will provide a way to group Resource bookings in a set period of time. It was suggested by CSMART that this should be a 15 minute period however it is recommended that a smaller unit of time is used to allow greater flexibility.

Comment: The module period granularity is dependent (adjustable) on the UI allowing for a finer granularity in the calendar (e.g. fullcalendar.io -> snapDuration). The EF model will allow any time period.

A Module will cover a single activity only. A Module can be any activity e.g.

• A Course Module e.g. BRM 1 introduction, Simulator Exercise No.1

• A coffee break

• A meeting

• A vacation day

Modules can exist as Templates or Instances. 

A Module Template is a collection of Resource Types associated with a specific time block. This can be either within an Event Template or as an individual Module Template. This will include:

• Resource Types required

• Title

• Description e.g. Lesson plan, meeting agenda

• Required/recommended duration

• Relative position within Event Template if relevant (day and time)

• List of Event Templates it’s referenced by

Module Templates can be placed directly into the Scheduler as individual Module Instances or allocated to an Event Template.

It is not possible to add specific Resources to a Module Template.

A Module Instance is a collection of Resources (which may correspond to the Resource Types from an associated Module Template) which has been scheduled into a specific time slot. If the Module is part of an Event Instance the timings (relative position) will be derived from this. It will contain the following information

• Resource Types required (+ manually added ad-hoc Resource Types)

• Resources, as per Resource Types required (+ Resources selected for ad-hoc Resource Types)

• Title

• Description e.g. Lesson plan, meeting agenda

• Start time, end time and date

• Event Instance it is referenced by if necessary

• Status - Unpublished, Published, Cancelled

 It should also be possible to add ad-hoc Resources to the Module Instance.

When adding Resources to the Module Instance only those associated with the specific Resource Type can be added to the Module Instance e.g. if a Resource Type BRM1 Instructor is required in the Module, then only personnel within the BRM1 Instructor Resource Type may be scheduled in this Module.

Once a Module Instance has been scheduled and Published the Resources listed are booked for the time of the Module Instances. 

Events

An Event is a collection of 1 or more Modules. For example a BRM1 course may consist of the following Modules:

• 30min Introduction

• 1st session in class room 1

• Bridge Resource management phase 1 (BRM1)

• Coffee break

• Simulator Exercise No 1

• Coffee break

• Simulator Exercise No 2

• Debriefing

• Preparation for Homework

Events are generally used for courses or conferences (as opposed to meetings, and other one-time Events which sit at the Module level). Like Modules, Events can exist as Templates or Instances. 

An Event Template contains a group of Module Templates specifying the relative timing of these within the overall Event duration. It also contains the following additional information:

• Max/Min number of participants

• Duration of Event (in days)

• Notes

• Criteria

• Event details

• Course detail

• Link to LMS content if applicable

• List of Modules held within Event

The Event Template can be placed into the Scheduler as an Unpublished Event Instance. The Module Templates within it will also be scheduled as Module Instances and pre-populated with the timings and Resource Types required.  However these Module Instances should not be bound i.e. once an Instance is placed into the schedule the allocated Resource Types may be changed and times and order can be adjusted should that be necessary.  Once happy with the structure of the Event and Module Instances the user will need to allocate Resources to the required Resource Types of each Module and Publish.

The Event Instance also has some additional fields:

• List of participants

• Start Time, End Time and Date of the Event. Module Instance timings will then be calculated from these

• Status - Unpublished, Published and Cancelled

• Lead Instructor/ Event Owner; the only Resource required at the Event level for Certificate purposes. All other Resources exist at Module level only. However this will not make the Resource assigned as Lead Instructor “busy” for the whole course period. Resource availability is only determined by scheduling of Module Instances.

It should also be possible to update an Event Instance by switching the underlying Event Template for a different one.

Resources

Personnel

It should be possible to schedule Personnel to different Modules. A personnel Resource will have the following attributes:

• Name

• Employee ID

• Department; as a drop down list

• Operating Line

• Resource Types e.g. Responsible BRM1,  Assisting BRM1,  Responsible ERM1, Assisting ERM2 including the date a Resource Type is valid from and to (in case a Resource Type is not available from a specific date - similar with Templates)

The Resource Types assigned will be used to categorise and filter personnel when adding Resources to Module Instances. It is also assumed the current functionality showing whether a Resource is Available or Unavailable based on other bookings will be maintained.

It must also be possible for a user to be assigned as a participant and instructor with the same user login. 

CSMART must be able to add new Personnel and assign them to Resource Types. There should be an activation date for when the new Personnel can be selected within that Resource Type. For example an instructor may get his certification for BRM1 instructor in 3 months time. Therefore it should only be possible to schedule this person to a BRM1 Module after the activation date in 3 months time. 

Similarly it must be possible to hide them from a particular Resource Type from a selected date, for example if a person is leaving the organisation and they have 3 month notice period they can still be scheduled prior to their leaving date but not afterwards.

Locations

It should be possible to schedule locations to different Modules and Events. A location Resource will have the following attributes:

• Name e.g. Simulator room 1, Meeting Room 2A

• Resource Types e.g. Simulator, Classroom, Debrief Room, Meeting Room

• “Always available flag”; some external locations are not restricted in how many Modules can be scheduled against them e.g external hotels. Therefore it should be possible to set a location Resource as always available.

These attributes (particularly Resource Types) will be used to categorise and filter locations to certain Events/Modules.

Resource Types

Resource Types are used to categorise and filter Resources when they are scheduled to Modules.

In the current Scheduler only MarineLS can change or add Resource Types. In the future it should be possible for CSMART to add, edit and hide Resource Types as needed, as well as assigning Resource Types to specific Resources.

Bulk Changes

Switch Event Template for Event Instances via Client Command (Phase 2 of Edit Event Templates) (release 3.9.0 - PSDEV-381)

It should be possible to bulk update Event Instances to use a new Event Template, starting from a particular date. This is to provide a client command to switch Event Instances to a new Event Template. For example: 

switchEventTemplate [old Event Template Name] [new Event Template Name] [fromDate: format of ‘dd/MM/yyyy’. Switch all Event Instances which start date is equal or greater than ‘fromDate’] [optional: ResourceType/Resource mapping for added Resource Types]

switchEventTemplateByEventId [event Id to switch] [new Event Template Name] [optional: ResourceType/Resource mapping for added Resource Types]

The command implementation have one other use case:

It allows setting Resources for Resource Types which are ‘none’ or ‘postponed’ if the command parameters ‘Old Event Template’ and ‘New Event Template’ are equal (and match with the event instance’s event template).

The command updates any ResourceType/Resource mappings for Resource Types which are ‘none’ or ‘postponed’ and updates event instance’s scalar properties like Criteria, Details, MinSeats, MaxSeats, Colour of the Event Instance, using the values from the Event Template. 

Examples

switchEventTemplate “BRM 1 Day” “BRM 1 Evening” 15/10/2018 “BRM 1 Responsible=Murray|BRM 1 Assisting=Terry”

switchEventTemplate “BRM 1 Day” “BRM 1 Evening” 15/10/2018 “BRM 1 Responsible=Murray|BRM 1 Responsible=Terry|BRM 1 Assisting=Mike”

If 2 ‘BRM 1 Responsible’ are part of the new Event Template, set both Resources ‘Murray’ and ‘Terry’.

Requirements for the targeted (new) Event Template:

• Must point to the same LMS course

• Must have the same event length (in days)

• Resource booking time spans may differ

• Resource Types may differ

Requirements for the updated Event Instance:

• All time spans must be updated according to the new Event Template’s time spans

Client command behaviour:

• Event Instance start date must be in the future (the earliest date is tomorrow)

  • Update all Event Instances which start date is on or after the provided ‘fromDate’. If the fromDate is today, get all Event Instances starting tomorrow (fromDate + 1 day)

• Also switch Event Instances with IsPublished = false - even if they were cancelled (CancellationDate != null)

• Check all Event Instances for above requirements before making any change

• Update all Event Instances which meet the requirements (update time spans, DisplayName, Details, Criteria, MaxSeats, MinSeats, Colour)

  • Warn and DON’T UPDATE MaxSeats if (new MaxSeats < original MaxSeats) AND (AllocactionCount > new MaxSeats)

• Don’t update NotificationIntervalShortId (it is assumed to be the same and would need to update TimerEntries as well if changed)

• Handle Resource Types

  • Remove Resource Types from the Event Instance if it doesn’t exist on the new Event Template any more

    • If 1 Resource Type of a duplicate Resource Type on an Event Instance should be removed, remove the bottom one first (as they appear on the UI).

    • Don’t consider ad-hoc Resource Types for deletion (see ‘Add new Resource Types’)

  • Add new Resource Types to the Event Instances from the new Event Template

    • That is, if the Resource Type doesn’t exist on the current Event Instance but is part of the new Event Template

    • Optionally, Resources are provided via client command parameter to use for added Resource Types (part of the new Event Instance)

    • Use the default scheduling type (i.e. postponed) if no Resource is provided as client command parameter for an added Resource Type

    • If 2 Resource Types of the same type are added, you must be able to provide 2 Resources as part of the client command parameters

    • Leave ad-hoc Resource Types in the Event Instance unchanged (selected Resource and time spans) if the Resource Type doesn’t exist on the new Event Template

    • No additional Resource Type can be added (ad-hoc) via client command parameter if the Resource Type doesn't exist on the Event Instance or Event Template already. All Resource Types specified in the client command parameter must exist either on the Event Instance or new Event Template

  • Update Resource Type if the same Resource Type exists on the Event Instance and on the new Event Template. 

    • That is, update the time spans only and leave any selected Resource as is

    • If a Resource Type is an ad-hoc Resource Type on the current Event Instance and the new Event Template contains that Resource Type, update the Resource Type’s time spans and leave any selected Resource as is (this means an ad-hoc resource Type is ‘converted’ to a ‘normal’ Resource Type)

    • If a Resource Type is ad-hoc and the client command parameter for that Resource Type is providing a Resource, update the Resource Type with the provided Resource only if no Resource was selected already (postponed, none)

• Output a list of Event Instances which were not changed and reason (missing requirement)

• Allow a ‘logOnly’ parameter on the client command which will simulate all changes made to the Event Instances but doesn’t make any changes to the real system. This will allow to test the effects of the command

For example:

• 20 BRM1 Events are scheduled via BRM1 Event Template throughout the year

• It is known that from July 20th 2016 the requirements of the BRM1 Events are to change and more simulator hours are required

• It should be possible to bulk update all BRM1 Event Instances on and after July 20th 2016 to use an updated Event Template BRM1_A

• Note: Only time spans are updated when switching the BRM1. BRM1_A Event Template must exist - all Resource Types, Resources and event length remain the same

Development Notes:

• An Event Instance has 3 different types of time spans

  • Event booking time spans (DefaultBookingTimeSpans)

    • All Resource bookings are grouped into days to form the Event Instance booking time spans - 1 time span pair (start/end) per day. For every day, take the earliest scheduled Resource’s start time span for that day and the latest scheduled Resource’s end time span. This will form the booking time span for that day. Because Resource time spans are updated, we need to update (recalculate) the overall booking time spans too. Take placeholders into account - i.e. if all Resource bookings are marked as placeholder for a day, the calculated time span is a placeholder too!

  • Event Template Default Resource Type time spans (DefaultResourceTypeBooking)

    • Every Event Template has default time spans for Resource Types. The default time spans are used if a Resource is scheduled for an Event Instance

  • Resource booking time spans (ResourceBookingTimeSpans)

    • Every scheduled Resource of an Event Instance has 1 time span per day. If a Resource of a Resource Type is scheduled, the time spans attached to an Event Instance’s Resource Type (ResourceBookingTimeSpans) is used. If no ResourceBookingTimeSpans exists on the Event Template, use the Resource Type’s default booking time spans 

• Make sure time span placeholders are handled properly

• Update a time span by replacing it, not just updating the item. Reason is to keep track of changes made to time spans. If feasible, add an audit entry to log an entry that the Event Instance has been switched to another Event Template

• A ResourceType has default booking time spans. The time spans are independent of an Event Template

• Updating a Resource booking time span may result in booking conflicts - the overlap in booking will autom. show up in the Scheduler. Conflicts are ignored and are NOT resolved when switching Event Templates - this needs to be done manually by CSMART

• Order of same Resource Types within an Event Instance/Event Template according to Id? Check with current UI how they get sorted. The order of multiple same Resource Types must be the same in UI and client command output as well as addressing the same Resource Type via client command parameter - make it deterministic (i.e. order by Id?).

From Module Selection

Similarly it should also be possible to bulk change the Resources for any set of Module Instances using some kind of selection and filtering system to set which Module Instances you would like to change for a specific Event.

Bulk changes will only be possible if Modules have shared Resource Types. For example:

• Module A has BRM1 instructor, Nils

• Module B has BRM1 instructor, Lars

• Module C has BRM1 instructor, Stefan

• It is decided Nils should be the instructor for all these Modules

• By selecting all these Modules it is possible to set Nils as BRM1 instructor for all of these

• It is clear that in order to do this the selected Modules must have a BRM1 instructor as Resource Type

This function is normally only used when changing Module Instances within a specific Event Instance and so it must be possible to bulk change Modules within an Event at the very least. 

It could also be possible to filter and select any set of Module Instances and bulk change these. This could be particularly useful when making changes when someone leaves the organisation or goes on vacation and it is necessary to replace Resources against all Modules for which they are scheduled to.

Collision Detection

When a Module Instance is published with Resources assigned to it, the system should detect whether there is any Resource collisions at that time and provide a warning for this. It should be simple to navigate to the relevant Module Instances and make adjustments if necessary.

Similarly if a Module is changed Resources collision detection should also be performed and warnings provided as necessary. This should happen whether the changes are through bulk or through a single Module change.

Participant Registration

Once an Event Instance is scheduled, participant registration will occur in the same way as the current Scheduler and LMS setup.

Views and Filtering

There should be a  view using a calendar view similar Outlook/Google Calendar. It should be possible to view daily, weekly, monthly time spans. 

It should be possible to filter the view to only show Modules with certain attributes e.g.:

• Location e.g Classroom 1

• Personnel e.g. Nils Borre

• Course e.g. BRM1 

Personnel Management

It should be possible to schedule personnel to Module Instances in order to manage their schedules and availability. 

It should be possible to set a category for this e.g. vacation, compensation, conference, mentoring onboard, other and it should be possible to add to this list of categories.

There should also be a place to capture a description of the Module i.e. what type of conference

These Modules can only be scheduled by an admin person following appropriate approval within CSMART. 

Notifications

When a Module Instance is Published, Personnel members allocated to the Module should be notified of the time, location and other Module information.

When a Published Module Instance is changed, or Unpublished any Personnel member allocated to the Module Instance should be notified of the change via email.

Further work is required on exactly what notifications need to be sent but the following are suggested:

• When start or end time changes all associated personnel are notified

• If an Event Instance changes from in-house to an external location, or from one external location to a different external location (not if it changes from one in-house location to another)

• Operating Line notifications stay the same as the current Scheduler configuration

• When a new Event is published the Event owner is notified

It should be possible to manually choose after an Event/Module Instance is changed whether a notification should be sent.

Existing system notifications will remain the same and continue within the new system.

Permission Levels

Permissions will be set as per the current Scheduler. These are:

• CSMARTAdmin

• CourseAdmin

• LineAdmin

• ExternalLineAdmin

• Viewer

• (new) Head of Department (can manage employees vacations, compensations etc and add/change instructors on Modules/Events that belong to their department)

History/ Migration

All changes should be logged.

If a Template is updated the system should  keep a copy of the old one but hide this from the Templates available for future scheduling.

When migrating to the new Scheduler system, past Events are not required however assessment data e.g. pass/fail for participants, should still be available. Times are not required.

Development Notes:

It may be the same effort to migrate future events and past events as it will be the same code migrating the data.

Move User between Operating Lines [spec in progress/discussion]

There are situations where a user moves to another operating line e.g. from AIDA to Costa. This person usually gets a new employee ID as well. CSMART should be able to move users between OLs themselves. Therefore, a UI is needed to let CSMART update OL and employee IDs for their users.

In addition, past participant assignment should retain the employee ID and OL at the time the user has been added to an event instance so reports display the correct (historical) data. 

Who can Update a User’s Employee ID and OL?

CSMART Admins only? OL coordinators see users from their OLs, so they may be able to move users between the OLs they are managing? Also update employee IDs?

Prerequisites - Add Employee ID to Participant Assignments

The current Scheduler doesn’t retain the employee ID for participant assignments at the time the user has been added to an Event Instance. Currently, the Scheduler reports use the current OL and employee ID of the user. For example, a participant completes a course with employee ID ‘A111’ in December 2017, and their employee ID is updated to ‘A222’ in March 2018. Running the reports after March 2018 would display the new employee ID ‘A222’ for the participant assignment from December 2017 - in fact it uses the new employee ID for all participant assignments of the user. This is true for OL changes as well.

To retain the OL and employee ID on participant assignments over time, every participant assignment needs to store the OL and employee ID individually. The OL is currently stored on every participant assignment, but the reports use the current user OL for display. The fix is to use the OL on the participant assignment. This would be an small change. However, the employee ID needs to be added to the participant assignment retroactively by using the current employee ID and assign it to all participant assignments (current, past and future).

Limitation to retroactively assign employee ID to participant assignments: It is not possible to correctly assign the employee ID to a past participant assignment IF the user’s employee ID has been updated since. All (incl. past) participant assignments will get the current employee ID of the user. This is also true if the user has moved to another OL. For example, a user was member of OL ‘A’ with employee ID ‘A-1’ at the time of event participation. Later on, the user moved to OL ‘B’ and got a new employee ID ‘B-2’. The past participant assignment would be retrofitted with employee ID ‘B-2’ during the data migration (=retrofitting all participant assignments with an employee ID). The reports would display employee ID ‘B-2’ but the OL would be OL ‘A’.

UI to Manage User Employee ID and OL

Introduce a new UI to ‘Manage Users’ in the Scheduler. The entry point to the new UI is a button on the main Scheduler page (like ‘Reports’) and only visible to CSMART Admins. 

The UI allows the following operations on users:

1. Update an existing employee ID and/or OL

2. Add OL and employee ID to existing users if they don’t have an OL and employee ID yet (i.e. resources)

3. Remove an OL and employee ID from a user

A user filter is provided to search for users via various user properties like first/last name, email address, employee Id, OL.

The search result of users is paged (similar to Core).

Optional features:

• Display the participant assignment count of future courses (event Instances which start tomorrow or later) for listed users. This would help to determine the impact of moving a user to another OL. Display list of current/future Event Instances (display name, start date?) per user

• Start/From date field to set an ‘effective’ date to specify which Event Instances should be updated with the new employee ID/OL

• Add an additional button ‘Manage Users’ in ‘Manage Participants’ to improve CSMART’s workflow

Notes:

Is it possible to update a participant directly? Employee ID only? 

Update of an employee ID will update all future (current?) participant assignments as well? Past participant assignments won’t be affected.

Process of Moving a User From one OL to Another

Remove an OL and employee ID is only possible if the user is not a participant in any future event instances (event instance start date > today). Already started event instances wouldn’t be affected.

Update an OL and employee ID is done for users who may have participant assignments for future event instances. Those event instances will need to be updated?

What should happen to the participant assignment if the Event Instance ...

• has remaining seats for the targeted OL?

  • Suggestion (Stefan): move to targeted OL allocation

• has no remaining seats for the targeted OL but the Open allocation has remaining seats?

  • Suggestion (Stefan): move to Open allocation for new OL

• has no remaining seats for the targeted OL and there is no Open allocation?

• has no remaining seats for the targeted OL and there are no remaining seats for the Open allocation?

• has remaining seats for the targeted OL but the current participant assignment is for the Open allocation?

  • Suggestion (Stefan): If possible always move to targeted OL before filling up the Open allocation

• has the participant on the standby list and the standby list of the targeted OL is full?

  • Suggestion (Stefan): over-fill standby list

• has the participant on the standby list and the standby list of the targeted OL is not full?

  • Suggestion (Stefan): move to standby list of new OL

For all of those scenarios, to which OL/Open allocation should the participant assignment be placed in the Event Instance?

What should happen to future participant assignments if the user’s employee ID is changed? Do all future participant assignments get updated with the new employee ID? If so, where would the update have an impact (i.e. reports)? 

Every OL move should report on what has been done exactly - list of all events and the corresponding action (i.e. move from OL A to OL B, move from Open (OL A) to OL B, move from OL A to Open (OL B), move from standby list OL A to standby list OL B,...).

Any already accepted participant assignment would remain accepted? Is it required to resend the invitation to the event?

Any CRS number (incl. hotel and flight information) will be transferred to the new participant assignment. 

The properties (employee ID and assigned by/assigned for) can be updated to transfer the participant assignment without the need to create a new participant assignment. Creating a new participant assignment potentially breaks data integrity if not properly implemented. For example, updating the existing participant assignment would ensure any Protel operating item referred to the correct participant assignment.

This is not part of any ‘Manage Participants’ because the participant is assigned to a specific OL for the event instance. Should the process be detached from ‘Manage Participants’?

Notify User About OL Move

What communication is needed to let users know that they were moved from OL A to OL B? 

Notes: 

Retaining the original user record is possible (and exists already) because every ParticipantAssignment keeps track of the OL the user has been assigned for. However, the employee ID would need to be added to keep a history of the ID. This means we need to add the employee ID to the participant assignment (EF migration).

Notes for Discussion:

A decision needs to be made how or if an employee ID may change over the course of OL changes. If an employee changes their OL (and employee ID) - what should happen to any participant assignments in the future? Update the employee ID on the participant assignments? How would be change the OL for the participant assignment (while complying to MaxSeats of the event instance?

In discussion with Carnival Corporation it is intended to introduce a Carnival wide unique employee ID for every user. Options like an OL prefix in front of the existing employee ID were discussed. If the employee ID format encodes the OL moving a user from to another OL with maintaining the same employee ID would make it not possible to read the OL out of their employee ID. 

Changing the employee ID when a user moves to a different OL would be more recommended. However, reports across OLs for a user may show multiple employee IDs for a user who moved OLs in the past but it would still be possible to aggregate the data since the user itself hasn’t changed (e.g. user Id, user name).

Once users are only imported via HR integration, creating a new user is not possible anymore in the Scheduler?

How would the Scheduler know when to move a user? Would this be a manual or automatic process? 

For example, a user upload from Aida doesn’t send the user who just moved to Costa and Costa would contain the moved user with same (?) employee ID. Processes would need to be put in place to move the user from one sub-org to another automatically as well. This also would mean that the Scheduler needed to be informed of the move as well somehow. The users need to be synced from Core to Scheduler after a user upload/update (via background thread/deferred action,...)

Duplicate Users

There should be a resolution for the ongoing problem in creating duplicate accounts. This is caused when an employee ID has an error and so does not appear in user searches, as such a new account is created even though the user already exists. The problem is resolved by deleting the account however this can lead to data problems later on. There should a way to either find the duplication before it is made or resolve the issue without causing data to be lost or inaccessible after it has been created.

In the long run - once every Operating Line has an HR integration into the LMS/Scheduler, it is not necessary to manually create any user. If a user can’t be found, HR needs to be contacted so the user is created during the next user synchronization.

This will change the direction how users are created in the Scheduler. After every user upload into the LMS a syncusers must be executed to add/delete/update any user in the Scheduler. Currently, users are only created in the Scheduler and then pushed into the LMS.

Intermediate Solution

Until all HR integrations are released we would offer a more sophisticated user search so duplicate users can be avoided more effectively. Once all HR integrations are released, there will be no need to create new users anymore. Until then, an extended user search is needed.

It should be possible to search for a user using wild-cards for it’s employee Id and/or email address, first/last names. This requires adding an extra step between searching for an existing user and selecting a user for an event. 

Also, the search may extend to look for matching users across all OLs? This would make OL coordinators aware that they may create a duplicate user?

Notes:

• Search for a user within the OL only?

  • If a new user with the same email address should be created but the existing user is assigned to a different OL - what should be done?

    • Change OL and EmployeeId before able to add that user to the event?

    • Allow change OL and EmployeeId within the ‘add participant’ UI? A button to move over the user?

    • What would happen to any of their other, future registrations for the old OL?

Participant Shuffling

Introduction

When participants undergo certain courses at CSMART there needs to be a balanced mix of ranks and experience among them. There has been much discussion on this subject over the last year, and it has become apparent that even though efforts have been made by operating Lines and Course Administrators the requirement for CSMART to move participants from one course in a week to another course within the same week of the same type (e.g. BRM 1) is still extant. 

Overall Requirement

Course Administrators (role: CourseAdmin) should be able to easily move a participant from one course to another of the same type running in the same week. This movement should be reflected in the course composition seen by the relevant Instructors on their Course Management Page and maintain any pre-course progress in the LMS course. It will change the participant’s attendance to a different offering but should not generate a new invitation to that participant to accept the destination course (note: no automatic notification is sent to the participant - all emails to the participant are sent manually). Changes should be visible to all users and reports and will reflect the new state of the world (LMS and Scheduler). This includes Operating Line coordinators who add participants, financial reports, instructors, and administrators. In effect, the change in course composition should only be apparent to Instructors and Administrators, with participants being informed directly by CSMART that their class and/or schedule has been changed. From the financial perspective it is no longer a requirement to reflect when an individual moves from course to course with all the associated tracking that would imply, and the following implementation should therefore maintain the required information on both Learning and Scheduler sides.

Requested Implementation

The moving of a participant from one course to another should be by means of a drag and drop interface within the Scheduler element of the LMS. It should be possible to display all participants for a particular course type (eg BRM2) in one week on a single page as set out below, and for the Course Administrator to reorder the participants at will, and then save the changes. 

This is expected to be a new page in the Scheduler which offers to select 2 courses (of the same course type) within one week.

To get to the shuffling page, an additional button for CourseAdmins (incl CSMART Admin)  will be provided in the week booking view. To the left of the ‘Edit’ button a ‘Shuffle Participants’ button will take the user to the shuffling page. This button is only available if there are at least 2 parallel courses (within 1 week) of the same course type (e.g. BRM 1). If only 1 course exists, no shuffling is possible and therefore no button is visible. 

The selected course will be used shuffling. The 2nd course on the page will be the next in line (ordered by name?). See Main Area for more details.

Shuffling Page - Footer Area

The footer area of the shuffling page contains a right aligned ‘Save’ (primary) button, and ‘Cancel’ or ‘Close’ button.

The ‘Save’ and ‘Cancel’ buttons need a confirmation dialog box.

If there are unsaved changes on the page, display ‘Cancel’ instead of ‘Close’.

Shuffling Page - Main Area

The main area of the page contains 2 courses of the same type side-by-side (e.b. BRM 1). If there are more than 3 parallel courses, a drop down list per side contains all published same type courses within this week. The user is able to select one course for display on either half. This makes it possible to shuffle participants between multiple courses. Switching between courses is only possible if there are no unsaved changes on the page by deactivating the drop-down menus.

Course View (1 Vertical Half of the Main Section)

The header section of a course contains the following information:

• Course name (= event display name)

• Date (from - to)

• Instructors (course offering instructor)

• Company (owner of the event). Use ‘-’ if no owner is set for this event

• Coordinators (Responsible/instructors)

• Information about how many seats are available per Operating Line and Max Seats. The seats count must update according to participants moved

  • The seats/max seats can be temporarily negative while moving participants. In this case the Save button must be deactivated

Visible columns per course (in this order and sortable)

• Rank

• First and last name (=display name)

• Company (=Operating Line)

• Sea Time (Service at Sea)

• OOW (=Officer of the Watch)

The participant lists are paged at 10 participants per page.

Ask Craig and Jeannie for mockups and design

Moving a ParticipantAssignment

Logic of Moving a Participant from one Course to Another

Moving participants between 2 courses may result into temporarily invalid state. Assuming the courses are fully booked, moving one participant will violate either allotted seats for an Operating Line or max seats of a course until another participant is moved back. This is to be expected since we need an ‘overflow’ to happen while moving participants between courses. 

The Save button is always available, even if this means going over the allowed seats per OL or per course. CSMART will take care that this doesn’t happen. A potential downside would be that the UI will contain negative seats due to overbooking.

The remaining seats per Operating Line (incl. Open allocation) is updated for every participant move to keep track of the balance. 

Rules for Moving ParticipantAssignments:

1. Shuffling must respect line assignment restrictions (remaining seats/max seats) per course (Note: CSMART didn’t need this feature - they will take care of the limits themselves)

2. Courses usually have a corresponding Operating Line. However, a participant can’t be moved to a course if the target course doesn’t have a corresponding Operating Line or Open allocation

3. Moving a participant of OL1 to a course which doesn’t have an allocation for OL1 but the 'Open' allocation, the user can be moved to the Open allocation if there is enough remaining seats

4. Moving a participant of OL1 to a course which does have an OL1 and Open:

   • Remaining seats for OL1 - move to OL1

   • No remaining seats for OL1 - move to Open

   • No remaining seats for OL1 or Open - don’t move

5. Moving a participant of OL1 from Open allocation to other event:

   • Remaining seats for OL1 - move to OL1

   • No remaining seats for OL1 - move to Open

   • No remaining seats for OL1 or Open -  don’t move

6. A participant must be moved into their Operating Line first if there are remaining seats left. If the Operating Line for the participant is full, only then, they would be moved into the Open allocation (if existent)

Background Implementation

There are multiple options how a participant is moved within the Scheduler and LMS. A rejected option by CSMARt won’t get described. A quick recap - the rejected option included re-registering the user in LMS losing all their pre-course progress. 

CSMART chose Option C.

Option A

This option would move the participant assignment in the Scheduler but will not affect their LMS course offering registration. This would ensure they maintain progress however the Scheduler and LMS would display different offerings. This would not require any additional work over the basic work required to shuffle participants.

Development Note: The course offering Id would need to be pushed into the ParticipantAssignment. The course offering Id on the event would remain so a new participant would be added to that offering.

Cons

LMS reports will display the old participant course offering and will not match up with the Scheduler reports

Option B

Currently, we create one course offering per event in the Scheduler - this gives CSMART a very fine grained reporting in the LMS (e.g. Grades (by student) Report) by event. 

The idea would be to collapse any course offerings of one course type (e.g. BRM 1) within 1 week (Monday-Sunday  according to start-dates of a course) into a single course offering. All participants would be registered in one course offering in the LMS. This wouldn't make any difference for the student in his Student Gradebook. The students would see the one course they participated in. However, the LMS reporting would have less entries - a single course offering for all parallel courses of one course type (e.g. BRM 1) and week (Monday-Sunday according to start-date of a course). 

The single course offering per week will have the benefit of being able to move any participant between same events in the Scheduler with maintaining their progress in the LMS because the participant's LMS registration remains the same.

Cons 

Lose some granularity in LMS reporting (one offering per week and course type).

This will cause more development work on the Scheduler as initially anticipated and will be reflected in the final estimates.

Example

• ERM2 Day A HaGrpUk (Mon 10, Jul - Fri 14, Jul)

• ERM2 Day B CMarGrp (Mon 10,  Jul - Fri 14, Jul)

• ERM2 Morning A HaGrpUk (Mon 10,  Jul - Fri 14, Jul)

• ERM1 Day B CMarGrp (Tue 11, Jul - Sat 15, Jul)

• ERM1 Morning B HaGrpUk (Mon 10,  Jul - Fri 14, Jul)

The current LMS would have 5 course offerings - one per event.

The new implementation would have 2 course offerings in the LMS - one per course type

2017-W27-ERM1-00 and 2017-W27-ERM2-00

Additional Development Work (Scheduler)

This is a change in how the Scheduler works and would need some refactoring/migration:

• Update naming algorithm for the course offerings to be able to generate new and old event names (in case an 'old' event is edited - e.g. event owner) according to a cut-off date (release date?)

• Find weekly course offering when creating a new event (considering old events may still exist)

  • If an event of this course type already exists within this week, use the same LMS offering

  • If no event of this course type exists, create a new LMS offering for this week

• Migration of existing events in the future and collapse all participants into one weekly course offerings (re-registering) via client command. An event start date must be set to convert every event after that date (one time use on release)

• Remaining (old) courses won’t change because it would delete all LMS course progress of all participants. Therefore, we will have 2 code paths - old and new. Code for old courses (from a specific cut-off date?) will use the old style of updating a course offering. 

  • Note: because the event has a reference to the LMS course offering, this shouldn’t be too difficult and only affect editing existing events. New events are always generated the new way.

  • Participant Shuffling may be only available for ‘new’ courses with one weekly LMS offering since moving a participant would require an LMS re-registration.

Option C (chosen by CSMART)

Everything will remain the same (one LMS offering per event) except we would copy over the LMS registration (incl. Progress and audits) into the new course offering if a participant is being moved in the Scheduler.

Cons 

This will cause more development work because of some additional LMS work.

Activity dates will have shifted dates. We audit many user activities in the LMS. Copying LMS progress from one registration to another will set the activity date to the date when the participant has been moved. 

Additional Development Work (LMS)

• Create new registration in new LMS offering

• Copy audit entries to the new registration

• Delete old registration

Affected Scheduler Systems/Features

Some of the changes for Participant Shuffling may affect other features in the Scheduler - a few notes discuss potential dependencies and therefore some work/thought involved to adapt the existing features.

Hotel Protel Integration

Moving a participant assignment must maintain any potential CRSNumber (= hotel reservation Id). This is done by moving instead of deleting and re-creating a copy of the ParticipantAssignment to the new course/event in the Scheduler.  The ParticipantAssignment move won’t trigger any Protel update via commit handlers (triggers on Check-in-/-out, hotel details properties only).

Development Note: Investigate if a participant can be easily moved from an Operating Line Detail to the Open Allocation without re-creating the ParticipantAssignment. The Open Allocation has a slightly different structure than regular Operating Line Details. Therefore, commit handlers may do some work if a ParticipantAssignment is deleted or created (e.g. cancel/recreate hotel reservation).

eSeaCare Sign-on/-off Integration

This is a potential system integration into eSeaCare Clinic. If, at the point of Participant Shuffling development, this integration is released, the following should be taken into consideration.

Moving a ParticipantAssignment between courses may impact the sign-on/-off dates in eSeaCare. However, the move is within a week and overlapping courses. There is a chance that the course theoretically start on a different day within a week (shifting the sign-on/-off by a day or so). This will cause an update of the participant’s sign-on/-off date. 

There is very little risk that this will have an actual impact on the sign-on/-off dates because the participant has already signed-on 7 days ahead of the course start. We still need to keep the sign-on/-off dates up to date and therefore recalculate the dates for the moved ParticipantAssignment.

Links to Old Documents

• https://docs.google.com/document/d/1hkGNfccxGCkUHcKpjua5FYoxetTduxyPJtXaQBhV0zI/edit

• https://docs.google.com/document/d/111G6QecuReLUsGitRtD-V-JH04-VWqleuxoA7tMuP0c/edit#

• https://docs.google.com/spreadsheets/d/1WfQNgVjBw_jjpBGJWqKjhQ6trFMYQ2VgLSwCmXun71c/edit#gid=1678284912