Welcome to this session on Application-specific Permissions. In this
session we'll see how we can assign users application specific permissions
and then we'll also take a look at teams we'll discuss how we can create a team
add users to a team add applications to a team which will then imply the
different permissions that those users and the teams have so let's go ahead and
get started application specific permissions allow
us to grant permissions or a role to a user for a specific application or
multiple applications so here we can see Mary Jane who by default is a developer
but by clicking grant role in applications we can select an
application like the dialogues plug-in and grant Mary Jane an application
specific developer role which may have different sets of access control so this
allows us to grant Mary Jane access in a different role type fashion to each one
of the applications if that's necessary now we also can use application specific
permissions to override the default users infrastructure role permission so
Mary Jane is a developer and here the app specific developer may have
different permissions than she does as a default developer the default user's
role can be overridden to either increase or decrease the level of access
so just because the default level has a certain level of access it doesn't mean
that application specifics can only make that greater or only make it less it
could be either one but if we do use the no access level of permissions in the
default user role the result will be that that user will not be able to login
so there's no way to override that once the users default role says no access
so here's an example we see Mary Jane again the default role is developer and
the developer can reuse and monitor inside of development but for the
dialogues plugin mary jane was given application specific developer and that
has change and deploy which is actually a higher level of application access so
here we're overriding her default role in the development environment only in
QA and in production we see that both roles both the default and the
application specific have the same set of permissions so this new definition of
the dialogues plugin application specific role only applies to the
development environment now if we look at teams teams can help us simplify
permission management because we can create groups of IT users and then work
with several applications with those teams at the same time so a team can be
assigned one or more applications and the team can have one or more IET users
the users on the team can belong to multiple teams so they're not restricted
to a single team and users will have roles in the team and they can have
different roles in each team that they're in users in the same team can
have different roles for the same application but one thing we have to
remember is that each application can only be assigned to a single team so
let's look at this in a little more detail to create a team we can go to the
user management area of lifetime and in that area we can manage users teams and
roles by selecting teams we can create a new team and creating a new team as as
simple as giving it a name and a description and clicking create once we
have our team then we can edit that team or add users to the team multiple users
can be selected for the team with a specific role and each team member could
have different role within the team if that
was needed users can be added to multiple teams so here we can see that
our to do team is going to have users added to it and in this case John Smith
and Mary Jane have been selected and they've been selected with the role of
application-specific developer now when we add applications to the team so once
our team is defined and we have John Smith and Mary on the team then we wish
to add applications to the team as well multiple applications can be added to
the team and the IT users in the team will have their team role permissions
for all the applications that are associated with it so once they're given
a particular role in the team it applies to all of the apps the same application
cannot be added to two different teams as we mentioned before so here we see
our to-do team which had John and Mary Jane on the team and we're now adding
applications to it since this is the to-do team we will add that to do core
app and the to-do app itself so we have two mobile apps one which is the core
and one which is the actual application both of those apps are now added to the
team so in this case to be able to see the team the users their roles and the
apps all in the same place the team definition would look like this here are
the users where we see John Smith and Mary Jane and here are the applications
which are the to-do in the to-do core if we came in and changed Mary Jane's role
to test her instead of app specific developer then this will actually change
her access to these applications because she's no longer being considered a
developer she's being considered a tester so whatever this roles
application access levels are that's what Jim Mary Jane is going to get for
these specific applications so let's look at mary-jane in a little
more detail but just remember the following users can have application
specific and team and infrastructure level permissions the team permissions
will always override the infrastructure level permissions and any application
specific permissions override the team and the infrastructure so application
specific permissions are the most powerful and the ones that will always
override any of the others so if we go back and look at how we've been defining
Mary Jane throughout this session we gave Mary Jane access to the dialogues
plugin has an application specific developer she's also been added to the
order's team application and she's an application-specific developer there so
by default Mary Jane is a developer but as a developer she can only reuse and
monitor so she can see the different components and applications but she
can't actually do anything to them once she's been assigned to the dialogues
plug-in and she's part of the orders application team she then has the
ability to change that code and deploy it inside of development the to do team
changed mary jane's role to test her so here you can see she now has no access
in development because she's just a tester and she shouldn't be messing with
the code while in quality she's allowed to reuse and monitor which is higher
than her normal list level of permissions so if we go back to the left
here we can see that by doing application specific stuff we increased
her permissions when she was added to the order's team as an app specific
developer she had her permissions increased and when she was added to the
do team her permissions decreased in development but increased in QA because
she's a tester which makes perfect sense so we can see that Mary Jane can belong
to different teams Mary Jane can have access to different applications and can
have a fairly complicated set of requirements as far as access to
all those applications in these different environments and life time can
help us set that up relatively easily and again when any of these don't exist
everything falls back to the default role that exists these will always just
modify whatever is in the default role and sometimes it decreases the level of
access and sometimes it increases the level of access so hopefully this has
made application specific permissions make a little bit more sense thanks for
watching and have a great day