Add mobilePhone as contact detail type #5

Activity

1. gerardpeters

   added

   enhancementNew feature or requestNew feature or request

   on Mar 15, 2021
2. bmeesters commented on Mar 22, 2021

   

   bmeesters

   on Mar 22, 2021

   Last edited by bmeesters

   Contributor

   More actions

   Thanks for your contribution @gerardpeters.

   We are wondering how exactly you want to use this information? Note that it is currently possible to provide multiple contact-details and use the same type of contact detail with a remark. See this actor for example:

   {
     "id": "3f80d380-ca82-495a-9d66-5b220cd293e3",
     "contactDetails": [
       {
         "value": "0612345678",
         "remark": "mobile",
         "type": "phone"
       },
       {
         "value": "0118123456",
         "remark": "landLine",
         "type": "phone"
       }
     ]
   }
   

   This is of course not ideal if you need to know exactly what kind of phone you are using since it might contain typos, and you might want to use the remark for something else as well. But that is really only a problem if you are expecting to act on this information automatically.

   We could also consider adding a few sub-types of the contact-detail type, such as a phoneType and emailType. However this will likely result in another union type to avoid having an emailType on a phone contact detail.

   Maybe if you provide us with some more information on your use case we can look at the alternatives?
3. gerardpeters commented on Mar 25, 2021

   

   gerardpeters

   on Mar 25, 2021

   Author

   More actions

   We use the mobile number to send automated text messages based on the status of a consignment or events that are happening. We also have to ability to send text to voice messages to a landline. Because these messages are more expensive and not everybody wants to use this feature we need a clear distinction between the types of phone numbers.

   Mapping based on magic strings (remark) is far from ideal since we cannot enforce a value based on the scheme. Whereas the type as enum has an enforcement.
4. bmeesters commented on Mar 25, 2021

   

   bmeesters

   on Mar 25, 2021

   Contributor

   More actions

   Yes I agree, for such an advanced use case a magic string is not sufficient.

   I think the best way forward would be to identify types per contact detail. So the phone contact detail has a phoneType that exists of an enum with landLine and mobile (and potentially more in the future).

   Is this acceptable for you?
5. gerardpeters commented on Mar 25, 2021

   

   gerardpeters

   on Mar 25, 2021

   Author

   More actions

   That would work, I'm not really sure if that change can be backwards compatible with the current model, but if that's the case I'd like to see this in a future version!
6. bmeesters commented on Mar 26, 2021

   

   bmeesters

   on Mar 26, 2021

   Contributor

   More actions

   If the new fields are optional the JSON will be backwards compatible, though the OpenAPI specification needs to change a bit to make it possible. Need to check to be sure though. I'll make this suggestion will be discussed again at the next meeting.
7. bmeesters

   added

   OTM 5.1This ticket is included in OTM 5.1This ticket is included in OTM 5.1

   on May 27, 2021
8. bmeesters commented on May 27, 2021

   

   bmeesters

   on May 27, 2021

   Last edited by bmeesters

   Contributor

   More actions

   @gerardpeters, sorry to get back to you so late. We had another discussion and will go with your original approach (so add a new contact detail option). It will be included in OTM5.1 (next Tuesday)
9. bmeesters commented on Jun 1, 2021

   

   bmeesters

   on Jun 1, 2021

   Contributor

   More actions

   Closing this as it is now official part of OTM5.1
10. bmeesters

    closed this as completedon Jun 1, 2021
11. bmeesters

    added this to the OTM 5.1 milestone on Feb 7, 2023