Absent Member.
Absent Member.
180 views

Lookup contacts using user.id

Jump to solution
We are on SM7.11. In the SD.open.interation form, we'd like to have "Contact for this interaction" to query the Contacts table against User_ID, rather than contact_name, which is OOB. I went into the interation link to make the changes, sot the queries go against user.id instead of contact.name. It seems like it should be easy to do, but I get errors when I try to submit the interaction. There are a few forms or tables that I'm not aware of. What else should I change to get this to work?
Maybe we should even attempt this?
0 Likes
1 Solution

Accepted Solutions
Absent Member.
Absent Member.
We had the same issue. We use a unique security identifier (think login id or employee number) for contact.name. On the interaction form, the full name is in the vj.

Similarly for Change, in the operator record, we have for login.name and contact.id that same security identifier.

The problems we have encountered is that everyone wants to see a full name. So vj's are in most of our forms to display full name.

View solution in original post

0 Likes
6 Replies
Absent Member.
Absent Member.
Hi Greg,
You could change the link record for the file "incidents". However, this is not a simple change as the data fields for callback.contact and alternate.contact will also need to be changed. I would recommend you add a new field "user.id" to the incident record to keep the data integrity.

It will also have a ripple effect when you escalate the interaction to either an incident or change. Plus, the add/edit contact will also have to be changed accordingly.

If you really want to do this... then follow these steps.
1. Enter "links" in the command line.
2. Search links for file "incidents"
3. See the source field name = "contact.name" for the contacts file name.
4. Change it to "user.id".

5. Also, you will need to select the same line and change the expression line as follows:
original expression
if (not null(contact.name in $File)) then ($query="contact.name#contact.name in $File") else ($query="true")
New expression
if (not null(user.id in $File)) then ($query="user.id#user.id in $File") else ($query="true")

6. Below the expressions tab, change the source field and target field from "contact.name" to "user.id".

You will now be storing the user.id value in the "contact.name" field in the incident record.

This really needs to be carefully tested to ensure other links are not compromised.

cheers for forum points
frank



0 Likes
Absent Member.
Absent Member.
Frank: Good stuff, thanks. Part of the issue we're working through is that we have different people with the same name, e.g., Jim Jones (Logistics), Jim Jones (IT). And we also have some names that might be hard for a Help Desk worker to enter correctly, like Van Der Smoot versus vanDerSmoot versus van der Smoot, etc. So we wanted to use User_id, which is easy to enter and all are unique. Somebody had the idea of putting employee number in the contact_name field and in the user_id field, with the real name in full_name.
I think that is a hack solution, because for every report and form, in the Contact Name field we will see a number "01423" instead of a real name.
Are we on the right track, or is there a better way to handle this?
0 Likes
Absent Member.
Absent Member.
We had the same issue. We use a unique security identifier (think login id or employee number) for contact.name. On the interaction form, the full name is in the vj.

Similarly for Change, in the operator record, we have for login.name and contact.id that same security identifier.

The problems we have encountered is that everyone wants to see a full name. So vj's are in most of our forms to display full name.

View solution in original post

0 Likes
Absent Member.
Absent Member.
Beth: Thanks. I appreciate that there are others struggling with the same things we are.
You mentioned virtual joins. How do I get at the vj's related to this problem?
0 Likes
Absent Member.
Absent Member.
Virtual Joins (VJ) are just another Format (FD) that exists. Consider it a sub format.

The Link on the master format handles the query from one table (incident) to the other (contacts). Attached are the VJs that we have used on Interactions.

You may have to create then yourself.
0 Likes
Absent Member.
Absent Member.
We decided it was too risky to make this change. To solve the problem of trying to do a lookup based on name, we have loaded our employee id into the contact.name field of the contacts table. However, many reports use contact.name, and if all we see is a number, it's not enough information to tell us who. So we will have to add full.name in those places.
Thanks, everyone for your time.
-Greg
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.