See all Issues

[parabolika66]

As a user I want to be able to find all issues, including old and closed ones in order to clean up or remember old sketches or reopen one.

Comment: Idea: Checkbox 'Show closed issues' on main list with relevant issues.

Related:

• 7

[adiherzog]

It would be nice to have a filter "my issues", but that's probably not possible without a proper user management.

[MyrionPhoenixmoon]

You will be able to filter by author, however. If you consistently use 'adiherzog' as the author when you create proposals, for example, you will be able to recreate this filter, even without user management.

[bruderol]

discussed proposal with @adiherzog yesterday in train as a first MVP-approach to this user story (goal of this proposal: most value for the users without putting to much effort in this): Instead of developing one big list (with all issues of all branches) we think it is more important to have an "Issues" tab on the starting page of Scenarioo, that contains all issues of the currently selected branch only. We would like to see this implemented first, and not implement an overall list (in this first version) at all (because we think this is not necessarily needed). Most users are only interessted in issues on the branch that they are usually working on.

To distinguish the tab (that it is not "documentation" but "design" = AS IS view versus TO BE view) from "documentation"-domain, we propose to simply use a special color for this tab and for all other new parts in the application that are related to the design domain), see also story #40

The tab could be simply implemented the same as the current "Use cases" tab implementation (same table, same filtering functionality).

[bruderol]

One remark about a potential issue to solve for this story or for the IssueSketcher in general (came to my mind only yesterday):

Did we talk about branch aliases and has this been covered in the concept?? What if a user creates an issue in a branch that he currently selected through its alias name. When later the alias points to another branch, will this issue no more be visible under the same URL?

I see two variants for this problem:

1. we ignore this problem, issues are allways stored under the real name of a branch
2. we distinguish between issues for a branch alias (and keep this issues with the alias) and other issues directly attached to a real branch. This would mean that the user sees different issues on the same branch, depending through which URL/dropdown-item (alias or real name) he selected the branch. This could be an interessting "feature", because we could have a "design"-branch always pointing to the current released version for designing new issues, also we could have another alias (to the same branch) like "operations" for sketching productive issues.

I think that the second variant has a lot of potential for giving the projects a powerful tool for grouping issues in special branches, using an allready exsiting powerful tool called "branch aliases". This should not add a lot of additional effort to the IssueSketcher project, it only means that issues and sketches are allways accessed relative to the currently selected branch name (alias or real name).

@adiherzog @parabolika66 @MyrionPhoenixmoon What do you think about this?

[bruderol]

Additional remark to my last remark, about the advantages I see with variant 2 (issues attached to branch alias names): The proposed second variant has also the advantage, that it gives the users of scenarioo the power to decide to only design issues on special "issues-xx" branch aliases to keep this issues clearly separated from usual "documentation only"-branches. Users can define from project to project where they want to store (under what branches or aliases) the issues. Even more it helps to keep "issues-for-release-xx" separated from current productive release documentation.

[adiherzog]

The alias ideas are interesting and maybe we can come back to this topic for the third milestone. But for the moment all issues should be stored in the folders that are named after the actual branch, in which they were created.

I don't like the idea of abusing the alias concept for something else. So if we follow Rolfs idea later, we probably have to either invent a new concept than aliases or we have to extend / rename the alias concept.

[bruderol]

After I talked with Adrian yesterday, I realized, that my idea (about which I was very enthousiastic first) seems not to be so intuitive to others (and therefore needs to be detailed/sharpened first), so let's forget about it for now, as proposed by Adrian. Thanks, and sorry for bringing up this point. For now we have to stick to variant 1, as mentioned in my comment (= ignore it).

Probably we have to open a separate issue for this problem, that I decribed (loosing designs on aliases, when a alias is pointing to a different branch, which e.g. happens after a release) for later milestones or even just in the scenarioo backlog (for later projects/releases).

[parabolika66]

@MyrionPhoenixmoon Route for all issues: /branch/:branchName/issues