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 <joh...@wso2.com> wrote:

>
>
> On Wed, May 29, 2019 at 10:21 AM Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>>
>>
>> On Tue, May 28, 2019 at 11:10 PM Isura Karunaratne <is...@wso2.com>
>> 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 <as...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, May 23, 2019 at 3:00 PM Johann Nallathamby <joh...@wso2.com>
>>>>> 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 <hars...@wso2.com> 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) joh...@wso2.com
>>>>>> [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) joh...@wso2.com
>>>> [image: Signature.jpg]
>>>>
>>>
>>>
>>> --
>>>
>>> *Isura Dilhara Karunaratne*
>>> Technical Lead | WSO2 <http://wso2.com/>
>>> *lean.enterprise.middleware*
>>> Email: is...@wso2.com
>>> Mob : +94 772 254 810
>>> Blog : https://medium.com/@isurakarunaratne
>>>
>>>
>>>
>>>
>>
>> --
>>
>> Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc.
>> (m) +94718407133 | (w) +94112145345  | Email: hasan...@wso2.com
>>
>>
>
> --
> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
> WSO2 Inc.
> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
> [image: Signature.jpg]
>


-- 

Hasanthi Dissanayake | Senior Software Engineer | WSO2 Inc.
(m) +94718407133 | (w) +94112145345  | Email: hasan...@wso2.com
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to