Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Introduction

Users can make a table in free format report to grow horizontally in case the content doesn’t fit.

Functional design

  • We should add the check-box “Grow Horizontally” in Edit layout mode > Control settings for a Table control.

  • When “Grow Horizontally” is set to true:

    • If the content fits in the table, then nothing happens.

    • If the content doesn’t fit in the table, then:

      • Use the empty space within the table

      • Decrease the font size of the content

      • Then the table should grow to the right till the content fits - Look at Zeplin

      • After that the report should be recentred in a screen by using the empty space on the left - Look at Zeplin

      • Controls with overlapping height should be pushed to the right till the table is fully expanded

        • We always keep the space between expanded table and other controls as it was designed

      • Controls without overlapping height should remain on the same relative place within the report

      • POV selectors, key message, and controls that aren’t moving to the right shift together with the left side of a report

    • If the table content decreases, then:

      • The table should shrink back (but not less than original width)

      • Controls with overlapping height should be pushed to the left keeping the original distance between

      • The report should be recentred again

Edge cases:

  • Cascading effect: - Look at Zeplin

    • Controls that vertically overlap with controls that have overlapping height with the growing table should be pushed to the right - Look at Zeplin

  • The behaviour of overlapping controls is not changed.

  • Horizontally and vertically growing table in separate steps:

    • Diagonally affected control should be pushed based on the last step: - - Look at Zeplin

      • If growing control first grows horizontally and then vertically, diagonal control is pushed down - Look at Zeplin

      • If growing control first grows vertically and then horizontally, diagonal control is pushed right - Look at Zeplin

      • In case of two horizontally and vertically growing tables, same rules apply as in ‘two horizontally growing tables’

  • If the table grows horizontally and vertically in one step, then all diagonally affected controls move down - Look at Zeplin

Functional Requirements

The following table shows how the overall user story is subdivided into smaller sub user stories, which are detailed below.

#

Title

User Story

JIRA Story

MoSCoW *

Vertical growth of tables

A vertical growth of tables should be supported as in the table from a report "Profit and Loss incl. Trend". 














*) MoSCoW = Must have, Should have, Could have, and Would like but won't get.

Step

Title

Wireframe

Notes

1.1

Vertical growth of a table of a multicolumn report

  • If a user has drilled a row(s) in a table of a multicolumn report, this table should grow vertically automatically till all content in the table becomes visible.  

1.2

Vertical growth of a table of a free format report

  • If a user has drilled a row(s) in a table of a free format report, a table control shouldn't grow vertically by default. 

  • If a content is large, than the size of a table then a vertical scroll-bar should appear in the right side of a table.

  • If the setting "Grow vertically" is set for a table in designer, then it should grow vertically automatically till all content in the table becomes visible. A user can limit the vertical growth of a table with the setting "Maximum Height". (For more details look here: Vertical stretching of free format controls: table, comments, news). 


Questions

#

Question

Answer











Technical Requirements

Audit Trail

Action

Message







Permissions

Function

Position in System

Authorization Rule











Changes to database schema and migration

Does the story change the database schema? Does the story require data migration? Does the story require application configuration migration? 

Changes to domain model

Does the story change the domain model?

Changes to components

Does the story require new components to be added or render existing components obsolete? Does the story require changes in how components communicate to each other? 

Changes to target infrastructure or platform

Does the story require changes to the target infrastructure or the required platform? Does the story require components to be installed on different servers?

Non-functional requirements

Does the story have specific non-functional requirements: security, performance, availability, etc.?

Rationale

The following table show the important technical decisions made during the design of this user story.

#

Issue

Alternatives

Decision















  • No labels