Content
View differences
Updated by Jens Ulferts 5 days ago
**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 n 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)
* 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`)
**Permissions and visibility considerations**
* Related work package tables are always seeded when the Scrum demo project is created
* It's ok if related work package table is visible on work package page when people do not have an Enterprise plan.
* That's already 17.5 behavior
* They just can'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)
**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
* 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)
* 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`)
**Permissions and visibility considerations**
* Related work package tables are always seeded when the Scrum demo project is created
* It's ok if related work package table is visible on work package page when people do not have an Enterprise plan.
* That's already 17.5 behavior
* They just can'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)