IdStory Identity Manager

Another possible way of configuring access to different providers of sms gateways would be to let administrators implement sending of sms via groovy script. This however could bring more complications for example with providing of credentials which would probably have to be stored inside of said groovy script. Another drawback of this approach is that it requires a lot of coding in groovy just to be able to send sms.

To be honest I would rather prefer not to put logic that is specific only to certain sms gw provider inside of core module. It would be much better if there was some way to dynamically (to some extent) provide adapters for different providers that can be just dropped as jars inside of tomcat and which will register itself and be available for user to choose in UI.

Sadly I dont know about any other way to do it than by using some sort of pub-sub model which leads to developing of new module for each provider. If any of you has better idea please comment, because I cant think of something better.

The main issue with this (as I understand it) is having to repackage whole application just to add another api support for sms providers.

1. in custom (or core) module: create custom / default sms notification sender implementation (type="sms")
2. in core: add new configuration to notification types (new agenda or configuration service usage) - choose sender implementation for notification type and use this configuration in NotificationRouteBuilder.routes. FE agenda could work the same as AuthorizationPolicy detail - after notification type selection senders could be found, which support selected type. Agenda could be added under notification configuration (split configutarion to two horizontal tabs).

I could prepare the second point, if this design will be ok.

I am almost finished with dto refactoring. Last thing to do besides some cleanup is to show notification recipients when listing all notifications. Problem is, that the mapper only maps collections if trimmed is not set to true and method AbstractReadDtoService.toDtos sets trimmed for all dtos? So there are basically two options. First is to fetch all notifications one by one so that the recipients collection will be present in the result, or change mentioned method so that it wont trimm all collections, or at least make it configurable in some way, because fetching recipients for all notifications one by one would be horror in my opinion.

I have pushed dto refactoring code in psourek/smsNotification with resolved conflicts and rebased on current develop so it is prepared for merging. There is an issue to resolve which i consulted with Radek and it is space/tab indentation. It seems that my commit has lot of formatting changes which will be very tedious to check.

I think that it would be best to check the code differences ignoring whitespace changes (git diff -w psourek/smsNotification develop).

After we decide what codestyle we want tu use, then we will format the code so it will be consistent throughout whole project. I dont think that it would be wise to run it now on my branch because it could potentially lead to more conflicts.

I have finished implementing sms notification support in branch psourek/smsNotification. Please review the changes and give me feedback. After consulting this with Radek we decided that FE agenda for selecting sender for each notification channel will be implemented later on in separate ticket, because it is not needed right now.

I updated documentation for sms in https://proj.bcvsolutions.eu/ngidm/doku.php?id=en:navrh:notification