Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Give iframe parent control over tab layout #331

Open
twelch opened this issue Aug 18, 2024 · 2 comments
Open

Give iframe parent control over tab layout #331

twelch opened this issue Aug 18, 2024 · 2 comments
Milestone

Comments

@twelch
Copy link
Contributor

twelch commented Aug 18, 2024

Issue: currently reports are displayed in an iframe and when you scroll the report you lose track of the Tabs.
Solution: give SeaSketch information to render its own tab layout.

Requirements:

  • Give SeaSketch information on tabs on load of iframe, such that it can render the tab layout and report does not.
  • Support a context menu (3 dot menu) that SeaSketch can put to the far right of the tabs.
  • Allow SeaSketch to trigger change of report page displayed when clicked.

Event changes:

  • seasketch init message - add renderTabs: boolean property for SeaSketch to signal intent to render tabs and report layout should not .
  • report init ready response that follows will include:
    • tabs: [{ tabId: string, accessGroups: string[], tabName: string, localization: Record<locale, label>
      • accessGroups is an indication of which groups should have access to this report
    • assume If tabs undefined, then there are no available tabs
    • See how SeaSketch passes sketch attribute localization for example data structure
  • changeTab event - tab ID. triggers report tab change

Need to review iframe API to make this spec more exact, it's off the top of my head.

@twelch
Copy link
Contributor Author

twelch commented Aug 18, 2024

@underbluewaters I'm open to suggestion on how the report should signal to seasketch who should be able to view/use a given tab. We had talked about an adminOnly property that can be provided for each tab, but that seems pretty inflexible. What if we have a specific subset of community members that should have access to a tab, instead of or in addition to admins? Maybe that's not the concern of the reporting side to control. I proposed here accessGroups: string[] instead. I'm just thinking of a structure that won't require breaking changes later necessarily.

@underbluewaters
Copy link
Collaborator

Groups is a better idea. Admins should be able to see everything anyways. I wouldn't want to use the group label since that could change, but I could make a short unique string id for groups available for copying from the admin interface.

@twelch twelch added this to the 8.0 milestone Sep 8, 2024
@twelch twelch mentioned this issue Oct 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Parking Lot / On Hold
Development

No branches or pull requests

2 participants