Request Import Tool Issue - Customers can't view their requests until manual customer update

[Aaron Carter]

Hello,

 

I am setting up a one-time migration of our open tickets from the old system to Hornbill. 

Using the request import tool gets everything across properly on the technician side with correct user assignments for customer, owner etc.

However, customers are unable to navigate to their request detail pages. Customers are able to see a list of all their open requests, but when they click to view an individual ticket the page only displays "You do not have permission to view this request".

From my account in the service manager, I can see that the customer has been correctly found in Hornbill users. The customer details in the requests shows their manager etc.

If I re-assign the customer to the same ticket manually through the service manager, the customer is then able to view specific tickets. 

 

Is there something I can do to fix this issue without manual reassignment? 

 

Thanks

 

Aaron

[Martyn Houghton]

@Aaron Carter

Normally the import tool would normally do this. Does the Request Importer log show that it has matched the customer for each request as it load it?

Might be worth uploading a redacted extract from the Request Importer log.

Cheers

Martyn

 

[Aaron Carter]

Hi @Martyn Houghton, thanks for the response!

 

This is the line in the log for the customer (using a test account on a sample ticket):

 

2020/09/08 14:57:47 [DEBUG] User Cached [sterling.archer@domain.co.uk]: Sterling Archer

 

The only warning I receive in the log is for site - I have tried the string name of the site, its int Id and its site code. nothing seems to match. However, I am unsure if this is causing my Issue?

 

As mentioned above, when I view the request as an analyst, I can see all the correct customer details. It is retrieving their manager, department etc. all from their User details in Organisational Data > Users.

It's as though it's stuck halfway!

 

If there is other relevant log data, let me know and I can share.

 

thanks

 

Aaron

[Martyn Houghton]

@Aaron Carter

Are these internal coworker users or external customers?

What do you have set as the following field mappings?

• h_customer_type
• h_container_id
• h_fk_userid
• h_company_id
• h_company_name

Cheers

Martyn

[Aaron Carter]

@Martyn Houghton

These are internal co-workers

• h_customer_type is currently set to 2 (I have also tried at 0 and 1)
• h_container_id is blank
• h_fk_userid is the email address of the customer
• h_company_id is blank
• h_company_name is blank

 

I couldn't find documentation on container, company_id, or company_name. I've been referencing the wiki page: https://wiki.hornbill.com/index.php/Service_Manager_Request_Import_Utility

 

Thanks

 

Aaron

 

[Martyn Houghton]

@Aaron Carter

h_customer_type should be set to 0 for internal co-workers. 

When you view the user in the admin tool, what is the value for the top User ID field. Is the the users whole email address or just the first part? 

I always try to ensure the value we map to the h_fk_userid is always identical to the value shown in the database table.

When the customers are viewing the requests, is it in the new Employee Portal or the original Service Portal? Just wondering if the recent changes in this area have caused an issue.

Also presume you are using the latest 1.8.0 version of the tool?

Cheers

Martyn

[Aaron Carter]

@Martyn Houghton

 

It was a version issue!

 

I had downloaded the latest tool but the old version was still being run.

 

 

thanks for your help, something I should have spotted sooner

[Aaron Carter]

On closer inspection, the issue is still there with the new version. I'll investigate and get back to you on the other questions (cannot seem to edit the previous response either))

[Aaron Carter]

@Martyn Houghton

 

Its the Employee Portal that they can view tickets through

The user Id, Logon Id, and employee Id are all identical: firstname.lastname@domain-name.co.uk

 

I am running the latest version of the tool.

[Martyn Houghton]

@Aaron Carter

Do you have a premier success plan with Hornbill which includes the ability to log support incidents with them or do you just have the community support? 

If you have the former, might be worth raising a formal support request with Hornbill for assistance.

When you view the request in the Live app after importing it is their a timeline entry and historic updates section?

Also if you use database direct to retrieve on of the imported requests is the h_fk_user_id set as you expect it to be in the database?

Cheers

Martyn

[Victor]

@Aaron Carter can you please check, on the requests that display the permission message, how is the customer on the request stored in the DB? You can run a simple report to retrieve the ID of the request customer. I am looking to see if the request customer and the user have ID with different case. The bit of code that checks if for permissions on requests is case sensitive and will deny access if it can't fully case match the ID of the request customer with the user ID in the DB. For example, if on requests the customer ID is stored as Firstname.Lastname but the user ID is actually firstname.lastname then this will throw the permission error when accessing the request.

[Aaron Carter]

Aha @Victor I think it was case sensitivity in the domain name. I had to reconstruct the email address and had capitalized the domain name, tricky to detect as it was able to fins the correct user account etc.!

 

Thanks a lot for the help

[Victor]

@Aaron Carter good news

In most places the case does not matter, so this is why all (else) is working fine. But for that particular permission check it does matter. You won't encounter this issue on your daily operations but this is something that can happen if data is pulled from outside HB into HB (either via an import tool or using API integrations for other operations)