feat: Support application、setting、user log recorder

[shaohuzhang1]

What this PR does / why we need it?

Summary of your change

Please indicate you've done the following:

• Made sure tests are passing and test coverage is added if needed.
• Made sure commit message follow the rule of Conventional Commits specification.
• Considered the docs impact and opened a new docs issue or PR with docs changes if needed.

[f2c-ci-robot]

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.

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/test-infra repository.

[f2c-ci-robot]

[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.

Needs approval from an approver in each of these files:

• OWNERS

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

[shaohuzhang1]

The provided code contains several improvements and optimizations:

1. Imports: The imports have been corrected to reflect the actual file names in the directory structure (common.auth.authentication to common.auth.authenticate, etc.).

2. Class Methods: Class methods like login, register, etc., now include annotations for logging, which will help trace each API call effectively.

3. Logging Functionality:

   • A _get_details function captures HTTP request details such as path, body (with sensitive data masked), and query parameters. This helps in debugging by providing comprehensive context about requests.
   • Annotations are used with the @log decorator to specify the menu item and operation performed, allowing tracing through application logs.

4. Encryption Usage: An example of using the encryption helper method within log is shown when handling passwords. This is not recommended; instead, consider encrypting passwords at rest wherever possible.

5. Docstrings and Comments:

   • All classes, methods, and sections that should be tested have appropriate docstring comments explaining their purpose.

Example of How you can use Log Decorator

Here's how you might apply the @log decorator:

class Profile(APIView):

    @log(menu='System Parameters', operate='Get MaxKB Related Information')
    def get(self, request: Request) -> Response:
        return result.success(SystemSerializer.get_profile())

In this case, logging.info would be called during the execution of the Profile.get() method to log the action performed, along with additional contextual information from the _get_details function.

---

Please ensure you have properly set up logging configuration in Python (settings.py) or another relevant location where your logging calls reside. Also make sure to handle exceptions appropriately across different APIs to maintain robustness.

[shaohuzhang1]

Here is a concise review of the code:

Potential Issues:

1. Repeated tags Parameter: The same tag 'model' is repeated for multiple actions across different classes and methods. This could be redundant and might not be necessary.

2. Use of Swagger Annotations: While useful, some swagger annotations like operation_id can lead to repetitive documentation. Consider reusing them where appropriate.

3. Redundant Logging Decorators: Similar decorators such as @has_permissions, @log, etc., are used for each action without apparent need. You should ensure they align consistently if implemented differently elsewhere.

Optimizations and Recommendations:

1. Deduplicate Tags: If there's redundancy in tagging, consider merging similar functionalities into single tags or groups.

   @tag(['common_operations'])
   def common_operation(request):
       pass

2. Reuse Decorators:

   • Combine related permission checks (e.g., checking permissions using permission_required) within a decorator if possible.
   • Ensure that logging logic is centralized and reused wherever needed.

   Example of combining permissions checks:

   from functools import wraps
   
   def require_permission(permission_codes):
       def decorator(view_func):
           @wraps(view_func)
           def wrapper(*args, **kwargs):
               user = args[0].user
               all_permissions_granted = True
               for permission_code in permission_codes:
                   if not user.has_perm(permission_code):
                       return result.error(f"Permission `{permission_code}` denied")
               return view_func(*args, **kwargs)
           return wrapper
       return decorator
   
   @require_permission([PermissionConstants.MODEL_CREATE, PermissionConstants.MODEL_READ])
   def combined_action():
       # Action implementation
       pass

By addressing these points, you can improve both readability and maintainability of your Django views.

[shaohuzhang1]

There are no obvious irregularities or issues in the provided code snippet. However, there is one suggestion for optimization:

Code Optimization Suggestion

Ensure that the menu parameter passed to the @log decorator is consistently formatted. Both occurrences use 'Knowledge Base/Documentation/Paragraph', but it might be better to standardize them to reduce confusion. Here's how you can do it consistently across the decorators:

from django.utils.translation import gettext_lazy as _

class Paragraph(APIView):
    @has_permissions(
        lambda r, k: Permission(group=Group.DATASET, operate=Operate.USE,
                                dynamic_tag=k.get('dataset_id')))
    @log(menu=_('Knowledge Base/Documentation/Paragraph'), operate=_('Paragraph list'))
    def get(self, request: Request, dataset_id: str, document_id: str):
        ...

By updating all these lines to reflect this consistency:

class Paragraph(APIView):
    @has_permissions(
        lambda r, k: Permission(group=Group.DATASET, operate=Operate.USE,
                                dynamic_tag=k.get('dataset_id')))
    @log(menu='Knowledge Base/Documentation/Paragraph', operate=_('Paragraph list'))
    def get(self, request: Request, dataset_id: str, document_id: str):
        ...

# Repeat this format for other view classes similarly

This ensures that each log entry uses the same value throughout the application, improving readability and maintainability.