fusionbox / buggy Goto Github PK

First chapter failed to grab my attention. I was asleep by the middle of the second chapter. None of the characters are relatable and they're all two-dimensional.

Allow saving the current search criteria with a name, to quickly go to that search later.

The columns headers in the bug list table should be clickable to sort by that column.

Given the markdown <google.com>, I expect output of either <google.com> or <a href="http://google.com">google.com</a>, but instead the output is <p><google.com></google.com></p>

This is because markdown isn't recognizing google as a link, so it outputs it as-is. Bleach thinks it's a tag, so it gets closed and entitized.

The way it's done now is not real fulltext search (it's just using icontains). It should be actual postgres fulltext search.

It should be possible for a git hook to add a comment through some kind of API.

• select arrow is still present
• Checkboxes are misaligned

On bug detail pages bug action timestamps should be an anchor link

You should be able to mention someone with @theirname.

This requires that user's names are case-insensitively unique and don't contain spaces.

https://www.getharvest.com/add-time-tracking

Anyone should be able to change the title of the bug. The title change show show up in the list of comments showing the old and new titles.

Buggy pages should be compatible with CSP and have the header set (through a meta tag in base.html maybe?)

1. Go to the bug create form
2. tab on to the project select
3. Select a project with enter, arrow keys, then enter
4. Press tab

I want to be placed on the title field, but instead I start tabbing from the top of the page again.

They're pretty ugly right now!

You should get an email whenever a bug is assigned to you.

In chrome 58

The bug detail view needs to show the attachments for an action.

It should be possible to undo things, in some kind of principled and perhaps logged way.

So that it filters immediately after changing a filter, instead of having to click filter.

Is this actually a good idea?

These pages should be accessible via links in the footer. All three can share the same page template.

If a user has selected tickets it might be difficult to dismiss the bulk action form. Currently dismissing the form requires either:

1. individually unchecking all selected rows
2. Checking then uncheck the table header checkbox

These methods aren't readily discoverable and depend on the users current scroll depth.
Adding a link would make the UX for dismissing this form simpler. I'd propose placing this immediately after the bug count:

There's no reason for a separate setting. A one way hash with a salt should solve this problem.

There should be a way to preview the rendered markdown output of your comment before adding it.

1. Paste some text into the search field
2. Blur

I expect the filters to update

The old buggy supported these searches with special syntax in the search field:

• assigned:foo search for bugs assigned to someone with a name of foo. me is an alias for the current user.
• created:foo
• involved:foo searches for bugs that foo has created, commented in, mentioned in, or been assigned to.
• project:foo searches for bugs in projects whose title matches the regex f.*o.*o.*
• state:resolved
• priority:high
• "foo bar" fulltext searches for foo immediately followed by bar, ie phrase search
• #:123 filters for bug number 123
• !filter negates filter

The filters combine:

• filters of the same type with OR
• filters of different types with AND

So assigned:foo assigned:bar priority:high parses as (assigned:foo OR assigned:bar) AND priority:high.

!assigned:me involved:me is (NOT assigned:me) AND involved:me

#:123 #:456 #:789 is #:123 OR #:456 OR #:789.

Apart from the relative dates, bug detail pages are easily cacheable (see a88dbca). We had to revert the caching though (c28f06f) because relative dates never get updated.

Maybe do the relative calculator on the client side so we can cache bug detail pages?