vibinex / chrome-extension Goto Github PK

This happened during one of the installations. The user used Chrome with their personal profile on a work computer but did not choose to sync the data between accounts.
This completely broke their experience of using the application. Instead, the 'onInstalled' event will be triggered on every browser they want to use our extension. So we can use the local storage instead of the sync storage.

We want to guide the user throughout the whole journey of setting up Vibinex on any given repository without taking them out of the setup experience (without the need for the instructions page created in #40 of the team-monitor-website).

Currently, the colours defined for highlighting are not sensitive to the theme used by the user.
For example, on GitHub, the colour used is great when the user is in a dark theme, but not so great if the user is using a light theme. Similarly, for GitLab, the light theme user sees beautiful highlights, but dark theme users do not.

• We do not want this to be dependent on the GitHub account preferences since people might be using browser extensions for turning their website into a light theme or dark theme.

Currently, we only add a border on the left side of the lines and the color of the highlight is not always very clearly visible.
It would be a lot better if we could add a ::before element there which is designed to attract the attention of the user without disrupting their experience of reviewing the code.

          @avikalpg A more robust method would involve using a URL parsing library to abstract away the direct manipulation of URL strings. Libraries like `URL` built into modern JavaScript or third-party libraries like `urijs` can parse URLs and provide an API to access different parts of the URL.

For example, using the URL interface in JavaScript:

const url = new URL(tabUrl);
const pathname = url.pathname;
const searchParams = new URLSearchParams(url.search);

// Now you can check pathname segments and search parameters without directly splitting strings
if (pathname.startsWith('/orgs/') && searchParams.get('tab') === 'repositories') {
  // It's an organization's repositories page
}

This approach is less likely to break if GitHub changes its URL scheme because it doesn't rely on the URL having a specific number of segments or the order of query parameters. It also makes the code easier to read and understand.

Remember to check browser compatibility for the URL and URLSearchParams APIs if the script is intended to run in a wide range of browsers, or use a polyfill or third-party library if necessary.

Originally posted by @coderabbitai[bot] in #81 (comment)

DOD

• Implement API
• backGround color changes
• encrypt and match

Context

GitHub has recently launched a new "repositories" page for organizations, which is currently in beta.

Action

We will add support for showing the "activated" repositories for the new UI as well (without stopping the support for the old UI).

Optional feature

If we can add a filter for "Vibinex-enabled" repositories, that would be very delightful.

DOD

• Figure out events
• Making UI
• User Authentication

This commit was the fix for the "unified" view: 0a85af8

Issue

Sometimes, Bitbucket diff and git diff do not exactly align.
Currently, the extension only highlights a line if the line is a part of a diff according to Bitbucket and it is a deletion (has the "-" market).

Expected behaviour

The line should still be highlighted even if it is not a part of the diff.

Ideally, we would want total control over what does and does not get highlighted and in which scenarios.
For example, when a user is logged out, the logged-in user changes or when their free quote expires, we want to make sure that unnecessary or incorrect things do not get highlighted.

Currently, all the colours in the contentScript.js are hard-coded; which is obviously not a good practice, if we ever decide to change the color coding for any of the functions of the chrome extension.

When I try to log out and log in with another user, the extension is unable to clear the previous id. Right now, this is just a problem for testing with different ids, if this issue gets user attention we may bump it up

DOD

• ui for loading
• implemented for all api loading

Currently, the UX for manually triggering Vibinex on a pull request is sub-optimal. The user has to copy the link of the pull request (which also has to be the root link of the pull request), paste it into the popup window (right next to the "Logout" button) and then click "Trigger".

A much better UX would be to have a button on the pull request page that can just be clicked to trigger Vibinex.

Optional: Show different states of the button:

• Default: The button is ready to be clicked with the Vibinex refresh symbol, and the tooltip text "Process this PR on Vibinex".
• Highlighted: If the pull request is not processed even once before, change the styling of the button to highlight it more.
• On Click: As soon as the user clicks the button, it should become disabled and the text should change to "Triggering..."
• Processing: Once the trigger is successful, the button should still be disabled, but the color should change to a shade of green and the text should change to "Processing...".
• Done: Once the hunks table row for the pull request has a last_modified_at timestamp greater than the time of the click, we can change the text of the button to "Done!". Then we can either refresh the page or just trigger the UI update function again. The button should change back to the "Default" state once the UI is updated.

DOD

• adding ui button
• onclick redirect to website or page where they can see the steps to track that repo

There should be a button on the page with the list of pull requests to process all the open pull requests at once.
The UI of the button can be similar to #103 plus the progress bar (if relevant) to show how many of the open pull requests have been processed.

If the "PR COMMENT" feature flag for a repository is turned off, then the Chrome extension should show the list of relevant reviewers with their relative relevance.

Purpose: Individual users should also know the relevant reviewers for their own pull requests so they can directly ping them to review their pull requests.

Design:
Create a section in the GitHub/Bitbucket UI right below the title of the pull request that looks like this:

Optionally, we can also add check marks next to the reviewers who have reviewed the pull request (even if GitHub/Bitbucket says that their review has been dismissed, we can maintain the right approval information on this element.)

For URLs of the type: https://github.com/<username>?tab=repositories, the Vibinex logo that indicates which repositories are Vibinex-enabled, does not appear.

Bitbucket is introducing a new UI, with "file changes" as a separate tab from the "overview" tab, similar to GitHub.
We are currently triggering highlighting only on scroll - which was good earlier, but now, since file-changes is a separate tab, it doesn't always have the option to scroll at all.

They have also added the file list on the left-hand side - so file highlighting should be done like it is done on GitHub.

-every time backend api throws an internal error or doesn't return JSON, chrome-extension shows not a JSON error.
-Not very urgent to be picked up but yeah this needs to be fixed.