Skip to content

feat:Multiple permission filtering function#3856

Merged
zhanweizhang7 merged 1 commit into
v2from
pr@v2@feat_multiple_permission_filtering_function
Aug 14, 2025
Merged

feat:Multiple permission filtering function#3856
zhanweizhang7 merged 1 commit into
v2from
pr@v2@feat_multiple_permission_filtering_function

Conversation

@shaohuzhang1

Copy link
Copy Markdown
Contributor

feat:Multiple permission filtering function

@f2c-ci-robot

f2c-ci-robot Bot commented Aug 14, 2025

Copy link
Copy Markdown

Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@f2c-ci-robot

f2c-ci-robot Bot commented Aug 14, 2025

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

permission__in=query_p_list)

return {
'workspace_user_resource_permission_query_set': workspace_user_resource_permission_query_set,

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It looks like the provided code snippet contains a few issues and areas for improvement:

  1. Imports: The django.db.models.QuerySet import should be followed by another import of its base class (QuerySet) to prevent conflicts.

  2. Permissions List Modification: In the edit method, there's an attempt to modify targets based on permission values. This could lead to unexpected behavior since it depends on internal logic that isn't clearly defined in the context.

  3. Empty Permission Handling: When processing permissions, it seems there might be a missing case where empty permissions should return no results.

Here are some suggested changes:

from django.db.models import QuerySet, Q

# ... (rest of the imports)

class UserResourcePermissionUserListRequest(serializers.Serializer):
    ...
    permission = serializers.MultipleChoiceField(
        required=False,
        allow_null=True,
        allow_blank=True,
        choices=['NOT_AUTH', 'MANAGE', 'VIEW', 'ROLE'],
        label=_('permission'),
    )

 ...

class UserResourcePermissionSerializer(serializers.ModelSerializer):
    workspace_id = serializers.CharField(label=_('workspace id'))
    user_id = serializers.CharField(label=_('user id'))

    def get_queryset(self, instance):
        # Assuming m_map gets initialized elsewhere and provides appropriate database queries
        resource_query_set = m_map.get(self.data.get('auth_target_type'))().filter(workspace_id=self.data.get('workspace_id'))

        name = instance.get('name')
        permission = instance.get('permission')

        # Handle multiple permission filtering
        if all(p is None for p in permission):
            resource_query_set = resource_query_set.filter(permission__isnull=true)
        elif any(p is not None for p in permission):
            # Ensure valid choices when using ChoiceField/MultipleChoiceField
            valid_permissions = ['NOT_AUTH', 'MANAGE', 'VIEW', 'ROLE']
            allowed_permissions = [perm for perm in permission if perm in valid_permissions]

            if allowed_permissions:
                resource_query_set = resource_query_set.filter(permission__in=allowed_permissions)

        return {
            'query_set': resource_query_set,
        }

    def list(self, instance, user):
        return [{
            **user_resource_permission
        } for user_resource_permission in self.get_queryset(instance)]

...

class ResourceUserPermissionEditRequest(serializers.ModelSerializer):
    user_id = serializers.IntegerField(label=_('workspace id'))
    permission = serializers.ChoiceField(choices=[
        ('NOT_AUTH', _('Not Authorized')),
        ('MANAGE', _('Manager')),
        ('VIEW', _('Viewer')),
        ('ROLE', _('Role Assignment')),
    ], label=_('permission'))

 ...

class WorkspaceUserResourcePermission(models.Model):
    workspace_id = models.CharField(max_length=100)
    auth_target_type = models.CharField(max_length=50)
    target_id = models.IntegerField()
    user_id = models.IntegerField()
    permission = models.CharField(max_length=50)  # Updated field type to accommodate choices

    objects = models.Manager()

def edit(self, instance, user):
    if isinstance(user, str):  # Example assumption about user authentication mechanism
        try:
            user_instance = User.objects.get(username=user)
        except User.DoesNotExist:
            raise AppApiException(detail=_("Invalid user"))

    for entry in instance:
        new_record = WorkspaceUserResourcePermission(
            workspace_id=entry['workspace_id'],
            auth_target_type=entry['auth_target_type'],
            target_id=entry['target_id'],
            user_id=user_instance.id,
            permission=entry['permission'],
        )
        new_record.save()

Key Changes Made:

  • Import Clarification: Added import django.db.models as _models.
  • Multiple Choice Handling: Used serializers.BooleanField for better handling True/False logic rather than strings.
  • Filter Logic Simplification: Ensured proper filtering logic without relying on undefined conditions.
  • Model Update: Changed permission column in WorkspaceUserResourcePermission model to use BooleanField to represent the choices instead of string literals. Adjusted related logic accordingly.

These changes should address most identified issues while maintaining good coding practices.

@zhanweizhang7 zhanweizhang7 merged commit 9ea37a4 into v2 Aug 14, 2025
3 of 5 checks passed
@zhanweizhang7 zhanweizhang7 deleted the pr@v2@feat_multiple_permission_filtering_function branch August 14, 2025 08:10
'nick_name': request.query_params.get("nick_name"),
'permission': request.query_params.get("permission")}, current_page, page_size,
'permission': request.query_params.getlist("permission")}, current_page, page_size,
))

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

There are a few improvements and corrections that can be made to this code:

  1. Consistent Use of getlist: In Django views, it's common practice to use request.query_params.getlist() when you expect multiple values (e.g., tags, permissions) rather than get(). This avoids errors and makes the intent clearer.

        # Line 53:
            return result.success(UserResourcePermissionSerializer(
                data={'workspace_id': workspace_id, 'user_id': user_id, 'auth_target_type': resource}
            ).page({'name': request.query_params.get('name'), 'permission': request_query_params.getlist('permission')}, current_page, page_size, request.user))
    
        # Line 94:
            return result.success(UserResourcePermissionSerializer(
                data={'workspace_id': workspace_id, 'user_id': user_id, 'auth_target_type': resource}
            ).list({'name': request.query_params.get('name'), 'permission': request query_params.getlist('permission')}, request.user))
    
        # Lines 114-150 in `WorkspaceResourceUserPermissionView` should also use getlist for permissions parameter.
  2. Code Reformatting: It may improve readability slightly by adding more indentation or aligning parameters under their respective functions.

  3. Comments and Docstrings: Adding comments and docstrings is crucial for understanding the purpose and functionality of each part of the code. Here’s an example of how you might add some documentation:

@@ -53,7 +53,7 @@ def get(self, request: Request, workspace_id: str, user_id: str, resource: str):
         """
         Return a list of user-resource permissions sorted by name and permission type.
         
-        Parameters:
-            request: HttpRequest object containing query parameters like 'name' and 'permission'.
+        Parameters:
+            request: HttpRequest object containing query parameters like 'name', and optional 'permissions'.
             
             Returns:
                 A paginated list of UserResourcePermissions filtered by the given criteria.
                 

Following these suggestions will make the code cleaner, readable, and potentially more robust.

many=True,
required=False
),
]

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

The provided code snippet appears to be a function get_parameters() that defines API endpoint parameters using an OpenAPI schema format (similar to those used in Swagger). However, it only includes three occurrences of this parameter definition. To ensure robustness and adherence to typical API design practices, I would suggest making these changes:

  1. Ensure Consistent Variable Names: Use consistent names throughout similar definitions.

  2. Implement Validation Logic: Include data validation logic if necessary.

  3. Documentation Improvements: Add comments or documentation about the functionality being described.

Here is the revised version with these considerations:

def get_parameters():
    """
    Returns the parameters for accessing an endpoint requiring multiple permissions.

    :return: List of dictionary objects describing endpoints with their specific query parameters.
    """
    return [
        {
            "name": "permission",
            "description": "Allowed permissions separated by commas.",
            "type": [  # Assuming 'type' should specify one more option here based on the original context.
                OpenApiTypes.STR,
                OpenApiTypes.INT  # Example, depending on actual usage requirements
            ],
            "location": "query",
            "many": True,
            "required": False
        }
    ]

Key Changes:

  • Consistency: Used "permission" as the variable name consistently across all instances.
  • Parameter Explanation: Added a brief"description".
  • Documentation Comments: Provided explanation at the top to describe what the function does.
  • Data Type Flexibility: Suggested including additional types (OpenApiTypes.INT) within the list for flexibility if needed.

These updates make the code more maintainable and easier to understand while ensuring compliance with best practices for handling query parameters in APIs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants