Content
View differences
Updated by Niels Lindenthal about 10 years ago
**Acceptance criteria**
- When switching from list view to split view there is no additional server request required to show the information on the overview tab. Information like the last activity is loaded asynchronously. Information like watchers and relations are loaded when required.
- When switching between split view and fullscreen view, there should be no server request for the available attributes. Information that are not available yet such as activity and relations should be reloaded asynchronously when work package is active and visible in split view. There should be an animation for the stuff that needs to be loaded.
- There is an animation to show the loading of missing data, e.g. watchers or relations.
<!-- end list -->
- Changes in the split view should be reflected without a reload in the list view.
- Example 1: The user changes the work package subject in the split view. The new title is shown in the list without a complete reload of the list.
- Example 2: The user changes an attribute so it does not correspond to the filter criteria. -\> The work package is still shown at the same place igonring the filter criteria, grouping and sorting.
- Example 3: The user creates a new work package. After saving the work package it should be shown in the list without reload of the list.
- The list is filtered for type *bugs*. The user changes within the split view the title from bug to *feature* -\> the work package is removed from the work package list without reload.
- The list is grouped by *Assiggne*. The user changes the *Assignee* in the split view -\> the work package is moved to the correct group in the work package list.
**Open**
- If we do not reload the screen with new data from the backend. How do we prevent to show outdated information.
- Example: User A opens the split view. User B makes a change. User A changes to another view. What happens in this case?
- Option: In this case the user cannot update the work package because he wants to modify an old version. in this case the user should get a hint that he needs to reload the page as the information is outdated. Reloading immediately is maybe a not so good idea because one may copy an already entered comment or so.
- When switching from list view to split view there is no additional server request required to show the information on the overview tab. Information like the last activity is loaded asynchronously. Information like watchers and relations are loaded when required.
- When switching between split view and fullscreen view, there should be no server request for the available attributes. Information that are not available yet such as activity and relations should be reloaded asynchronously when work package is active and visible in split view. There should be an animation for the stuff that needs to be loaded.
- There is an animation to show the loading of missing data, e.g. watchers or relations.
<!-- end list -->
- Changes in the split view should be reflected without a reload in the list view.
- Example 1: The user changes the work package subject in the split view. The new title is shown in the list without a complete reload of the list.
- Example 2: The user changes an attribute so it does not correspond to the filter criteria. -\> The work package is still shown at the same place igonring the filter criteria, grouping and sorting.
- Example 3: The user creates a new work package. After saving the work package it should be shown in the list without reload of the list.
- The list is filtered for type *bugs*. The user changes within the split view the title from bug to *feature* -\> the work package is removed from the work package list without reload.
- The list is grouped by *Assiggne*. The user changes the *Assignee* in the split view -\> the work package is moved to the correct group in the work package list.
**Open**
- If we do not reload the screen with new data from the backend. How do we prevent to show outdated information.
- Example: User A opens the split view. User B makes a change. User A changes to another view. What happens in this case?
- Option: In this case the user cannot update the work package because he wants to modify an old version. in this case the user should get a hint that he needs to reload the page as the information is outdated. Reloading immediately is maybe a not so good idea because one may copy an already entered comment or so.