On Mon, Jun 3, 2019 at 2:45 PM Johann Nallathamby <[email protected]> wrote:
> > > 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. > Yes it is fine. But It was great if we could think of the older API capabilities when it is being implemented the new API. Say; if someone was using this feature in 5.1.0 how does user migrate to newer implementation in new versions ? IMO; we need to prioritize & implement this in to the product soon. Thanks, Asela. > > 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] > -- Thanks & Regards, Asela Mobile : +94 777 625 933 http://soasecurity.org/ http://xacmlinfo.org/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
