RicardoPereira asked a question.
User logged in
How do I recover the user who is logged in to the portal?
I need to implement an approval rule and for that I need to know who is logged in the portal
This actially should be the default behavior of the system,. if you have the SLM Automationbook imported.
There is a "Named attribute" called "Requesting user" with some additional available Attributes like "Requesting user AD attribute".
Hello Axel, thanks for the reply.
I tried to use this parameter, but when running the script it assigns it to the user who made the request. What is not wrong.
But what I need would be something like this on the order approval page:
1 - user currently logged in;
2 - user who requested the service
With that I have a group in the AD that guarantees me the permission of who can approve, but it can happen that the user who requested the service is also on this list.
The idea is to generate a script that identifies whether the logged in user is the same as the user who requested it and thus preventing approval from being carried out.
Expand PostHello Ricardo,
ah ok I see your challenge 😉
By default, the requesting user and the "customer" (let's call it this way) are the same person.
The Automationbook does not support ordering for another person (except the service is defined as "per user" in SLM).
To achieve this, you need to add a new parameter like "customer" to the service, and use this as input to the "MailToUserId" in the activity "Email notification".
The "Requesting User" will always be the (logged on) user that orders. The "MailToUserId" is the user that the service is ordered for.
Looks like this in my demo environment:
The rest will be up to you scripting all you want in powershell.
Expand PostHello Axel, thanks for the reply.
It wouldn't work anyway.
Because the value is passed to the Approval Task.
It would be necessary to get the user logged in to the approval task for my process to work.
It would then be possible to validate if the connected user is the same as the requestor's parameter. If it is the same, I generate a block so that the order cannot be approved.
Expand Post
One possibility would be to create a dynamic list of approvers.
But I have no idea how it could be done. 😓
By default, the "Owners_Primary" parameter is entered manually during checkout.
To fill this field automatically, you will have to check where you can get the information. How complete is your Active Directory? Will you find the department and manager properties populated?
Of course you can use your AD group, but this will mean that you will have one group of approvers for the entire company.
So just as an idea:
- add a parameter "approver" to the checkout that is entered manually
- add a hidden parameter "hiddenapprover" to the workflow
- use a powershell webservice to fill the parameter "hiddenapprover":
- if requesting user is a member of the approver ad group then set hiddenaprover to "autoapprove" else set hiddenapprover to whatever has been entered as approver
- set a run condition on the two approval activities so that these will be only executed if hiddenapprover is not equal to "autoapprove"
- use hiddenapprover or approver as the value for "Owners_Primary"
Maybe not the most elegant solution but I think this could work
Expand PostAxel,
The idea is a good one.
But I still don't think it would meet my need.
Today I have a primary approver who is chosen at the time the order is placed.
The idea is that I have a list of secondary approvers, which can easily be implemented by passing a group of AD as a parameter to the service.
The issue is in the approval rule.
We have some information in the form, such as:
1- Initiator (requester user)
2- Applicant (Field open for search in AD)
3-Approver of the order (Automatically searches for a list of user members of a group in AD)
The rule states that the Order Approver is not the same as the initiator and / or requester. (Implemented)
The problem is that with the generation of the list of secondary approvers, eventually the Initiator and or the Applicant may be part of the Group of Secondary Approvers. In this case, approval must be prevented.
And the only way I see how to resolve this issue is to identify the user currently logged in to the portal and compare it with the Initiator and or requester.
Thus, it could create a field with a Regexp value for comparison, thus avoiding, by mandatory filling, a pre-defined value.
My entire scope is focused on the task approval page.
Yesterday I got to do the function below, but with no success, because in addition to returning the user who calls the script, it was previously defined at checkout
function Get-CurrentUser {
$result = Invoke-WebRequest -uri 'http://localhost/API/user/Current' -UseDefaultCredentials -UseBasicParsing
$x = $result.Content | ConvertFrom-Json
$obj = New-Object psobject -Property @{
"User" = $x.userID
}
$obj
}
😀
Expand Post
Yesterday I had an idea for solving the problem, I thought that maybe it is possible to create an entry directive with a field pre-filled with the logged in user, I have to test it further I think it may be a solution.
- Oskar Frolin (Flexera Software)
Hi @Ricardo Rerison​ ,
If I understand correct, you are trying to achieve the following:
Setup:
User A request Service X, with a approval task with Owner_Primary set for an AD Group that that User A might be a member of.
Issue:
User A should not be able to approve the task that they made themselves.
If this is correct, I would solve it like this:
Solution:
- Save the requesting user in a parameter on checkout
- Configure a visible parameter on Task view with PSWS takes in the saved parameter, compares against current user (Get-APRequestingUserName) and returns a specific value if they do not match.
- Configure this parameter to be read only and with a regex that REQUIRES that specific value.
Now if the logged on user is the same as the initial requester (the saved value), the task will be unable to complete.
This there can be information text in the regex failed message etc to highlight this to the user etc.
Screenshots:
How it could look on the Task:
The PSWS function is described in the template comments:
Example of the regex configuration:
Example of the PSWS:
Please let me know if this was understood correct, and if this solved the issue for you :)
Hope this helps!
//Oskar
Expand Post
Hi @Ricardo Rerison​ ,
If I understand correct, you are trying to achieve the following:
Setup:
User A request Service X, with a approval task with Owner_Primary set for an AD Group that that User A might be a member of.
Issue:
User A should not be able to approve the task that they made themselves.
If this is correct, I would solve it like this:
Solution:
Now if the logged on user is the same as the initial requester (the saved value), the task will be unable to complete.
This there can be information text in the regex failed message etc to highlight this to the user etc.
Screenshots:
How it could look on the Task:
The PSWS function is described in the template comments:
Example of the regex configuration:
Example of the PSWS:
Please let me know if this was understood correct, and if this solved the issue for you :)
Hope this helps!
//Oskar