-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Display issue closed reason in timeline events #1223
Conversation
private static final int[][] ISSUE_HEADER_COLOR_ATTRS = new int[][] { | ||
{ R.attr.colorIssueOpen, R.attr.colorIssueOpenDark }, | ||
{ R.attr.colorIssueClosedCompleted, R.attr.colorIssueClosedCompletedDark } | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the issue activity distinguishes between 'open', 'closed' and 'completed' now, I think the issue list activity should do the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't agree on this... "completed" is the reason why an issue has been closed, it isn't a third state.
Furthermore, if we follow this logic, the three tabs should be called "Open", "Not planned" and "Completed". But even in that way it would look overkill IMHO, considering how the GitHub UI displays the new close reasons.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'Completed' basically is the equivalent of the 'merged' PR state: 'closed as done' ... treating it that way in the UI doesn't seem like overkill to me, but rather more consistent?
So IMO it should be either 'show all closed issues, with red header' or 'distinguish between closed and completed, using the respective colors'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'Completed' basically is the equivalent of the 'merged' PR state: 'closed as done'
Mmhh... I believe it's a bit of a stretch to see "closed as completed" in the same way as the Merged state.
The GitHub UI emphasizes it differently (there's no "Completed" purple pill for issues like the Merged pill for PRs) and there's also the fact that all old issues are displayed as "closed as completed" while they might have been closed for other reasons... this is why I don't like having a "hard" separation in the app.
My idea in this PR was to replicate the GH web UI behavior in the app, with the only difference that not planned is red instead of grey.
show all closed issues, with red header
I guess it could be fine, but what about using purple for all issues instead? Red is not used anymore for issues in GitHub UI and the completed-purple has become the "default" closed color.
@maniac103 I've removed the commits that change the header colors, can this be merged as-is for now? |
This PR keeps OctoDroid up with the changes GitHub has recently made to the "closed" issue status:
closed
timeline eventthe IssueActivity/Fragment color has been changed to purple if the issue is closed as completed.For closed as not planned issues I've kept the classic red color - even if GitHub UI uses dark grey - for consistency with the closed red icon that is already used in the app, and because the grey color used by GH is very similar to the grey used for PR draft status (and draft issues may be a thing in the future, according to the issue linked above)the Closed tab in the Issues list has had its color changed from red to purple (since issues are by default closed as completed)following the same logic, the color of the My issues list has been changed to purple when showing closed issueslocked
timeline event when availableI haven't added the ability to close an issue as not planned since it seems it can't be done via the REST API: we need to use the closeIssue GraphQL mutation. Also, when we introduce that feature, the UI will need to be revised since it's possible to change the closed reason of an issue by "re-closing" it.
A few more technical details that will be useful while reviewing this:
stateReason
field is null if the issue was closed before the introduction of closed reasons. The GitHub UI displays the event with closed as completed whenstateReason
iscompleted
ornull
stateReason
field is never null for closed issues: it's set tocompleted
for both closed as completed issues and issues that were closed before the introduction of closed reasons