# Feature AGILE-285 - Show children as related wp table for Epic and User story (default seeding)

Project: Stream agile
Status: closed
URL: https://community.openproject.org/work_packages/AGILE-285

## Planning

| Attribute | Value |
| --- | --- |
| Date |  |
| Priority | Medium |
| Target versions | 17.8.0 |
| Sprint | Sprint 7 |
| Backlog bucket |  |
| Votes |  |
| List |  |
| Roadmap |  |
| Relevance |  |

## OPEN POINTS / FEEDBACK

_No work packages_

## Features and Chunks

_No work packages_

## Bugs and other work packages

_No work packages_

## Technical Details

| Attribute | Value |
| --- | --- |
| Module | DevSecOps / Seeding, Modules and project features / Work packages |
| Feature Flag |  |
| Requires doc change | No |
| Enterprise plan |  |

## Details

| Attribute | Value |
| --- | --- |
| Pull preview |  |
| Mockups |  |
| Accessibility | No |

## People

| Attribute | Value |
| --- | --- |
| Assignee |  |
| Accountable |  |
| Product manager |  |
| Developers | Jens Ulferts |
| Designer |  |
| Ordered by |  |
| Signed off by |  |
| Interest by |  |

## Estimates and progress

| Attribute | Value |
| --- | --- |
| PD (min) |  |
| PD (max) |  |
| Work |  |
| Labor costs |  |

## Description

**As** a new user of OpenProject  
**I want to** have it configured optimally with demo projects  
**so that** I can experience main features and capabilities

ok, not sure the User story format (As ... I want to ... so that ...) works here, let me try JTBD format:

**When I** look at an epic or a user story,  
**help me** see its children directly in the work package page  
**so I avoid** going to the relations tab to list children and add new ones,   
**and I gain** the knowledge that having embedded tables in the work package page is possible

**Acceptance criteria**

*   After installation/trial start, "Epic" and "User story" work package types have a related and embedded table showing their children on top of their form configuration
    
*   Adding a table of related work packages is an Enterprise feature (available from Basic plan), as such:
    
    *   When instance has active Enterprise plan: they can edit the related wp table and add new ones (already 17.5 behavior)
        
    *   When instance does not have active Enterprise plan: they cannot edit the related wp table, they cannot add new table. And the related wp table is still visible in work package page (already 17.5 behavior)
        
    *   (So nothing changes about it)
        
*   For Epic:
    
    *   Filter work packages by relation type: Children
        
    *   Name: User stories and bugs
        
    *   Filters:
        
        *   Type: "User story" or "Bug"
            
        *   ~~Sprint: open or started (current and future sprints)~~ This filter operator is not supported for sprints. Additionally, it would lead to the stories/bugs disappearing over time leading to a false impression.  
            
        *   no status filter (closed items are visible)
            
    *   Columns:
        
        *   ID
            
        *   Subject
            
        *   Status
            
        *   Assignee
            
        *   Story points
            
        *   Sprint
            
    *   Sort by:
        
        *   Status descending (wip first)
            
        *   Sprint ascending (current sprint on top (wip items), then next sprint, then next x2 sprint, ..., then no sprint)
            
        *   Position ascending (have same order as defined in sprint for non-wip wp)
            
        *   (makes sense?)
            
*   For User story:
    
    *   Filter work packages by relation type: Children
        
    *   Name: Tasks
        
    *   Filters: none
        
    *   Columns:
        
        *   ID
            
        *   Subject
            
        *   Type
            
        *   Status
            
        *   Assignee
            
        *   Sprint
            
    *   Sort by:
        
        *   status desc (wip first)
            
        *   ID asc (older first)
            
        *   (any better suggestion?)
            

<img class="op-uc-image op-uc-image_inline" src="/api/v3/attachments/921891/content">

**Technical notes**

*   The related wp tables are added during seeding of demo projects
    
*   The related wp tables are **not** added to already seeded demo projects
    
*   Related work package table names must be translatable (using `t_` prefix in `standard.yml`)
    
*   Group attributes are managed in `app/models/type/attribute_groups.rb`.
    
*   db field is `attribute_groups` in `types` table. It&#x27;s a serialized array.
    

**Permissions and visibility considerations**

*   Related work package tables are always seeded when the Scrum demo project is created
    
*   It&#x27;s ok if related work package table is visible on work package page when people do not have an Enterprise plan.
    
    *   That&#x27;s already 17.5 behavior
        
    *   They just can&#x27;t edit it or add new ones.
        
    *   actually it teases OpenProject capabilities about related work package tables feature
        

**Translation considerations**

*   related table names must be translatable (use `t_` prefix in `standard.yml`)
    

**Out of scope**

*   Set proper Sprint value to items in Scrum demo project (still uses the Version field as if Version field is holding Sprint information)