rgehan / octolenses Goto Github PK

For this, we should:

• Persist the count of items or an array of issue IDs in the filter
• After fetching new items, compare that count/list with the data saved, and if there are new ones, display some kind of user feedback.

Maybe add a red exclamation mark, or a red badge near the FilterLink?

Refreshing a Jira filter doesn't always work.

Sometimes it even clear it completely, forcing the user to clear the cache

Is your feature request related to a problem? Please describe.
Don't work on firefox

Describe the solution you'd like
Build and deploy the version to firefox store

Describe alternatives you've considered
Building on Code Sandbox and deploy to Now

Additional context
Data dev use Firefox at Botify, if you want success you need firefox version

Is your feature request related to a problem? Please describe.

It's unclear what PRs in the list need action based on their review status, because this info isn't displayed in the list anywhere.

Describe the solution you'd like

It would be really helpful to see some sort of status on the PR list (awaiting review, approved, etc.) so that you know what status a PR has.

Describe alternatives you've considered

I've created a workaround by adding additional lists with review status filters, which works but clutters up the dashboard.

Candidate: webNavigation

We should add some kind of ellipsis

GraphQL

The GraphQL endpoint can return both comments & reviews count:

PullRequest fragment:

comments {
  totalCount
}
reviews {
  totalCount
}

Issue fragment

comments {
  totalCount
}

REST

I think the REST endpoint only returns comments count. The value would be a bit off, but that's still better than nothing.

Make sure it works with both

When opening a new tab with octolenses, I think we should not show the URL bar like this

instead, I think it would be better if we provide the ability to search with Google, with cursor focus at the URL bar by default.

This would have a few advantages:

• We'd be able to fetch more interesting things from each PR/issue (See #37)
• We'd reach less quickly the rate-limiting as we would be fetching way less data on each search
• We could use something like apollo-client or whatever is trendy today. We'd get a caching system for free (#11)

Is your feature request related to a problem? Please describe.
Like many people I really like Momentum
as my new tab view. Since your extensions is using the same space, I have to decide which one I like / need more.

Btw. I took me a moment to figure where to find the extension.

Describe the solution you'd like
Move the extensions out of the new tab space and integrate with GitHub.com. A content script allows you do modify the DOM so you an inject a button on GitHub.com which triggers a new view.

I can imagine:

• $username or $me that would be replaced by the user's name
• More to come

Before doing that, we'd need to fetch the user's profile (/me I believe)

This would require adding some kind of transformer between the filter definition and the fetching. We could use lodash.template for the actual replacement of the variables.

• Token
• Open In New Tabs
• etc

To prevent the user from getting stuck with the "Set a valid Github token" error message

We'd need:

• Export button in the sidebar that would copy a serialized filter definition to the clipboard
• An import button that would allow that serialized filter to be pasted, then imported.

It could allow quick access to useful stuff such as:

• Copy link
• Copy branch name

• Detect PR/issues that are stale (more than X days without interaction)
• Display it somewhere in the cards
• Make a staleness threshold configurable somewhere

When the plugin will have been fixed

It currently checks on the chrome://newtab url, but should also check on the about:newtab

If a token is provided, we could fetch the list of:

• All the repos the user has access to
• All the organizations the user has access to
• Maybe all the labels of these repos (might be too heavy, would need to be cached)
• Maybe all the users of these organizations (same as above)

This would allow adding suggestions to predicates such as:

• repo
• user
• involves
• commenter
• organization
• label
• etc

This library works pretty well, we could use it https://github.com/clauderic/react-sortable-hoc.

On hover of a filter, we should display a small icon (https://fontawesome.com/icons/grip-lines?style=solid) on the left. Dragging that icon would allow moving the filter up/down.

We should store the a version number in the storage too.

That way we'd be able to define migrations from say format v0.1.0 to format v0.2.0

We could add support for various providers if the code was less tied to GitHub.

This means there would be some refactoring to do so that we're not coupled to the GitHub API JSON structure.

In order to support that, we'd need to:

• Add a selector (defaulting to GitHub) in the Filter Modal, allowing to pick which provider we want to use
• Modify the settings modal to allow adding different tokens
• Determine which filter predicates are available on each provider
• Only allow adding filter predicates that match the selected provider
• Create a connector for each provider, allowing to filter resources
• Create the corresponding formatters, so that we don't have to handle various resource formats.

Providers that we could support:

• GitHub
• GitHub Enterprise (shouldn't be too hard)
• GitLab
• BitBucket
• Jira would be cool, but probably the most difficult. That said, we could only support a few simple predicates at first, and build on that later.

Is your feature request related to a problem? Please describe.
By default, I'm suspicious when it comes to permissions that an app or extensions requires. For me it's really important to understand why an extension needs those permissions. In your case the Read your browser history permission needs some clarity why this is needed.

Describe the solution you'd like
Try to remove them or narrow them down as much as possible. E.g. "https://github.com/*", instead of *://*.github.com/*

Describe alternatives you've considered
Explain why your extensions needs all those permissions.

Additional context

When there is a loader/error, there is no margin in the card.

This should be fixed.

That does:

• Prepend the list of all the commits (from the previous tag to HEAD) to a changelog.txt file
• Asks for the new version number (preferably via semver)

Also update the Releasing section of the README.md

Use it in the Chrome Store and add it to the README.md

Do not refresh on willMount

We need to wrap chrome.storage in the IStorage interface defined in: https://github.com/pinqy520/mobx-persist/blob/master/src/storage.ts

Something discrete, such as a green/red checkmark icon somewhere on the card.

So that the user sets his token

Is your feature request related to a problem? Please describe.
I use both github.com and Github Enterprise daily. Octolense only works with github.com.

Describe the solution you'd like
Octolense should also support Github Enterprise instances.

Describe alternatives you've considered
N/A

Additional context
N/A

For now, we cannot search issues/PR by their creation date. Ideally, I'd like to be able to do something like:

• Search for issues/PR that are older than: 1 day, 1 week, 1 month.

I think we could create something smart that would dynamically generate the date corresponding to the "range" we want and use it in a filter condition.

Reference: https://help.github.com/articles/searching-issues-and-pull-requests/#search-by-when-an-issue-or-pull-request-was-created-or-last-updated

If your filter fetched data previously and you try to refresh, only to get rate-limited, we currently just show the error and discard whatever data you fetched previously.

We should indicate that the request was rate-limited in a more subtle way, and still display the "old" data.

Maybe we could show a small toast instead of showing a global error in the page