Hi everyone,

I have also this requirement for a big french client and I will probably
have it for another one in the near future both are international and they
have to adapt their communication channels to the country's uses.

Users can have email or mobile or both or a specific channel (we need a
fallback when the claim is not filled)
Each country can have a different provider to send messages.
Platform owner want to fix specific channels for some type of notifications
and leave others to the users' choice.

If your implementation can address this kind of use cases it could be great!

Thanks,

Le mer. 29 mai 2019 à 07:53, Hasanthi Purnima Dissanayake <[email protected]>
a écrit :

> Hi Johann,
>
>
>>>    - Provide a way for the user to dynamically change the selected
>>>    preferred communication channel. IMO this is the most practical way in
>>>    users perspective.
>>>
>>> This can be solved with user claim as described earlier.
>>
>
> Sorry for the confusion. Seems I have not explained well what was in my
> mind. :)
> What I meant here is we should be able to change the preferred
> communication based on the scenario. As an example, user can select SMS or
> Email as the channel in a password recovery flow. So, in each flow, users
> can select the channel. I think storing the preference value in a claim
> here is not mandatory. But yes we can give a better user experience if we
> store it. So the flow in my mind is like below.
>
> If we use a claim value to store :
> 1. User update the preferred communication mechanism in his user profile
> 2. In the UI for the  preferred communication mechanism the default
> values will be selected based on the user profile value.
> 3. The user can change the preferred communication mechanism value in the
> flow based on the scenario.
>
> As we have stored the value in a claim the default value will be displayed
> according to the user preference, so he can re-use it or change it. The
> importance of displaying the options is the user can update the channel
> by selecting the channel in each flow rather than going to the user
> profile and updating it.
>
> Thanks,
> Hasanthi
>
> On Wed, May 29, 2019 at 10:34 AM Johann Nallathamby <[email protected]>
> wrote:
>
>>
>>
>> On Wed, May 29, 2019 at 10:21 AM Hasanthi Purnima Dissanayake <
>> [email protected]> wrote:
>>
>>>
>>>
>>> On Tue, May 28, 2019 at 11:10 PM Isura Karunaratne <[email protected]>
>>> wrote:
>>>
>>>> Yes.
>>>> Currently, we don't have a way to select the user's preferred
>>>> communication channel. This is a good improvement to the product.
>>>> Introducing a claim to store user's preferred channel is not enough to
>>>> support full functionality over the SMS channel.
>>>> If the user's preferred channel is SMS, we need to improve some
>>>> features such as Password Recovery, Self Registration, Ask Password, Email
>>>> verification to send OTP instead of a confirmation email link for the
>>>> better user experience.
>>>>
>>>>
>>>>
>>>  Hi All,
>>>
>>> This looks like a feature improvement and +1 to add this feature to the
>>> product. When defining the preferred communication channels, I think this
>>> can be achievable in two ways.
>>>
>>>
>>>    - Provide one time global configuration. Once a user select the
>>>    preferred communication channel it can not be changed in the middle and 
>>> the
>>>    user needs to use the configured channel for  all the paths
>>>
>>> I didn't understand what you meant by global configuration. But anyway
>> the requirement is to allow the user to change it in the middle. So this
>> won't work.
>>
>>
>>>    - Provide a way for the user to dynamically change the selected
>>>    preferred communication channel. IMO this is the most practical way in
>>>    users perspective.
>>>
>>> This can be solved with user claim as described earlier.
>>
>> Regards,
>> Johann.
>>
>>
>>> Thanks,
>>> Hasanthi
>>>
>>>
>>>>
>>>>
>>>>
>>>>> On Thu, May 23, 2019 at 3:48 PM Asela Pathberiya <[email protected]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, May 23, 2019 at 3:00 PM Johann Nallathamby <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> *Problem*
>>>>>>>
>>>>>>> IS currently supports different types of communication channels in
>>>>>>> the products with the use of output event adaptor such as Email, SMS, 
>>>>>>> HTTP,
>>>>>>> etc. However currently there can be only one channel selected for a 
>>>>>>> given
>>>>>>> deployment based on the configuration.
>>>>>>>
>>>>>>> We have a customer requirement to select either Email or SMS channel
>>>>>>> based on user preference.
>>>>>>>
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> I actually assume that this is already  in the product.  It is
>>>>>> remembered that  we could send the notification type in the API request.
>>>>>> Isn't it ?
>>>>>>
>>>>>> If it is not, we need to have this capabilities.
>>>>>>
>>>>>> Thanks
>>>>>> Asela.
>>>>>>
>>>>>>>
>>>>>>> *Solution*
>>>>>>>
>>>>>>> Previously +Harsha Thirimanna <[email protected]> implemented the
>>>>>>> DefaultNotificationHandler to support different output event streams to 
>>>>>>> be
>>>>>>> chosen based on the scenario of the notification. I think we can extend
>>>>>>> this further to select the output event stream based on scenario as 
>>>>>>> well as
>>>>>>> user's preferred communication address. We can introduce a new reserved
>>>>>>> claim for user's preferred communication address.
>>>>>>>
>>>>>>> Can we confirm this approach unless there is a better way of doing
>>>>>>> this?
>>>>>>>
>>>>>>> Thanks & Regards,
>>>>>>> Johann.
>>>>>>>
>>>>>>> --
>>>>>>> *Johann Dilantha Nallathamby* | Associate Director/Solutions
>>>>>>> Architect | WSO2 Inc.
>>>>>>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [email protected]
>>>>>>> [image: Signature.jpg]
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thanks & Regards,
>>>>>> Asela
>>>>>>
>>>>>> Mobile : +94 777 625 933
>>>>>>
>>>>>> http://soasecurity.org/
>>>>>> http://xacmlinfo.org/
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Johann Dilantha Nallathamby* | Associate Director/Solutions
>>>>> Architect | WSO2 Inc.
>>>>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [email protected]
>>>>> [image: Signature.jpg]
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Isura Dilhara Karunaratne*
>>>> Technical Lead | WSO2 <http://wso2.com/>
>>>> *lean.enterprise.middleware*
>>>> Email: [email protected]
>>>> Mob : +94 772 254 810
>>>> Blog : https://medium.com/@isurakarunaratne
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>>
>>> Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc.
>>> (m) +94718407133 | (w) +94112145345  | Email: [email protected]
>>>
>>>
>>
>> --
>> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
>> WSO2 Inc.
>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [email protected]
>> [image: Signature.jpg]
>>
>
>
> --
>
> Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc.
> (m) +94718407133 | (w) +94112145345  | Email: [email protected]
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Gregory EVE
[email protected]     - +33 1 41 40 88 04 / +33 6 22 95 95 34
Architect                         - Technical Office
Smile - I.T is open          - http://www.smile.fr
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to