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

Improve performance of the PermissionsService #5001

Merged
merged 3 commits into from
Nov 18, 2017
Merged

Conversation

scottbommarito
Copy link
Contributor

Previously, the PermissionsService would
1 - Get a list of all permissions that the user has
2 - Check that list with the permissions required by the action

This PR now allows the PermissionsService to short-circuit and stop checking permissions when it finds that the user has a permission that's required.

E.g. if I am an owner of the package and this action is allowed if I have owner permissions, I don't need to check if I am a member of any organizations that own the package.

}

if (isUserAdmin)
if (isUserAdmin &&
Copy link
Contributor

Choose a reason for hiding this comment

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

you can get a minor perf improvement if you switch between the admin check and the owner check.
Admin performing an action is not as common as user performing an action, so you can avoid the check in most cases.

Copy link
Contributor

@skofman1 skofman1 left a comment

Choose a reason for hiding this comment

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

:shipit:

return PermissionLevelsMatch(PermissionLevel.Anonymous, actionPermissionLevel);
}

private static bool PermissionLevelsMatch(PermissionLevel first, PermissionLevel second)
Copy link
Member

Choose a reason for hiding this comment

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

nit: This is more like PermissionLevelsIntersect right? Match to me sounds like equality.

@@ -103,10 +103,17 @@ private void CreateOrganizationOwnerAndAddUserAsMember(List<User> owners, User u

private void AssertPermissionLevels(IEnumerable<User> owners, User user, PermissionLevel expectedLevel)
{
Assert.Equal(expectedLevel, PermissionsService.GetPermissionLevel(owners, user));
for (int i = 0; i < Enum.GetValues(typeof(PermissionLevel)).Cast<int>().Max() * 2; i++)
Copy link
Member

Choose a reason for hiding this comment

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

What's this math for?

Copy link
Member

Choose a reason for hiding this comment

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

Looks like the max value for permissions level (i.e., IsOwner | IsSiteAdmin | IsOrganizationAdmin | IsOrganizationCollaborator), and is also used for test data above. Maybe create a readonly class variable for it?

Copy link
Member

Choose a reason for hiding this comment

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

nit: My only concern with ReturnsExpectedPermissionLevels is whether it would be obvious from a test failure what the issue is. In the case of failure, will debugging be necessary to determine the issue? Looks comprehensive though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yup, it's for iterating through all possible combinations of permissions

Copy link
Contributor Author

Choose a reason for hiding this comment

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

added readonly variable

@joelverhagen
Copy link
Member

Was there a perceived performance impact? How was this measured?

@scottbommarito
Copy link
Contributor Author

@joelverhagen performance was never measured, but it seems very reasonable that in the majority of cases, skipping the organizations check when we know the user is an owner should be more performant.

@scottbommarito scottbommarito merged commit cd4cc9f into dev Nov 18, 2017
@scottbommarito scottbommarito deleted the sb-betterperm branch November 18, 2017 01:12
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.

5 participants