You are viewing limited content. For full access, please sign in.

Question

Question

Dynamically Assigning User Task: Named User vs. Participant LDAP User

Forms Version 9
Updated February 26, 2018
asked on May 30, 2014

I have a Forms Process that does a look up based on the person filling out the form and finds out who their supervisor is. It then looks up the supervisors network login (which matches their forms login) so that after the form is submitted it will assign it to the supervisor for review.

 

We just purchased additional participant licenses and are setting up LDAP configuration for them. I noticed that the username is their email address. Does that mean that in order to dynamically assign a user task to them that the value needs to be the email address instead of the characters before the @ like you do with named users that are Windows Accounts?

1 0

Answer

APPROVED ANSWER SELECTED ANSWER
replied on June 12, 2014

How about have two fields for user information. One stores email, another stores username. And assign task to both these two fields, for LDAP user/participant user, only one will go through. So they will get assigned either way.

0 0

Replies

replied on February 26, 2018

Any updates on this? It has been years since this post and it is very logical request. Why have the added complexity of using an email for some users and a username for others based on their licensing?

There is no limitation of LDAP to prevent access to the user's login name. There is unnecessary code actually requesting their email instead of their username.

When you lookup users from AD, you need to specify the login name you are looking for, but AD has not a clue what type of Laserfiche licenses they have been assigned.

Either the Laserfiche code needs to change, or Microsoft Active Directory needs an integration with Laserfiche, but that seems far more complex then is required.

2 0
replied on May 30, 2014

So I found out that since the user name for an LDAP user is the email address for the user, you have to assign that to the user task. Is there a reason why it does not pull the logon name for the user in AD instead of using their email address?

 

The reason I ask is because now dynamically assigning a user to a user task just became a lot more difficult as we some how will have to know who is a Windows Account Named User and who is and LDAP Participant user so we format the username accordingly since the named users username is domain\username and the participant username is email@address.com.

1 0
View 6 previous replies
replied on June 3, 2014

Does anyone from Laserfiche have any input on this?

0 0
replied on June 11, 2014

We need a unique identifier as the username for LDAP participant so that we can tell whether this user is LDAP participant when login. For LDAP participant, we get the value for "mail" this attribute from the LDAP server as the username in order to distinguish this type of user from windows named user and LDAP named user. Besides, there is no such attribute in the LDAP server which value is in domain\username this format.

 

If you are using a lookup rule such as when _(current user) match column a(username), then fill field with column b(supervisor) to dynamic assign user task, can you add data in the same external table to map supervisor with email well?

0 0
replied on June 12, 2014

We can do as you suggested, but the problem is that since we have both types of users (named and participant) we have to be able to say "If user is a named user, then assign the user task using column a (username). If user is a participant user, then assign the user task using column b (supervisor email)."

 

We have some supervisors that have named user licenses and some supervisors that have participant licenses. As it currently sits (as far as I'm aware), I would have to add all of the named user license users OR all of the participant license users to a conditional statement that would then split to two different user tasks and keep that conditional statement updated any time we have staff changes.

 

So maybe since with LDAP there isn't an attribute that has the value "domain\username", could an option be added for a conditional statement to be able to determine if a user is an LDAP user, named user, or general forms user? That way we could assign the user value correctly?

0 0
APPROVED ANSWER SELECTED ANSWER
replied on June 12, 2014

How about have two fields for user information. One stores email, another stores username. And assign task to both these two fields, for LDAP user/participant user, only one will go through. So they will get assigned either way.

0 0
replied on June 12, 2014 • Show version history

So if it isn't able to assign based on one of the values does it throw an error of any kind?

0 0
replied on June 13, 2014

There'll be an Error in the Event Viewer, No task participants named 'test@test.com' can be found.

0 0
replied on June 15, 2014

How about use a exclusive gateway follow with two user tasks: task 1 use username field as dynamic approver, task 2 use email field as dynamic approver; if username !="", the go to task 1, else go to task 2.

0 0
replied on June 16, 2014

Xiuhong, the problem with that options it that we have over 70 users. I would have to put their names in the condition. Along with that, if we replace employees, then the workflow has to be updated every time as well.

0 0
replied on March 4, 2015

I thought this post would be the best place to start... :)

I tried creating a form field (and variable) in the form "<Full AD Name> (<DOMAIN>\<username>)", and despite having this as a variable, and referencing this variable as a Task Participant under a User Task, the Event Viewer is displaying the following:

Function: BindActualApproversToResumeByName
Message: No task participants named '<Full AD Name> (<DOMAIN>\<username>)' can be found.

The user I specified was me, so it's definitely a legitimate Laserfiche Named User, so I'm wondering if it might be the way I'm referencing the variable?  Could there be something I'm missing in terms of how I'm referencing the Task Participant in a User Task?

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...