Hi, I also see a need to be able to configure how we deal with (repeated) alerts over time. If the data is not changed the alert will be re-created every night as it is right now, correct?
I have some ideas for improvements, but would be good to hear what others are thinking here. - should we have some kind of status on the alert, to turn it off or "snooze (1 day, 3 days, 7 days etc.)" that the alert recipients can update? - should we allow the pre-configuration of how alerts are repeated? -e.g. send again after 1,3,5,7,10 days if data has not changed. - should we allow for pre-configuration of escalating alerts where new user groups are alerted if the alert is not "resolved"? E.g. (just an example): <1st> (0 days) alert to <district surveillance officers>, <2nd> alert after <7> days to <province surveillance officers>, <3rd> alert after <12 days> to <national surveillance officers> Ola ----- ---------------------------------- Ola Hodne Titlestad (Mr) HISP Department of Informatics University of Oslo Mobile: +47 48069736 Home address: Eftasåsen 68, 0687 Oslo, Norway. Googlemaps link<https://maps.google.com/maps?q=Eftas%C3%A5sen+68,+0687+Oslo,+Norge&hl=en&ie=UTF8&sll=59.893855,10.785116&sspn=0.222842,0.585709&oq=eftas%C3%A5sen+68,+0687+Oslo,+&t=h&hnear=Eftas%C3%A5sen+68,+%C3%98stensj%C3%B8,+0687+Oslo,+Norway&z=16> On 13 March 2014 09:13, Prosper BT <ptb3...@gmail.com> wrote: > Thanks Guys, > > I think the role was also affecting its use, I go for user groups. > > Regards > > > On Thu, Mar 13, 2014 at 11:12 AM, Lars Helge Øverland <larshe...@gmail.com > > wrote: > >> Good. I would say lets change to groups, not too many are using it still. >> >> Lars >> On Mar 12, 2014 6:44 PM, "Jim Grace" <jimgr...@gmail.com> wrote: >> >>> An option to configure this per validation rule group sounds fine. In >>> the interest of not making this too complicated for the user, would it >>> better to leave it with roles (optionally restricted within the org unit >>> hierarchy), or change the implementation from roles to user groups >>> (optionally restricted within the org unit hierarchy). >>> >>> Of course we could support both roles and user groups, but I'm just >>> trying to see if we can keep it simpler for the user. >>> >>> Cheers, >>> Jim >>> >>> >>> >>> On Wed, Mar 12, 2014 at 1:11 PM, Lars Helge Øverland < >>> larshe...@gmail.com> wrote: >>> >>>> I think the suggestion from Jim is good. Could it be configurable by >>>> validation rule group? So we have a true/false option "send alerts to users >>>> within hierarchy only" or similar on the validation rule group. Then >>>> messages only goes out to users who have the originating org unit of the >>>> alert in their sub-hierarchies. >>>> >>>> I think in general having user roles and not user groups was a (my) >>>> mistake - we could simply change it. >>>> >>>> regards, >>>> >>>> Lars >>>> >>>> >>>> >>>> On Thu, Mar 6, 2014 at 8:26 PM, Prosper BT <ptb3...@gmail.com> wrote: >>>> >>>>> Yes Jim this would suit my use case, but not sure if its global enough >>>>> others can comment may be >>>>> >>>>> >>>>> On Thu, Mar 6, 2014 at 10:23 PM, Jim Grace <jimgr...@gmail.com> wrote: >>>>> >>>>>> Maybe the most useful next step is to leave the user interface the >>>>>> same, but filter for the organisation unit assigned to the user when >>>>>> sending the messages. So for example a national user would see alerts >>>>>> from >>>>>> anywhere in the country, but a district user would see alerts only from >>>>>> within their district. (We probably should have done it that way in the >>>>>> first place!) Would this help? >>>>>> >>>>>> Cheers, >>>>>> Jim >>>>>> >>>>>> >>>>>> On Thu, Mar 6, 2014 at 2:15 PM, Prosper BT <ptb3...@gmail.com> wrote: >>>>>> >>>>>>> Thanks Jim for the quick response. >>>>>>> >>>>>>> As we talk about the two the more I see them complicated. >>>>>>> >>>>>>> For the user role, my use case is on the Uganda national system >>>>>>> where user roles and creating users is guarded like a gold mine. Only >>>>>>> two >>>>>>> people allowed to create roles and users though the rest of us can >>>>>>> create >>>>>>> user groups. But for now I will ask them to create a user role with only >>>>>>> one role that can do much with the system and try it out. >>>>>>> >>>>>>> For the second one, my use case is in four districts where community >>>>>>> health workers are sending weekly maternal surveillance reports. These >>>>>>> are >>>>>>> like over 4000 villages in level 5 on the hierarchy. I want districts at >>>>>>> level 3 to receive alerts whenever a death is reported >>>>>>> >>>>>>> So if I implement it the way it is now, I have to create 4 district >>>>>>> accounts and assign all them the alert user role. Once a death happen in >>>>>>> one district all the districts will receive the alert. >>>>>>> >>>>>>> May be as you suggest we should add hierarchy selection (level) in >>>>>>> creating the rule and if we specify sending to a given level (district, >>>>>>> region, national,...) an alert is only sent to only users assigned to >>>>>>> that >>>>>>> level and only for that hierarchy of that orgunit. >>>>>>> >>>>>>> Example >>>>>>> >>>>>>> Uganda/Northern Region/Gulu District/Alur Soubcounty/Gulu >>>>>>> Hospital/Village A >>>>>>> Uganda/Western Region/Kibaale District/Mutoke Soubcounty/Kagadi >>>>>>> Hospital/Village W >>>>>>> >>>>>>> If death is reported from Village W and the rule was set to send to >>>>>>> only users at level 3 only users assigned to Kibaale District with the >>>>>>> alert role should receive the alert, but if level 1 is chosen then all >>>>>>> users assigned to Uganda would receive the alert. >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 6, 2014 at 9:39 PM, Jim Grace <jimgr...@gmail.com>wrote: >>>>>>> >>>>>>>> You also raise a good point about sending alerts from different >>>>>>>> parts of the org unit hierarchy to different groups of users. I'm >>>>>>>> trying to >>>>>>>> imagine how this could be configured. Perhaps when you configure a >>>>>>>> validation rule group you could choose a point in the org unit >>>>>>>> hierarchy >>>>>>>> and assign a user group to be alerted for organisations at or below >>>>>>>> that >>>>>>>> point -- and then you could make similar assignments for other points >>>>>>>> in >>>>>>>> the org unit hierarchy as well. This sounds very useful to me, if a bit >>>>>>>> awkward. Can you imagine a simpler mechanism? >>>>>>>> >>>>>>>> If you can say a bit more about the use case, that also strengthens >>>>>>>> the case for a new feature. In particular, can you tell me what kinds >>>>>>>> of >>>>>>>> position(s) the users have who want to know about maternal or >>>>>>>> neonatal deaths in their district? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jim >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Mar 6, 2014 at 1:17 PM, Jim Grace <jimgr...@gmail.com>wrote: >>>>>>>> >>>>>>>>> Prosper, thanks for the feedback. The role is only used to >>>>>>>>> identify a group of users, so it doesn't matter what authorities the >>>>>>>>> role >>>>>>>>> has. You could create any number of otherwise dummy roles for this >>>>>>>>> purpose. >>>>>>>>> >>>>>>>>> But your point is very well taken that user groups are in general >>>>>>>>> easier to set up and administer (without needing the authority to >>>>>>>>> create >>>>>>>>> roles.) That's a very good suggestion for the future. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jim >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Mar 6, 2014 at 12:53 PM, Prosper BT <ptb3...@gmail.com>wrote: >>>>>>>>> >>>>>>>>>> Dear Team and Jim >>>>>>>>>> >>>>>>>>>> Thanks for this validation rule type that helps us send alerts >>>>>>>>>> above set thresholds. Am planning to implement it on one of our use >>>>>>>>>> case - >>>>>>>>>> Maternal and Neonatal Weekly death reports. Basically I want sms >>>>>>>>>> sent to a >>>>>>>>>> group of users whenever a maternal or neonatal death is reported. >>>>>>>>>> >>>>>>>>>> First of all the two challenges I have are: >>>>>>>>>> >>>>>>>>>> - Sending to users assigned a given user role as opposed to >>>>>>>>>> sending to users in a given group. Its easier to send to a user >>>>>>>>>> group as >>>>>>>>>> opposed to the current design that only allows to send to users >>>>>>>>>> assigned a >>>>>>>>>> given user role. First of all am not sure what different authorities >>>>>>>>>> this >>>>>>>>>> role should have. Secondary in a situation where I have no rights to >>>>>>>>>> create >>>>>>>>>> a user role I cant implement this like the case of Uganda national >>>>>>>>>> DHIS2. >>>>>>>>>> >>>>>>>>>> So I would suggest we either add sending to a user group. >>>>>>>>>> >>>>>>>>>> - Ability to localize the alerts to the hierarchy; right now we >>>>>>>>>> can only send alerts to a central team otherwise it creates a lot of >>>>>>>>>> noise >>>>>>>>>> if we send to user of lower levels for them to be relevant. A user in >>>>>>>>>> districts B may not be interested in alerts from district C would >>>>>>>>>> rather >>>>>>>>>> only receive from his only district. But currently if a user in >>>>>>>>>> District B >>>>>>>>>> is assigned the alert role, he/she will receive alerts from all >>>>>>>>>> districts. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Prosper Behumbiize, MPH >>>>>>>>>> Phone: +256 414 320076 >>>>>>>>>> Cell: +256 772 139037 >>>>>>>>>> +256 752 751776 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Prosper Behumbiize, MPH >>>>>>> Phone: +256 414 320076 >>>>>>> Cell: +256 772 139037 >>>>>>> +256 752 751776 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Prosper Behumbiize, MPH >>>>> Phone: +256 414 320076 >>>>> Cell: +256 772 139037 >>>>> +256 752 751776 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~dhis2-devs >>>>> Post to : dhis2-devs@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>> > > > -- > Prosper Behumbiize, MPH > Phone: +256 414 320076 > Cell: +256 772 139037 > +256 752 751776 > > > _______________________________________________ > Mailing list: https://launchpad.net/~dhis2-devs > Post to : dhis2-devs@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
