On Mon, Jun 3, 2019 at 1:05 PM Asela Pathberiya <[email protected]> wrote:
> > > 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 ? >> > > > Identity mgt API supports something called notificationType [1]. Based > on the type, notification module would be selected dynamically . Default > module was the email. This was there from the beginning, Can't we use it ? > This is the old identity-mgt implementation isn't it. This implementation and the corresponding notification modules are deprecated now. We moved to the new identity management implementation and CEP based output event adaptor framework from IS 5.3.0 onwards which is more flexible and capable. Regards, Johann. > > [1] > https://github.com/wso2-attic/carbon-identity/blob/v5.0.7/components/identity-mgt/org.wso2.carbon.identity.mgt/src/main/java/org/wso2/carbon/identity/mgt/services/UserInformationRecoveryService.java#L142 > > Thanks, > Asela. > > >> >> 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/ >> > > > -- > 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]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
