[FOLIO-725] Navigational Elements in FOLIO Should Support Right Click to Open in New Tab Created: 18/Jul/17  Updated: 12/Nov/18

Status: Open
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Umbrella Priority: P2
Reporter: Cate Boerema (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: 1 hour, 30 minutes
Original estimate: Not Specified

Issue links:
Blocks
is blocked by UIIT-46 Edit Item Page Should Have Own URL Closed
is blocked by UIIT-47 Create New Item Page Should Have Own URL Closed
is blocked by UIU-141 Create New User Page Should Have Own URL Closed
is blocked by UIU-142 Edit New User Page Should Have Own URL Closed
is blocked by UIU-143 User Loans Page (Open Loans Tab) Shou... Closed
is blocked by UIU-145 Loans Details Page Should Have Own URL Closed
is blocked by UIU-230 User Loans Page (Closed Loans Tab) Sh... Closed
is blocked by STCOM-24 Button component should support rende... Closed
is blocked by STRIPES-462 Factor out shared code in search-base... Closed
Relates
relates to UIIN-126 Edit Holdings Page Should Have Own URL Closed
relates to UIIN-123 Item Detail Page. Should Have Own URL Closed
relates to UIIN-124 Holdings Detail Page. Should Have Own... Closed
relates to UIIN-125 Edit Item Page Should Have Own URL Closed
Sprint:

 Description   

Purpose: All navigational elements in FOLIO should support right click to open in new tab (this will support multi-tasking using built-in browser capabilities). In order for this to work, buttons need to be styled as anchors (component work) and pages need their own URL so there is somewhere specific to go tp.

This umbrella issue will include links to specific items that should be fixed as part of this project.



 Comments   
Comment by Cate Boerema (Inactive) [ 06/Oct/17 ]

Mike Taylor, Jason Skomorowski, there are all these stories about making sure each page has it's own URL. They are currently in Blocked status. Are we working on the blockers? Do you think we can unblock them soon?

Comment by Mike Taylor [ 06/Oct/17 ]

I should be able to work on STRIPES-462 Closed next week.

Comment by Jason Skomorowski [ 06/Oct/17 ]

They're blocked for a number of reasons:

  • if we want to routinely assign URLs for modals it would be good to have a general approach for these STRIPES-451 Closed
  • since the plan was to potentially address this with URL parameters and the way we assign URL parameters is changing (lots of movement on that this week) it's blocked on STRIPES-452 Closed
  • if the STRIPES-462 Closed work is going to include links to any associated modals (such as create/edit), we'll want to make sure the URLs are consistent
Comment by Cate Boerema (Inactive) [ 06/Oct/17 ]

Thanks, Jason Skomorowski! A couple thoughts.

if we want to routinely assign URLs for modals it would be good to have a general approach for these STRIPES-451 Closed

Let's use "modal" to describe those interstitial screens that force the user to interact with them by inactivating everything in the background via a transparent grey layer. For example, the user search and select component in Check Out is a modal. We don't want URLs for these.

By this definition, Loans and Loan Details are not modals. They are currently implemented as a kind of overlay that obscures much but not all of the application (you can still click around in the top nav). It needs to be closed using an X in the upper left. We are changing that, though. Filip would like us to move to a back button instead of the X - there will be breadcrumbs too. But, that's all beside the point. The point is that these pages aren't modals but they do need URLs

since the plan was to potentially address this with URL parameters and the way we assign URL parameters is changing (lots of movement on that this week) it's blocked on STRIPES-452 Closed

Last I heard, Jeremy thought this would be done before Monday.

if the STRIPES-462 Closed work is going to include links to any associated modals (such as create/edit), we'll want to make sure the URLs are consistent

Mike said he'd take this on in sprint 24

Comment by Mike Taylor [ 06/Oct/17 ]

Why wouldn't we want URLs for modals?

Last I heard, Jeremy thought this would be done before Monday.

Sorry, but it won't be by Monday (unless Jeremy gets superpowers). See https://docs.google.com/document/d/1IQhCPX899V8m0ZgKNQx2Y51BobAXjP1y25tn9bemN2c/edit?ts=59d66837#heading=h.dxzjoqs98v10

Comment by Cate Boerema (Inactive) [ 07/Oct/17 ]

Because modals are usually interstitial pages that don't make sense to link to outside of a complete workflow. Think about the user search and select modal on the checkout page. Why would you want to link to that? Anyway, I suppose if we later decide we need URLs for modals we can figure out how to implement them. Does that make sense to you guys?

Comment by Mike Taylor [ 07/Oct/17 ]

Hmm. Well, I suppose it's really that I don't really see the point in not have URLs that capture the state of modals. But, no matter, it'll be easy enough down the line to move the state of modals into the anointed resource that gets persisted to the URL. So we can leave this undone now, without committing ourselves to a future policy.

Comment by Cate Boerema (Inactive) [ 09/Oct/17 ]

Hey guys, there are lot of references to STRIPES-462 Closed in the above comments, but that issue isn't even linked to this one. Did we really mean STRIPES-426 Closed ?

Comment by Mike Taylor [ 09/Oct/17 ]

I think 462 is correct. I removed the dependency on 426 and replaced it.

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