Need to know when there is no data vs. officer did not try to get data

[o-fish-wildaid]

Sometimes there just is no data for a field - like when a crew member does not have a license number. Because of these cases the office would like to be able to check a 'none' checkbox so that the app knows there is no data for that. Data marked as 'none' should validate and not warn that it is empty.

See basic design as per https://mongodb.invisionapp.com/share/RWX43EEF567#/screens/415937331_Boarding-Vessel-Name and the document at https://docs.google.com/document/d/1rDXmdlB3lfqAb7uAhR1u96LbyNaUyl3_2t2O_C0kI_E/edit#bookmark=id.ua1q0ri03hpz has all the screens and what fields should have checkboxes vs. not.

[am-MongoDB]

Need to know whether these flags need storing in the Realm objects – that way they'd be remembered when you came back to work on a draft report - the down side is that the Atlas document will be cluttered by all of these flags

[Sheeri]

I'm assuming your vision of the schema with flags is something like this:

    "vessel" : {
        "homePort" : "London",
        "name" : "Jenny",
        "nationality" : "United Kingdom",
        "permitNumberBlankOnPurposeFlag" : True
        ]
    },

and so there would either be a permitNumber, or a flag. And those flags would be noise once a record is saved.

What if we had an array of flags, something like:

{
        blankOnPurpose: ['vessel.permitNumber', 'vessel.ems.registryNumber', 'crew.2.license'], etc.
    "_id" : ObjectId("5f22bb785f5ad3f4d4d"),
    "agency" : "WildAid",
    "vessel" : {
        "homePort" : "London",
        "name" : "Jenny",
        "nationality" : "United Kingdom"
        ]
    },
...
}

That gets complicated when you have arrays like crew, but it shouldn't be too crazy to parse.

Or the array can be something like: blankOnPurpose: [ { vessel: {permitNumber: true, ems: {registryNumber: true} } }, {crew: [ '', '', 'license']} ] That way the clutter is in one place as opposed to spread about.

[am-MongoDB]

Because of the way Realm sync currently works, I think that you'd have the flag and the empty attribute in the Atlas document (I'll do some experiments to confirm).

Going for an array of flags means that each of the views would need to have access to the top-level report object rather than just the sub-object they would otherwise work on - not a disaster but not encapsulation/reuse best-practice. I also think that arrays of arrays of flags would get complex and be open to bugs that lead to them becoming inconsistent with the field data.

Including "UI sugar" in the model feels a bit wrong. The exception would be if supervisors (or prosecutors, etc.) wanted to see that an officer explicitly indicated that there was no permit number

[am-MongoDB]

Confirmed (for iOS at least) that if a flag is in the Object class then it is written to the Atlas document regardless of whether it's set or not (set to nil). This means that permitNumberBlankOnPurposeFlag will appear in every document, even when the permit number has been set. In the attached, draft was an optional in the iOS class and set to nil

[Sheeri]

Given the complexity of this functionality along with drafts, we are going to stop work on this functionality and leave it out for now.

Thanks everyone for the work you've already done on this.