[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: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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
|
| Comment by Jason Skomorowski [ 06/Oct/17 ] |
|
They're blocked for a number of reasons:
|
| Comment by Cate Boerema (Inactive) [ 06/Oct/17 ] |
|
Thanks, Jason Skomorowski! A couple thoughts.
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
Last I heard, Jeremy thought this would be done before Monday.
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?
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
|
| Comment by Mike Taylor [ 09/Oct/17 ] |
|
I think 462 is correct. I removed the dependency on 426 and replaced it. |