Skip to content

Viewing issues and PRs in CLI should show the state (open, closed, merged) #652

Description

@doi-t

Describe the feature or problem you’d like to solve

Currently, issue view --preview shows who created an issue regardless of its state.

Screenshot 2020-03-14 at 5 35 27

However, I think that what we actually want to see is the last event state such as Opened, Closed and Reopened (I guess Locked, Unlocked and Transferred could be included) and who made the last event.

Proposed solution

IssueTimelineItemsItemType provides various issue events and we can extract the last event.

Ref. https://github.community/t5/GitHub-API-Development-and/GraphQL-repo-issues-has-no-closedBy-field/m-p/26858/highlight/true#M2173

I gave a shot with 58f6be...doi-t:cf6e746 and it seems it is possible to do like below. These captures show the last state and its actor instead of the author of the issue.

Screenshot 2020-03-14 at 5 33 32
Screenshot 2020-03-14 at 5 33 02
Screenshot 2020-03-14 at 5 34 06

If it makes sense to everyone and is fine with contributing guide, I'd happy to work on it with unit tests for each event.

Activity

  1. billygriffin commented on Mar 13, 2020

    @billygriffin
    Contributor

    Thanks @doi-t! I'd love to hear @ampinsk's thoughts, but in trying out several things, I think the biggest missing piece of context is the current state, not the last event. For example, when I'm viewing an issue on the web, its status is unambiguous.

    Screen Shot 2020-03-13 at 3 46 10 PM

    However, that same issue, when viewing it in terminal, looks like this.

    Screen Shot 2020-03-13 at 3 46 59 PM

    And even when viewing the whole preview in terminal, there's no way to see that the issue I'm looking at is actually closed. That strikes me as one of the most critical pieces of context when viewing an issue. So in my view, it's less about what the last piece of activity was (because that's ambiguous in terms of what information it's conveying), and more about the issue or PR's current status.

    I don't have a strong opinion about how to convey that information and would leave that to @ampinsk to make a call on, but I do think it should be prominent. Curious your thoughts.

  2. ampinsk commented on Mar 13, 2020

    @ampinsk

    Agree with @billygriffin's points here! Basically, "opened by" really means the author and that should stay consistent. But if we want the state to be clearer, and to be more parallel with github.com, I think we could do that like so:

    Screen Shot 2020-03-13 at 3 17 58 PM

    We can also do this for PRs, but keep the metadata on PRs the same as it is now

    Screen Shot 2020-03-13 at 3 31 39 PM

    Note: This change means removing labels from this header

  3. changed the title [-]`issue view --preview` should show the last event[/-] [+]Viewing issues and PRs in CLI should show the state (open, closed, merged)[/+] on Mar 13, 2020
  4. doi-t commented on Mar 14, 2020

    @doi-t
    ContributorAuthor

    I see! It is simpler than what I thought and unambiguous as I wanted. 👍 👍 I understand that view --preview is based on the title and description with some metadata at the top on the web.
    If it's ready to go and fine to take it, I can work on it. 🙋‍♂️

  5. billygriffin commented on Mar 16, 2020

    @billygriffin
    Contributor

    @doi-t We discussed this this morning, and if you'd like to do this, please go ahead. One note is that "Merged" (in purple) should be a possible state for PRs as well. Thanks!

  6. doi-t commented on Mar 18, 2020

    @doi-t
    ContributorAuthor

    @ampinsk
    I've added the Draft PR state in #667 which was not mentioned in #652 (comment). I picked Gray color as same as gh pr status. Please check it out along with other designs.

    In addition, is it expected to use • (Bullet: U+2022) as a separator?

  7. ampinsk commented on Mar 18, 2020

    @ampinsk

    I've added the Draft PR state in #667 which was not mentioned in #652 (comment). I picked Gray color as same as gh pr status. Please check it out along with other designs.

    Perfect, sounds good!

    In addition, is it expected to use • (Bullet: U+2022) as a separator?

    Yes, exactly. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementa request to improve CLI

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions