cityofaustin / cityofaustin/techstack

Bidirectional relationships: pages

Open
#4,188 0 comments 0 reactions 0 assignees View on GitHub
Joplin Alpha Team: Dev
Dominant language
No language data
Stars
11
Forks
3
PR merge metrics
No merged PRs in 30d

Description

May need to split further.

### As a content author, I want to be able to manage relationships between multiple pages from each side of the relationship, so that I can effectively manage content without having to the page I'm currently editing.

Examples:
- Locations
- Location pages ⟷ department pages
- Location ⟷ service pages
- Location ⟷ event
- Top pages ⟷ department pages
- Top links ⟷ topics
- Pages ⟷ topics
### Requirements
#### Locations
Currently, a user selects a location page from a department, service, or event.
- [ ] From a location edit page, a user can see every page that the location is selected.
- [ ] They are able to see whether those pages are LIVE or DRAFT (status)
**Do we want to be able to _edit_ from this page? I don't think that's a need for locations, or at least low priority.**
#### Top pages on departments
Currently, a user selects which pages will appear as "Top services" for a department when editing the department page. Only the following published page types may be chosen for this field: Information page, Service page, Guide page, Official document page. The page picker excludes pages of other types.
- [ ] From editing an information page, service page, guide page, or official document page, a user can see if it is assigned as one of a department's top services
**Do we want to be able to _edit_ from this page? It seems to make most sense to me to curate the top services from the department page, and lower priority (or unnecessary) to be able to set it from the content pages. Also, we have a limit of four top services, so how would we enforce that from elsewhere?**

Additional note: You can choose ANY page as a top service, even if it's not assigned to permissions for that department. We might want to limit the pickers to only display pages from that department.

#### Top links on topic pages
Currently, a user selects a topics' top links from the topic page. Only the following published page types may be chosen for this field: Information page, Service page, Guide page, Official document page. The page picker excludes pages of other types.
- [ ] From editing an information page, service page, guide page, or official document page, a user can see if it is assigned as a top links for any topics
**Do we want to be able to _edit_ from this page? It seems to make most sense to me to curate the top links page from the topic, and lower priority (or unnecessary) to be able to set it from the content pages. Also, we have a limit of four top links, so how would we enforce that from elsewhere?**

Additional note: You can choose ANY page as a top link for that topic, even if it's not a part of that topic. We might want to limit pickers to only display within that topic.

#### Pages and topics
Currently, we assign a content page to a topic from the **individual content page**. In addition, we want to be able to: **Content and design, please review and tell me if this seems right**
- [ ] From a topic edit page, a user can see all of the pages assigned to that topic
- [ ] From a topic edit page, a user can use a page picker to assign a page to that topic
- [ ] This is limited to content types that include topics as part of their data model
- [ ] If a user does assign a page to a topic via the topic edit page, they can later then go to the individual content edit page and manage the topic relationship from there.

### To test
tbd
### Test data
tbd

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.