Skip to content

Permissions checking implementation#71

Merged
palimad merged 10 commits intodevelopfrom
feature/permissions-check
Mar 13, 2026
Merged

Permissions checking implementation#71
palimad merged 10 commits intodevelopfrom
feature/permissions-check

Conversation

@palimad
Copy link
Copy Markdown
Collaborator

@palimad palimad commented Feb 19, 2026

@palimad palimad requested a review from aarongoin February 19, 2026 09:18
};

// Returned by /auth in newer API versions
permissions?: string[] | Record<string, boolean>;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Does this type actually come back as an array or strings? I don't think it should.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Good catch, fixed

Comment on lines +28 to +30
const enabled = Object.keys(source as Record<string, unknown>).filter(
(k) => Boolean((source as any)[k]),
);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

If the type gets updated in the types/auth.ts file then you shouldn't need to cast here. And you could probably then just write this like:

Suggested change
const enabled = Object.keys(source as Record<string, unknown>).filter(
(k) => Boolean((source as any)[k]),
);
const enabled = Object.keys(source).filter((k) => !!source[k]);

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

using !!source[k] could be unsafe because any truthy non-boolean value (e.g. "none" or 1) would be incorrectly treated as enabled, right? what about const enabled = Object.keys(source).filter((k) => source[k] === true), so only explicitly enabled permissions are included

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Good call! 👍

Copy link
Copy Markdown
Member

@aarongoin aarongoin left a comment

Choose a reason for hiding this comment

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

Nice. Just a couple little nits and improvements.

@palimad palimad requested a review from aarongoin February 20, 2026 14:30
@palimad palimad closed this Mar 10, 2026
@palimad palimad reopened this Mar 10, 2026
Copy link
Copy Markdown
Member

@aarongoin aarongoin left a comment

Choose a reason for hiding this comment

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

Okay this looks good. In order to deploy it though we're going to need to bump the package version (probably just a patch level bump since we're still pre-version 1) in the package.json and then npm install to update the lock file. Then once those changes are in the PR we can merge and the CI/CD workflow will handle actually bundling and deploying the new version.

Copy link
Copy Markdown
Member

@aarongoin aarongoin left a comment

Choose a reason for hiding this comment

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

Nice!

@palimad palimad merged commit cfb8be5 into develop Mar 13, 2026
@palimad palimad deleted the feature/permissions-check branch March 13, 2026 11:10
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.

2 participants