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

Add shareable repo-specific URL #255

Merged
merged 11 commits into from
Feb 26, 2024

Conversation

nknguyenhc
Copy link
Contributor

@nknguyenhc nknguyenhc commented Feb 14, 2024

Summary:

Fixes #251

Type of change:

  • ✨ New Feature/ Enhancement

Changes Made:

  • For every change in repo, the URL query param changes. For example, if you are switching from another repo to this repo, the URL changes to /issuesViewer?repo=CATcher-org%2FWATcher.
  • When user keys a URL with pathname (i.e. needs to login before proceeding), the pathname + query params are stored in session storage.
  • In authentication page, if there is a URL to be redirected to (in session storage), it automates the login process.
  • Appropriate error handling is added so that wrong URL input are handled properly.

I did try to limit the changes in this PR to as small as possible, but I could not find a good way to split this task to smaller task, such that smaller tasks can be independently tested.

Some of the sample URLs I have tried:

  • /issuesViewer: invalid URL, because now issue viewer URL must have query param
  • /issuesViewer?repo=CATcher-org%2FWATcherrr: invalid URL, because repo does not exist
  • /issuesViewer?repo=CATcher-org%2FWATcher%2Ftest: invalid URL, because repo name is of wrong format
  • /issuesViewer?repo=CATcher-org%2FWATcher: valid URL
  • Invalid URL, followed by pathname /: login should proceed as per normal
  • Valid URL, followed by pathname /: login should proceed as per normal

Future enhancements:

Here are some possible future enhancements of this feature:

  • Store filters, including labels, milestones, etc, in query params to allow filters to be shareable through links
  • Redirect to activity dashboard if URL is indicated as such, when the activity dashboard is available

Screenshots:

NIL

Proposed Commit Message:

Add shareable repo-specific URL

Previously, URLs are fixed upon repo change, hence URLs are not shareable.

Let's make the current repo visible in the URL, so that it shareable.

Furthermore, login is automated when there is such next route to be redirected to.

Checklist:

  • I have tested my changes thoroughly.
  • I have created tests for any new code files created in this PR or provided a link to a issue/PR that addresses this.
  • I have added or modified code comments to improve code readability where necessary.
  • I have updated the project's documentation as necessary.

@luminousleek
Copy link
Contributor

Thanks for this PR! A quick test does show that the username doesn't display in the top right corner after logging in though, see the screenshot below.

Screenshot 2024-02-17 at 9 01 14 PM

@@ -33,6 +33,9 @@ export enum AuthState {
* updating the application state with regards to authentication.
*/
export class AuthService {
private static readonly DEFAULT_HAS_PRIVATE_PERMISSION = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this should be the default. See #214.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have changed this to false. This means that auto-redirect does not work if the user paste the link to view a private repo. There needs extra work to handle viewing private repos, I will create a separate issue.

@nknguyenhc
Copy link
Contributor Author

I have fixed the bug! Let me know if there are any other issues.

Copy link
Contributor

@luminousleek luminousleek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks almost good to merge! Just a really small nit to fix.

@@ -33,6 +33,9 @@ export enum AuthState {
* updating the application state with regards to authentication.
*/
export class AuthService {
private static readonly DEFAULT_HAS_PRIVATE_PERMISSION = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small nit - might want to change the constant name here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the constant name to DEFAULT_HAS_PERMISSION_TO_PRIVATE_REPOS

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm what i meant is that the constant name sort of implies that the constant value is true, but it's actually false. maybe something like DEFAULT_DOES_NOT_HAVE_PRIVATE_REPO_PERMISSION might work

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid the name being interpreted as a boolean question, I have renamed it to NO_PERMISSION_TO_PRIVATE_REPOS

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion I get where @luminousleek is coming from. Default should indicate its default state in the name following the word DEFAULT.
However, this is confusing since developers might mistake it as representing a boolean variable which means "No private repo access", when really it is used as "has private repo access".
I think a better name would be just HAS_PERMISSION_TO_PRIVATE_REPOS. why the DEFAULT at all when it is implied already by static readonly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without the word DEFAULT, it might be mistaken that the auth service will never have access to private repos, while in fact, this is only the default settings when the app skips manual login. The app would still have access to private repos if the user chooses to (with manual login).

Phrasing the name as a boolean question (i.e. HAS_PERMISSION_TO_PRIVATE_REPOS) is more applicable when it is a boolean variable that can take up both values (i.e. true and false) in different scenarios, but in this case, it can only be false. Some might infer the variable name as the auth service always have access to private repos.

I would still be more inclined to use NO_PERMISSION_TO_PRIVATE_REPOS, because it really means "no private repo access", and is meant to be used only when the app has no private repo access. Unless there is a good way to incorporate the word DEFAULT into the constant name when phrasing it as a boolean question.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Late to the discussion, I would prefer DEFAULT_NO_PERMISSION_TO_PRIVATE_REPOS or similar. Default keyword is important to show that it is by default

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to DEFAULT_NO_PERMISSION_TO_PRIVATE_REPOS!

@Arif-Khalid
Copy link
Contributor

Tested all functionality and working as intended. Aside from naming nitpick by @luminousleek, LGTM!

Copy link
Collaborator

@gycgabriel gycgabriel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Late to the discussion, I would prefer DEFAULT_NO_PERMISSION_TO_PRIVATE_REPOS or similar. Default keyword is important to show that it is by default

Copy link
Contributor

@luminousleek luminousleek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, this will be a useful feature! Thanks for your hard work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add shareable repo-specific URL
4 participants