fix: Workspace manager folder

[shaohuzhang1]

fix: Workspace manager folder

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

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]

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

• OWNERS

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

[shaohuzhang1]

There seems to be an error in the code snippet you provided. In the @has_permissions decorators:

1. The operation being checked is mixed between Operation.UPDATE and OPERATE.CREATE. Typically, one should use either UPDATE or CREATE, not both.

lambda r, kwargs: Permission(group=Group(f"{kwargs.get('source')}_FOLDER"), operate=Operate.CREATE,
                              resource_ path=f"/WORKSPACE/{kwargs.get('workspace_id')}/{kwargs.get('source')}/{r.data.get('parent_id')}"),

lambda r, kwargs: Permission(group=Group(kwargs.get('source')), operate=Operate.EDIT,
                            resource_path=f"/WORKSPACE/{kwargs.get('workspace_id')}:ROLE/WORKSPACE_MANAGE")

This will result in an inconsistency and might lead to unexpected behavior in your application.

2. Ensure that all parameters used ('source', 'workspace_id', 'parent_id') are correctly set before accessing them with .get(). Using these values directly without setting it first could throw a KeyError if those keys do not exist in the request data.

3. Consider whether the logic for checking permissions should be more specific or general based on additional fields or context within your application.

4. If you intend to perform different operations depending on certain conditions, ensure that each decorator uses the appropriate constants from your library (e.g., Permission.Operation.UPDATE vs. Permission.Operate.CREATE).

[shaohuzhang1]

The code looks mostly correct but can be simplified for better readability and maintainability. Here's an optimized version:

function openCreateDialog(data?: any) {
  if (!data || !this.isToolTypeSupported(data.tool_type)) {
    return;
  }

  this.selectNodeFromData(data);
  this.openCreateMcpDialog(data);

  this.handlePostOpenCreateDialog();
}

handlePostOpenCreateDialog() {
  // Add any additional cleanup or logging here
}

Optimization Suggestions:

1. Early Return: The early return after checking !data || !this.isToolTypeSupported(data.tool_type) ensures that unnecessary checks are skipped when the input data is insufficient.

2. Code Clarity: Breaking complex logic into separate methods (selectNodeFromData, openCreateMcpDialog) improves code modularity and clarity.

3. Method Name Clarification: The method name could be made more descriptive, such as prepareAndOpenDialog.

4. Add Additional Checks: If necessary, you may want to add more robust error handling or validation of data.