search

cph-cachet / carp.core-kotlin

Infrastructure-agnostic framework for distributed data collection.
https://carp.cachet.dk/core/
MIT License
21 stars 3 forks source link

Add Social Security Number as Input Data Type #451

Closed bardram closed 8 months ago

bardram commented 1 year ago

We need to support SSN - like the Danish CPR number.

It should just be a string IMO.

Whathecode commented 1 year ago

If all you need is a string, you could just add it as a custom participant attribute to the protocol.

As we discussed in person, there may be a requirement to still have full control over the data type name. I will check whether the custom suffix and uuid are essential for things to work or not. I think it may just be API convenience, in which case it already should work now if you provide the right JSON payload.

Whathecode commented 1 year ago

The current constraints for participant data are managed upon protocol creation, and whenever the "expected participant data" is set. The logic for this lives in ExpectedParticipantData.kt:

Determines whether the set contains any of the following conflicts:

  • contains differing participant attributes with the same input data type
  • contains multiple attributes of the same input data type which are assigned to the same role

As long as the input data type is unique, there should thus be no problem. When you set the expected participant data, you have to pass the InputElement by using CustomParticipantAttribute instead of DefaultParticipantAttribute. Default denotes the input element and validation is known at compile time; "custom" implies it isn't and thus needs to be specified at runtime by the one configuring the protocol.

I see that there is no integration test covering this, and thus also no example JSON requests generated for this. I will add this to clarify usage.

In addition, the Kotlin API currently doesn't allow to specify the InputDataType for CustomParticipantAttribute; it generates a unique ID in the format of dk.cachet.carp.input.custom.9004a473ce624c49bcec34a238174118. This is by design to protect the dk.cachet.carp.input namespace, but maybe is overly strict. The main goal here is to not pollute dk.cachet.carp.input with types for which support may be added later on, which would cause conflicts when comparing/handling data. E.g., if you use dk.cachet.carp.ssn now, but support gets added at with a stricter/different format. I think a suitable compromise is to allow you to set your own InputDataType, but restricting access to dk.cachet.carp sub-namespaces. @bardram Would this serve your need?

Whathecode commented 1 year ago

I see that CAMS already uses the same namespace for data types.

That's something we overlooked, and ideally would have been a CAMS namespace. If core were to add any of these, backwards compatibility will break.

Maybe I should disallow custom types in carp namespaces, but provide an option to disable that constraint for backwards compatibility.

Whathecode commented 8 months ago

Closing this issue, as currently CustomParticipantAttribute fulfills the use case. #453 provides an example on how to use this.