Support for putting the system or individual data collectors in training mode

[einari]

When starting up in a new country it is important to be able to use the system as close to the real world for testing by the users who will be registering and verifying data.

One way of doing this could be to have for every country - 2 databases; one for the actual production and one for the training purpose. The implication of this is that one needs to be able to send SMS messages to both systems in one way or the other; for instance have a specific telephone number for training purposes and one for the production environment. The hardware boxes being tested now; SMS Eagle and the Cisco 809 has dual SIM cards and has an identifier being sent which SIM a text originates from. Leading to an easy way to identify this.

Another option is to have one environment and mark the users as in training mode and have all their data registered as something that is "deletable". The implication of this is to develop specific support for this as a feature - it affects user management and volunteer reporting as bounded contexts.

The advantage of option 1 is that we need a way to register multiple countries - once that mechanism is in place - the "shadow" system for a country is just another "country", even though its configured as the same - just a shadow where nothing of the data is being used.

There might be other options here as well - but these are the ones we discussed on the core-team meeting 9th of May 2018. There will be a follow up discussion on this - and please feel free to engage in this issue as well with ideas and input into this.

[Velcrow81]

Difficulties in duplication of sms hardware (one device can only send info to one endpoint), double registration of data collectors (one for training and one for prod) and possible confusion for data collectors when interacting with multiple sms numbers puts option 2(mark as training) in the lead (discussed in sync meeting on 16th of May 2018).

One possible solution to solve this is to introduce new events called:

• DataCollectorBegunTraining
• DataCollectorCompletedTraining

This could be used to ensure that case report read models allow filtering on training reports and they can also be stopped from affecting other bounded contexts. This also allows training to occur multiple times with periods of live data in between.

To allow this we also need a new type of event for reports when they are verified (and possibly an event for rejected case reports with a reason for rejection). Case reports should not be available for i.e. alerts when they are recieved. They must first be verified by a data verifier. This could of course be automated if the data collector is trusted or experienced. The verification logic can then automatically prevent case reports sent during a training period from beeing verified. Other bounded contexts that only care about verified case reports will be blisfully ignorant of everything training related.

Should all data collectors be set in traning as default when registered? Im thinking yes

What do you guys think? @einari? @karolikl ? @aninek ? @eprom ? @alexanderhoset ? @woksin? @jakhog ? @dageirikboe ?

[Velcrow81]

It should also be possible to quickly filter data collectors on training status, so its easy to find those that are beeing trained when they are to be marked as completed with training

[alexanderhoset]

@aninek agreed that this will only be in volunteerReporting scope and not got generate alert events

[karolikl]

@aninek will update us on the terminology for the "verified" / "valid" case reports (as valid/verified cannot be used, but in this case we mean case reports that should trigger alerts etc.).

[alexanderhoset]

In this case we will for example have

• VerifiedCaseReports - new name needed
• TrainingCaseReceived
• DataCollectorBegunTraining
• DataCollectorCompletedTraining

[aninek]

Could we use 'training' and 'live'? 'training' reports being for all those SMS reports sent while the data collector was marked as 'in training' (could potentially time this to be first 48h after registration = in training = all SMS reports sent during that time 'training reports'. When a data collector is marked as 'active/live/no longer in training' the SMS report is 'live'. A filter should be added for 'training' and 'live' and same for export options. (default view to hide 'training' in vol reporting).

[smithmx]

You can certainly add an "IsTraining" state to a DataCollector which can be turned on and off. You can then have different types of case report (Training, Real) and a flag on the ReadModel whether it is training or real. Conceptually this is straightforward enough, but I think the "IsTrainingCase" flag will cascade through the entire system.

I think it would be better to establish what you actually want to do with the Training reports. Is it just to train the DataCollector in the use of the mobile phone and the format used? If so, then put the incoming report into a completely separate aggregate / event / read model that is nothing to do with the normal case report flow. Create a view that the trainer can look at and you isolate the whole thing to the one incoming case report step - sms is received, check if they are in training, if so, into the training flow, otherwise normal. I'd also suggest you probably want to create administrative stuff like ConvertTrainingReportToLive and CovertLiveReportToTraining to deal with errors - the DataCollector was in the wrong mode.

[Velcrow81]

Good idea @smithmx :)

Is there a built in way in DoLittle to handle background task policies like "if a data collector has been in training for more than 48 hours, deactivate training"?

I suggest the following issues based on the discussion above:

Issue 1: Add two new events: DataCollectorBegunTraining => Sets a flag InTraining to true and LastTrainingBegunAt to time in event DataCollectorCompletedTraining => Sets InTraining to false

Issue 2: Add new event: TrainingCaseReportRecieved Keep all existing logic that deals with invalid reports and unknown data collector, but emit TrainingCaseReportRecieved instead of CaseReportRecieved if data collector is InTraining. Suggest new read models that only show training reports. Training reports should not show up in existing read model for cease reports. Use same aggregate.

Issue 3: Create UI to list Training reports. Might borrow from real report list

Issue 4: Create policy that will put newly registered data collectors in training mode. Is this the way to go @smithmx or would it be better just to set default values during registration?

Issue 5: Create policy that will emit DataCollectorCompletedTraining if its been more than 48 hours since training begun

Issue 6: Add events ConvertTrainingReportToLive and CovertLiveReportToTraining, and the necesary logic that converts one report from one to the other

Issue 7: Create UI that allows for convertion of reports

This will keep training reports away from the rest of the system, while still alowing volunteers to use the same number and formats as they will do live.

What do you think @einari? @karolikl ? @aninek ? @alexanderhoset ?

[smithmx]

There's nothing built in as yet, though this is planned for Policies.

There are a number of ways we can do it. I would suggest the easiest way is to use one of the scheduling libraries to schedule a recurring task that periodically checks the "time in training" and issues a CompleteTraining command to DataCollectors who have been in training >= 48hrs and satisfy whatever other criteria (e.g. have sent X training messages successfully).

Time passing can be an important "event" in a domain when it has some real meaning - new day/ month/quarter, transition to "out of hours", etc. . I don't think this use case justifies that kind of modelling.

[Velcrow81]

Thanks @smithmx :)

I think we have enough now to model this in the upcomming event storm session

[Velcrow81]

@aninek, @einari : Should we also create events that say that a case report or training case report should be deleted (from read models). Maybe DismissCaseReport or RemoveCaseReport or RejectCaseReport? This should be emited when we convert i.e from training to live. Then a RejectTrainingCaseReport and a CaseReportRecieved whould be emited. What do you think? Anyone else?

[gardnk]

Fixed in #1180