cityofaustin / cityofaustin/techstack
Bidirectional relationships: pages
- 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.