Solved

Generic Inquiry behaves differently for different users

  • 18 October 2022
  • 8 replies
  • 171 views

Badge +11

I’m afraid this is a bug, but I’m wondering if anyone else has encountered this problem.

 

I have a Generic Inquiry created for Cases. There’s nothing especially unusual about this GI. The Case ID column is mapped to a navigation parameter which opens the Case screen.

 

As my own user, the GI works fine. As several other users, the GI also works fine. As one or two particular users, the GI navigation does not work. Clicking any Case link opens the first Case in the list.

 

Of course, the first thing you’d think of is to eliminate the variables. So using my computer with my Edge browser, I open an incognito tab and using the ‘Sign in as user’ feature, I sign into these user’s accounts. Exactly the same results. Some users it works for, some it doesn’t.

 

How is this possible?

icon

Best answer by darylbowman 18 October 2022, 20:54

View original

8 replies

Userlevel 7
Badge +4

Hi @darylbowman! I have seen issues like this in the past and it can come down to a couple different things, but narrowing it down should help identify the cause.

I’ve seen an issue where the NoteID relation is being used in the GI to link to something the user does not have access to like, a note (!), or  a customization field, or restriction group possibly.

I would start by de-activating all the joins in the GI except one and see if the navigation works, then add them back one at a time to see which join is causing the problem (if this is the case).

You can also try to deactivate the restriction groups to verify they aren’t interfering with navigation, as sometimes the record will display because the user is part of allowed group, but also part of restricted group and so there is some confusion on GI form.

Otherwise I would try having no cusotmizations running to see if it could be an access issue to customized data coming in.

Lastly, I’ve seen this issue a lot with the INItemXRef table being joined in, if applicable.

Hope this can help!

 

Badge +11

One of the affected users and one of the unaffected users have identical permissions and we don’t use restriction groups.

Userlevel 7
Badge +4

@darylbowman Does the out of the box cases primary list work correctly? Please test the steps mentioned above to peel back the layers of joins in the GI and then re-add them while testing the navigation with each join re-added.

Badge +11

I’ve never seen anything like this. Using [DisplayName] from the Contact table in Results Grid is causing the problem. Not joining the Contact table. Activating the field.

Userlevel 7
Badge +4

@darylbowman That is interesting, but not out of the scope of behavior I’ve seen in a GI. Are you also displaying the supporting Contact details like ContactCD or is the DisplayName by iteself?

Sometimes if a field which is unbound is displayed on its own then it can act strange or not display a value at all until the field is it bound to is also displayed.

Badge +11

It has something to do with trying to join CR.Location. I’ve tried joining Case to Location and Location to BAccount, and also Case to BAccount and Case to Location. Neither helps.

Am I misthinking something here?

 

 

Badge +11

I believe I solved it by including [LocationCD] from the Location table in the results along with the custom field I needed to display.

Userlevel 7
Badge +4

@darylbowman nice catch, this is a common thing I’ve seen in GIs where only the unbound field is displayed, glad it’s working!

Reply


About Acumatica ERP system
Acumatica Cloud ERP provides the best business management solution for transforming your company to thrive in the new digital economy. Built on a future-proof platform with open architecture for rapid integrations, scalability, and ease of use, Acumatica delivers unparalleled value to small and midmarket organizations. Connected Business. Delivered.
© 2008 — 2024  Acumatica, Inc. All rights reserved