[UIU-384] Navigation/Display problem when moving from one app to another Created: 14/Feb/18  Updated: 03/Jul/19  Resolved: 13/Mar/18

Status: Closed
Project: ui-users
Components: None
Affects versions: None
Fix versions: 2.13.0

Type: Bug Priority: P3
Reporter: Ann-Marie Breaux (Inactive) Assignee: Michal Kuklis
Resolution: Done Votes: 0
Labels: sprint32, sprint33
Remaining Estimate: Not Specified
Time Spent: 1 hour
Original estimate: Not Specified

Attachments: Microsoft PowerPoint FOLIO Navigation Problem.pptx    
Issue links:
Blocks
is blocked by STCOR-134 The anointed resource is not being co... Closed
Relates
relates to UISE-56 After linking out to another app, str... Closed
Sprint:
Tester Assignee: Ann-Marie Breaux (Inactive)
Analysis Estimate: None
Analysis Estimator: Cate Boerema (Inactive)
Back End Estimator: Jakub Skoczen
Front End Estimate: Medium < 5 days
Front End Estimator: Jakub Skoczen

 Description   

Overview: See attached PPT documenting a UX/Navigation concern
1. When you move away from an app, and then come back to it, FOLIO seems to leave the app in the last display state it was.
2. That means when you click a user name hotlink in the referring app (in this case, the requests app), you get inconsistent results. One time, the tri-pane with user info pane opened. The next time, the user list, with no user info pane.
3. That seems like a problem/unexpected behavior.

Steps to Reproduce: see steps in the PPT. These screenshots were taken from http://folio-testing.aws.indexdata.com/, logged on as diku_admin

Expected Results: Same list/details/tri-pane display whenever I click on a link in the requests app that takes me over to the users app.

Actual Results: Inconsistent displays. Screen display seems to be staying in whatever state it was previously.

Interested Parties: Mark Veksler Cate Boerema Ann-Marie Breaux



 Comments   
Comment by Cate Boerema (Inactive) [ 14/Feb/18 ]

Not sure if this is a ui-users bug or something more general in stripes. John Coburn or Mike Taylor, do you have thoughts on where this belongs?

Comment by Ann-Marie Breaux (Inactive) [ 14/Feb/18 ]

Hi Cate Boerema - how did you assign it to UIU? Can't quite figure out that part

Comment by Cate Boerema (Inactive) [ 14/Feb/18 ]

When you create a new bug, there is an option for Project where you can select, for example, UIU or FOLIO. Once the issue has been created, to move it you just need to go to More > Move.

Comment by Cate Boerema (Inactive) [ 14/Feb/18 ]

Just removed you from the Assignee field. It's important that we leave that Unassigned so a developer can pick it up. I did put your name into the Tester Assignee field, though, so that when it is marked In Review, it will be reserved for you to test

Comment by Ann-Marie Breaux (Inactive) [ 14/Feb/18 ]

Sounds good - thank you. I think I accidentally assigned it to myself when I was trying to figure out the FOLIO vs UIU thing. Appreciate you straightening it out!

Comment by Mike Taylor [ 14/Feb/18 ]

Thanks for this very clear report.

The problem here looks like it's in the Requests app: it is its responsibility to ensure that whenever it redirects to a user in the Users app, it goes to that user's record rather than just to the Users app in general.

In the PPT that you attached, the URL after following the second requester link displays as the no-record-selected URL of the Users app rather then the URL of the specific user – compare to the URL after you followed the first link. So the issue is not just that Requests is linking to the right place but Users is displaying it wrongly.

But why did I hedge by saying that this problem looks like it's in Requests? Because it smells a bit similar to other oddities we've seen when linking from one Stripes app to another: see UISE-56 Closed . We think, though we don't know, that this complex of behaviours is related to an underlying stripes-core issue to do with navigation in general ( STCOR-134 Closed ), which Zak Burke is investigating.

My suggestion: there's probably not much point in trying to fix the present issue in isolation, because we'll know more once we have STCOR-134 Closed sorted – indeed, it might just straight-up solve this issue. So I am going to link this issue to STCOR-134 Closed and mark it as BLOCKED for now.

Comment by Zak Burke [ 28/Feb/18 ]

I agree with Mike Taylor; this smells like other problems that were related to STCOR-134 Closed . (The other possibility, that requests did not correctly specify the link into ui-users, does not appear to be the case here.) I'll mark this "In Review" and reassign to Michal Kuklis so he gets credit for the fix.

Comment by Ann-Marie Breaux (Inactive) [ 13/Mar/18 ]

Seems like it's working properly now, at least in terms of bringing you to the proper user detail page. Closing this ticket.

Generated at Thu Feb 08 23:10:33 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.