Jump to content

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


Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

@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

 

Link to comment
Share on other sites

@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? 

image.png.ec33fe14cc9b1043485bc13954fe7283.png

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

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

@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.

  • Like 1
Link to comment
Share on other sites

@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)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...