 Okay. Thank you. So, as you said, I'll be talking about the user role permissions model. So about me, so my name is Akshath. I also go by the name AKJN. I'm a sophomore undergraduate student from IIT Patna, India. And I have been an active open source contributor at FOSS Asia since like over one year now. I was a GSOC student with FOSS Asia last year and I'm also mentoring in Google code in 2018 and code it 2018 with FOSS Asia. So about Suzy. So as the previous speakers have already said, Suzy is an intelligent open source personal assistant. It's a rule-based personal assistant. We have several platforms. We have web, Android, iOS, we have numerous bots, etc. where like Suzy server is integrated. So there are various services we provide. So let's begin the talk. So what exactly are user roles? So each user role basically defines the permissions for a set of users, like what task he or she can perform. So let's say a very basic example can be like let's say we are creating any Google document. So we have all gone through these things, right? Like who like let's say we want to give like edit access to someone like some of our friends or someone. So these are basically these are what user roles are. So for in case of Google Doc, like the least permission one is just him or her being able to view the document. After that comes the next one which is like he or she is able to comment. After that he or she can edit and then comes the directly the owner of the document. So this is in the case of Google document. So this is what user roles are. So in the case of Suzy user role. So earlier we were following the Wikipedia user role permission model but recently we decided to switch to our own permission model. So the main reason for this was like it allows us to make more flexible decisions based on what are our needs for various Suzy services, alright? So as we can also see over on this picture on the right side. So each user creates an account. So each account is linked to a user and each user has a user role and each role is basically linked with a set of permissions which he or she has. So as I said we switch to our own user role permission model but why? So it allows us to have more flexibility. It is a better administrative model based on what we require and it also allows us to provide a better distribution of the various permissions based on what we require. Like we have various services. We have client side. We have bots. We have like various other things. So based on those things we can distribute the permissions like more appropriately based on our needs. So what are the different user roles in Suzy permission model? Like in the case of Google Doc we had like the ability to view, ability to comment, ability to edit and then comes the owner. So in the case of Suzy permission model these are the various user roles which we have. So the least one or the lowest one is the blocked users. These are the users which are basically blocked and then comes the anonymous users and then are the unverified, then are the registered, then are the reviewer, operator, admin, all the way to super admin. So we will be going over all these in the next upcoming slides. So this slide and this next slide. These two slides are basically, so we had a spreadsheet as the spreadsheet was actually quite long enough I couldn't fit them in one slide. So basically this spreadsheet or on the top row we have the various features which we have and on the left side on the left most column we have these different user roles. So this spreadsheet is basically this was a roadmap to implement the new user role model for Suzy. So I basically split this in two parts in like two slides in the presentation. So like the basic gist is that this allows us to basically figure out what we need for each user role, what features we need, what we need to limit for each user role. So coming back to the slide, so starting off with blocked users and also one more thing I'd like to point out here like you can see different colors right? We have green, we have red and we have yellow. So as we are implementing the new user role model like not all can be done at once. So we started doing that we also have this new this tab V1. So this was our roadmap and this current tab is basically what's the current situation. So the green ones have already been implemented. The yellow ones are in the process of being implemented and the red ones like we'll take them after the yellow ones have been implemented. So coming back to this so blocked users. So these are the users which have been blocked by the admins and hence they don't have any access to any of the features of Suzy AI. And as we can see as we saw on the spreadsheet this was marked as yellow as this is still under the process of being implemented on the Suzy AI server and also in the various APIs which we have. So the second one was anonymous user. So these are the users which do not log in and these just browse the websites and use our services without logging in. So like we have services like the users which have not logged in though they also can use all the skills they also can they they can use skills but they cannot create their own skills and they cannot rate any of the existing skills they cannot also make the bots and all those things. So some example APIs where the minimum user role is anonymous are as follows and on the top right side we have like this function this is a Java function so this is how we basically in all the APIs which we have on the server side this is how we control what's the lower most user role which can access this API from the client side. So return user role anonymous so this specifies that the minimum user role required for accessing this API is anonymous. So some example APIs where we have the minimum user role is anonymous like get skill metadata service. So this is an API to fetch the basically the details of all the skills. So as I said the anonymous users can browse all the skills so they should be able to see all the skill details for all the skills. Hence they have access to this service they have the sign up service because they haven't signed up so that's why we have the console service so they also have access to all the console services which we have and then the get API key service which also which is basically like some skills require some API keys to work so as I said that the anonymous users are all they also can use all the skills so they also should be able to get the API keys from the server in order to be able to use some of those skills. So this was about the anonymous users. Nextly so on the spreadsheet we can see that we have these two things unverified user and registered user. So current and these are marked as yellow so these haven't been implemented yet and the current implementation is like we have a user who has we have this user who is already logged in so we want to split this into two parts which are unverified and registered. So the current implementation is on the server side is like this that we have this return user role dot user which specifies that the minimum user role required is user. So we want to split the user user role into two parts which are the unverified user and the verified user which are basically the registered user. So the unverified user are basically those which haven't basically gone to their email and clicked on the verify account link so they haven't been verified yet by the server. So we wish that they shouldn't be able to make their own skills or create any of the bots or rate any of the existing skills as well. So this is in the process of being implemented in the various APIs which we have. So next is the registered user. So these are the users who have registered they have clicked on the verify account link on their email they are able to make the skills they are able to rate any of the existing skills they are able to create their bots they are able to deploy their bots and this is also kind of being in the process of being implemented on the server and the current user role the user which we had so that's like this registered user which would most for the most part inherit most of those things from the user user role. So some example APIs where the minimum user role is user or whenever then this new model gets implemented it will be shifted to registered user so those are as follows. So we have these are some of the APIs we have the list user settings service which is basically user specific thing so and then we have change user setting service it allows users to change their settings we have the password change service we have the get rating by user service so this basically fetches the various ratings done by user on various skills we have the feedback skill service which allows users to submit feedback to the for the for the various skills which we have we have a add new device service we have delete device service and this term device this this is basically being referred to the sujii smart speaker devices which we have and there are various there are lots of various APIs to explore whose minimum user role required is user so next we have these two pages again so here so the next user role was reviewer so if we can see here so between reviewer and between registered user we don't have much much distinction but we wish that reviewer should be able to review the various skills which we have this is why we kept the provision for a separate user role so that in future whenever we wish to give reviewer more power we are able to do that because like shifting to an entirely different user role model isn't something which like we can do like very frequently or like that so let's shift to reviewer so this is the fifth user role which we have so as I said we don't have much distinction between reviewer and normal user as of right now but this allows provision for more distribution of power in future whenever whenever we wish to have like more reviewer specific things alright so the main intent for having a separate user role was because of the number of because of increasing number of skills every day so we need a dedicated user role for this purpose alright and then we have the next user role is operator so this is where things get interesting so this guy gets access to all the admin panel he can see he or she can see the list of all the users and their connected suji as smart speaker devices etc on the admin panel and then we have admin so this gets some even more power than operators so he also obviously gets access to the admin panel