In this lesson we're going to extend the security of the pages and also add some
server side checking to make sure that our users don't tamper with the data.
So what we want to do, let me just go ahead and open here the issues web block.
What we want to do is only allow managers to classify issues.
So only the managers can classify the issues, and this means that we need to hide
these buttons from users that are not managers. Okay. So this is pretty much the
same as we did for the menu. We need to hide this for users that don't have access
to this functionality. So to do that we'll select here the if and change the
condition, and again I am going to use the check, the check customer.
Let me just use auto-complete here. Check the customer support manager role.
And again I will not to set the user ID. I will let the action use the current
logged in user, and this means that managers will see the buttons when the priority
is not set for this issue. Okay. This is basically it. There's only one more thing
we need to do, because if we edit an issue, we can also set its priority as you
recall. So we also need do something here on the issue edit screen.
And what we need to do is to disable this input when the user is not a manager.
Let's select here the input. There's here a property, which is the enabled,
and this is the property that we'll use. And again, we're going to use the check,
the check costumer, auto-complete again, check costumer support manage role.
So this means that managers will have this widget enabled, and users that are not
managers will see this widget disabled. And let's publish and see how this works.
Let me just close this. Let's publish. Okay. So let's login first as Peter,
and, as you recall, Peter is a manager. So he should be able to see the buttons on
the page, and he should be able to change the priority of an issue.
So let's login, and here is the dashboard. Let's go to the Unclassified.
And okay, we still have the buttons for Peter, and if we try to edit,
we still can set the priority for the issue. Okay. So now let's log out as Peter.
Log out and let's login as John. John, okay, and John is not a manager.
Okay. John is not a manager, so he should not be able to see the buttons on the list,
and he should not be able edit the priority on the pop-up. And here it is,
no buttons for John. Okay. Let's see the pop-up. As you can see here,
the input is disabled. Its grayed out, and I cannot select it.
So this seems to be working. But if we really want to be sure that somehow users
don't tamper with the data and are not able to change the priority,
we will need to add some server side validations to our application.
So let me just log out and close the browser, and we'll add these server validations
here on the save action. And basically what we want to do . .
. let me just close this down and get some space here. What we want to do,
let me give you here a hint. If you use Ctrl + shift and select a node,
this will select all the nodes that are connected to this one,
and move this down. And what we want to do again here is to only allow changing the
priority if the user is a manager. So let's see how we'll do this,
and we'll use an if. Basically what we want to do is first of all we need to check
if the priority changed, and to do that we're going to match.
We're going to see if the priority ID here on query, so the priority ID that came
from the database is different from the priority ID we have on our edit record.
Okay. So this means that the user changed the priority, and if the user changed the
priority and he is not a manager, so not a manager, and to check if he is a manager,
again, you use the check costumer. Let me Ctrl + space auto-complete,
check costumer support manager. So if he changed the priority and he is not a
manager, then we will give him some feedback, saying that he cannot change the
priority, and we won't update the issue in the database. Okay.
So again, let me add here feedback and end node. So we will end the request with
this feedback message only. The message will be: You can't change the priority of
the issue! Okay. Let's set here the message type. This will be an error,
and to see this validation working, let's add break point here.
Let me first remove any break. I don't have any break points.
Okay. So let's add a break point here, and let's set the debugger running here.
Let's publish our application. Okay. Let's login first as John this time.
So John should be not able to edit the priority, and we will see the validation
server side. So let me login, and on the unclassified issues,
let's edit number 54. Okay. I cannot change the priority, but let's save this
anyhow, and let's go here. Here we have our break point, and let's step into,
and as you can see here the priority is the same. The priority that comes from the
query and the priority in the edit record has the same value.
This means that, in this condition, this part is false, and so the rest of the
condition will not be evaluated because this is an end and this will also be false.
And this means that -- let's just step over -- this will continue the request,
and the issue will be saved, but the priority was not changed.
Okay, here we have it. Now let's log out as John and login as Peter,
and let's set this issue priority. So number 54 here, let's edit and let's change
the priority of this issue to high, and let's save. And here is the request.
So now let's step into. Now the priority is different. Okay.
So now the priority is different, so this is true, and this part needs to be
evaluated, and we will see the result of this function. We will see if this user has
this role. So let's step into, and here we have the check costumer support manager
role returned true. So this user is a manager, and if he is a manager,
he can edit the priority and let's step. The flow will continue,
the request will continue, and we will update the database. So let's just continue
and see it here. There we have it. And that's it.