Skip to content
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

Jira widget: single-word status does not show #574

Closed
lesteenman opened this issue Aug 30, 2019 · 8 comments
Closed

Jira widget: single-word status does not show #574

lesteenman opened this issue Aug 30, 2019 · 8 comments
Labels
🐛 bug "Houston, we've had a problem."

Comments

@lesteenman
Copy link
Contributor

lesteenman commented Aug 30, 2019

What's broken?

If an issue has a name that's only a single word, it's not shown. E.g., we have statusses like Ready for release, which is shown. Doing, however, is hidden.

This seems to be caused by the color formatting. I suspect a single word in square brackets (e.g. [Doing]) is parsed as a formatter code, and therefore stripped.

Screenshot 2019-08-30 at 15 36 38

I've solved this in a local build by replacing the square brackets with parentheses. See attached screenshot.

Screenshot 2019-08-30 at 15 36 47

If this is an acceptable workaround, I'm willing to make a PR for it.

@lesteenman
Copy link
Contributor Author

Alternatively, we could change it to match the original proposal's layout: #203 (comment)

@Seanstoppable
Copy link
Collaborator

I think either of those are reasonably. Spacing + different colors make the column differences fairly clear from screenshots.

@senorprogrammer senorprogrammer added the 🐛 bug "Houston, we've had a problem." label Aug 30, 2019
@senorprogrammer
Copy link
Collaborator

I think you're right about the cause and your solution sounds good to me. A PR would be appreciated, thanks!

@lesteenman
Copy link
Contributor Author

lesteenman commented Aug 31, 2019

When implementing the column-based layout as shown in the original proposal (which I personally prefer), I ran into the issue of column widths, as can be seen in this screenshot:

image

This issue already exists if you have longer issue types, as can be seen above as well.

Having a lot of varying column positions (as in the screenshot), does not make for an easily scannable display. Having everything in view at a glance is one of the main reasons to use WTF for me personally.

I added functionality to first find the longest value in each column, and use that to determine that column's amount of padding. However, there are possible issues with this, mainly the possibility of there being a very long status or type name.

I would like the opinion of experienced collaborators on this. I would prefer capping the length at e.g. 16 characters, and cutting off the column contents there.

@lesteenman
Copy link
Contributor Author

My main question for now is:

  • do the above examples look acceptable to merge
  • should I cap column lengths at a number of characters, or leave it like this

@lesteenman
Copy link
Contributor Author

For comparison, this is what capping the max length would look like:

image

I do not know if this matches the standards of WTF.

@senorprogrammer
Copy link
Collaborator

Looks good to me. I think that's a reasonable approach until we can get proper table support for sections like this implemented.

@senorprogrammer
Copy link
Collaborator

Fixed by #591

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug "Houston, we've had a problem."
Development

No branches or pull requests

3 participants