 Right, so today we are going to discuss on few important topics which are not only relevant to DHS2 tracker but these concepts you will come across whenever you are customizing DHS2 in general for aggregate as well as sometimes when you are analyzing data and especially when you as an implementer support your DHS2 instances in the country these topics are going to be very crucial. So they are going to be interesting and as well they are going to be sometimes complicated because here you will be discussing about I mean few of these minor I mean some complicated concepts like the authorities. So we will try as much as possible to make them clear to you during the presentation as well as in the demo session but if you have any queries please feel free to ask them in Slack and also we request you to refer the DHS2 documentation as usual. Right, so today we are going to discuss about users, user roles and user groups. The objectives of this session include describing the individual concepts that make up a user and then configure these concepts in DHS2 instance and also how to create a user in DHS2 incorporating all these concepts. So what actually constitute a user in DHS2. So the first concept is we have something called user authorities. So what we mean by user authorities is a permission to perform one or several specific tasks within DHS2. And then we have another concept called user role. So what is meant by user role is a group of authorities created for a specific type of user. So we are going to discuss about each of these concepts in detail so in this slide we are kind of giving you a basic overview of different concepts. And then we also have another concept which we have already come across when we were sharing our design tracker program called user groups. So user groups is a group of user that have access to a specific object in DHS2. So there are so many objects, different types of objects in DHS2 and to provide access to these objects we use this concept called user groups. And then we have organization units. So I mean this term is something that you are really familiar with we have been discussing about organization units from the DHS2 fundamentals it is one of the three dimensions in DHS2. So what do we mean by organization units. Basically organization unit controls a user access to administrative units in data entry or data analysis and search. And finally we have users. So all of us who are accessing DHS2 are DHS2 users. So a DHS2 user is an individual DHS2 account assigned to user roles, user groups and organization units. So now let's look at each of these concepts in a little bit more detail. User authorities. Now DHS2 uses something called an authority to allow users access to various components of the system. These authorities are very granular in nature you will see when we are doing the demonstration and they control detailed operations of what can be done in DHS2. So it's basically like we will show you what are the different authorities we have we have a comprehensive list of authorities so it's kind of limits, restricts individual tasks the user can do within the broader DHS2 system. A user authority can provide a default behavior when creating objects in the system. So we have like kind of two concepts under this we are like public versus private. So what we mean by public objects like they can be seen by anyone who logs into the DHS2 system. So if you create a DHS2 public object. For example, there are some metadata items we create as public in DHS2 system for example this programs that you created are configured as public, which means it can be seen by anyone who logs into the DHS2 system. And at the meantime, we can also create private objects in DHS2. So the attributes that you created, for example, when you are customizing are configured as private objects by default. And that is how we have configured the DHS2 instance for this academy. So these private objects must be shared in order for others to see them because it is private to that particular user. So in any case if you want these privately created objects to be shared by others, you have to share it with the specific user. Okay. Right. And now let us again discuss a bit more about different authorities which are there. So for example, you will see that we have authority called all. When we grant this all authority in a DHS2 system, it grants authority to do everything in the system. So for example, whenever we grant this authority, usually this authority is granted to the super users, they can do anything. So they have all permissions, unlimited permissions to do anything within a DHS2 instance. And authority called tracker capture application. So this what it does is it allows the user to access the tracker capture app. So if we do not grant the authority to weave the tracker capture application, that particular user will not be able to see the tracker capture application in this in that users apps menu, it will be disabled. And we have, for example, authority call update track entities, which allows a user to modify a track entity value of the enrollment. And we have another one which will show today called uncomplete events. So this allows the user to reopen a previously completed event. So if we complete the event to make it incomplete, incomplete, we have to use this particular authority. Then we also have authority for, for example, search a track entity instances across all low units. So this allows the user to search beyond the organization units that they are assigned to. So generally, we assign some more unit to a particular user. But if this user has access to weave across all low units, then that means like whenever he searches, he is able to search whoever who's registered in any of the org units in our DHS2 system. Right, so what do we mean by user role. Now previously we talked about authorities in DHS2. So these are individual permissions. So basically what we mean mean by user role is a collection of such authorities. So we discussed like for example in the previous slide we mentioned five different authorities. So if they kind of, if we group them together, we can make something called DHS2 user role. Authorities basically write to perform an action within DHS2. As I mentioned before it could be public or private, and it receives access to various apps and functionalities within DHS2. And these user roles which is a collection of authority once created, we can assign this user role to DHS2 user. And once that user is assigned a user role, he can log into, he can log into DHS2 instance. Right. So basically what we mean by DHS2 users are particularly the people who log into DHS2 instance. Okay, so I guess like DHS2 user is a very simple concept to understand because we all, all of us here are users of the DHS2 instance that we are logging in to customize right. And when we log in, all of us will have different user roles. Right. So here we are kind of explaining further the concept of user role. So as you can see, see here, we have the use we have two different types of user roles here. The first one is the system administrator. The second is tracker data entry. So the system administrator has been granted the permission all meaning he has full access or authorities to do anything within the DHS2 instance. The third is tracker data entry user role. We are only giving some limited permissions or authorities. So for example, he can see tracker capture application, he can update track entity entities, and then he can uncomplete events and he can also search for track entity instances across the organization unit. So here for this particular user, the tracker data entry user, we are only giving four permissions, right, as for this diagram so it's a kind of very limited amount of access that this user is going to have. Right. Then next, in the latter part of today's session, we will be discussing in detail about the concept called user groups. User groups to users can also be assigned to various user groups. User groups are used to set up access and sharing of objects or notifications. So if you can remember the tracker programs that we created the final step was to assign it to a user or user group. We did not like in our demonstration be just assigned to one user, but you may have also seen if you refer the documentation or if you just when you are signing you may have seen that you can assign that basically you can share that tracker program with the user group as well. So once it is shared with the user group, all of them will go are going to have access. User groups, basically a combination of user roles, user groups is what constitutes what a user can do within the DHS to instance. So when we created DHS to user that user is going to get assigned a user role, which means they'll be a set of authorities that user role is assigned to so all these tasks that user is able to do. And then if we assign that user to user group, it'll kind of will determine what are the objects that this particular user is going to have access within the system. So it's a always a combination of user groups and user roles that defines what the user can do and and what is the kind of like, I mean what are the different objects say for example what programs that user is going to have is determined by the user user group. Right, so it's always a combination of these two concepts. Right, so for example, you can see here. We have this user should I did who can be assigned to one or more than one user group. So here he can be assigned to malaria user group admin malaria group. Right, and then we have another user group called TV analysis, as well as TV HIV analysis so this user can be a member of each of these user group. So the implication is like whatever the shareings like for example if we shared access to say the access to TV program if we shared with the TV analysis user. This user should I did this going to have access to that program right and at the same time if malaria is also shared with this group is going to have access to that. And the and if you have shared the HIV program with the analysis HIV user group. This new search rather it is also going to have access to that program as well. So how he has access to all these three programs is because he's a member of each of this user group. So that's how we determine. We I mean what are the objects, it could be like for example, program, a particular user is going to have access. Right, so we will discuss in detail about how this user groups concept is going to affect what the user can do in the later part of the day. Right, so then we will briefly discuss about the organization units. So, we have different. I mean types of organization besides, for example, we talk about data capture and maintenance organization units. So, this kind of determines where a user can capture data. Right, so when you are configuring you when we are when we are creating a user we have to determine we have to define the data capture and maintenance or you need. Now, again, it is going to be like a combination of like say for example now when we are saying is determines where a user can capture data. He must be also part of user group with the setting data can capture and we've data. For example, if you can remember when we were configuring the TV program. We defined in the last part we had to set so that that particular user can capture as well as we did. Right, and also in the same time, when we are talking about this data capture and maintenance organization unit it determines what is the organization unit user will see in the maintenance app. But for that to happen that particular user must have a user role, which grants access to be mean maintenance app. Right, so then again you can understand like you just can't, you know, like by by assigning a user to a capture unit will not give him access to the maintenance app so it's a kind of a combination of the user role, which has the authority to to be the maintenance app, and a user having access to one or unit that will kind of constitute the entire authority or the permission access that user is going to have in the system. And then we also have type of organization unit, but we are defining when we are creating a user called data output and analytic organization units. So here it determines the level of data a user can see based on the organization unit selected. And then we also have search organization unit concept. So this determines what are the organization units a user can search for a track entity instance. So for example, even though a user may have access to to level three capture unit and a view of unit. If that user when we are configuring if we configure the search with the kind of a higher organization unit level, say like level two, he'll be able to search all the track entity instances up to the up to that particular level. So it's it's again kind of overriding or kind of like setting a higher level of access when the track when we are searching the track entity instance. Right. So here we discuss about three different concepts associated with arguing. This one is the tracker data, sorry, the data capture and maintenance or getting the second is data output and analytic work units and third is search and maintenance. Right. Okay, and also it is kind of important to notice that in all cases, a user will automatically be granted to all access to all lower levels within the top most or unit selected. So if we give access to level two in the or unit hierarchy, that means, I mean, whatever the or units coming under level three under that level two or unit, he will have access something like that. Okay. Right. So for example, now, this user should achieve, we can just assign one note unit or more. For example, here as you can see the particular user has been assigned more than one or unit access so he's assigned access to province one, two and three. So that way we can I mean in the organization unit tree that we are seeing when we are configuring the user, we can give multiple levels levels of access. So here you are seeing a summary of what we have discussed so far before we move to the demonstration. So, when we are discussing about users in DHS to a user is assigned to a user role. So a user role restricts what apps a user can access and what operations a user can perform within those apps. And then we also assign users to a two organization unit. So this will restrict access to organization units within the data and pre maintenance and maintenance analysis and searching. And then we can also assign the user to a user group, which restricts access to specific objects. And it also aids in notification separation. Right. So this is kind of summary of what we have discussed so far. Right. So, next, what we are going to do is to do a demo of user roles and followed by that we will discuss about user groups.