Issue/Help with "Move a security rule"

[pyxgun]

Documentation link

Move a security rule

Describe the problem

I am referring to pan.dev (link below), but it appears that this page does not contain the correct information to begin with. For example, the following incorrect information/behavior is observed

1. The request method is listed a POST, but the Python sample script shows GET.
2. QueryParameters requires a 'folder', but the Python sample script is not updated at all even if the 'folder' is specified in the field for creating a REQUEST. pan.dev Move a security rule (https://pan.dev/access/api/prisma-access-config/post-sse-config-v-1-security-rules-id-move/)

Also, the API endpoint is described as requiring the ID of the security rule to be moved to be added to the URL, but when a request is actually sent to the endpoint that specifies the ID of the security rule, it results in a "404 NotFound". The security rule ID used to confirm the above behavior are the ID of the security rules that actually exist, and the IDs are never incorrect.

The following is the API response result when request to this api endpoint == API Responses ======== Response: { "statusCode": 404, "error": "Not Found", "message": "Not Found", "errorCode": "Not Found", "errorMessage": "Not Found", "httpStatusCode": 404, "ok": false, "trackingId": "6fe24d0b-5c5c-48c2-aee1-20b966ad48b0" }

Suggested fix

[sserrata]

Hi @pyxgun, thanks for reporting the issues:

The request method is listed a POST, but the Python sample script shows GET.

Will investigate this further as it could be a bug in our OpenAPI docs plugin.

QueryParameters requires a 'folder', but the Python sample script is not updated at all even if the 'folder' is specified in the field for creating a REQUEST. pan.dev Move a security rule (https://pan.dev/access/api/prisma-access-config/post-sse-config-v-1-security-rules-id-move/)

I believe this issue has already been resolved - can you help confirm?

As for the "rule id" issue - if you are still encountering problems with it I recommend opening a TAC issue.

[sserrata]

The request method is listed a POST, but the Python sample script shows GET.

After some investigation, this issue appears to stem from how the endpoint path is currently structured and processed by the postman-collection library we use under the hood:

/sse/config/v1/security-rules/{id}:move

I believe this violates the OpenAPI spec because {id}:move is not a valid path parameter placeholder—OpenAPI only supports parameters as whole path segments or as the entire segment, not as partial values.

Proposed path:

/sse/config/v1/security-rules/{id}/move

@sarette FYI

[Gtt1229]

The SCM docs are the same way. The response states the folder is undefined, and doesn't process even if one is given.

Example:

I've redacted my UUID's, Bearer, and Request ID.

Request:

curl -X POST ^
 https://api.sase.paloaltonetworks.com/sse/config/v1/security-rules/UUID1:move ^
  -H "Authorization: Bearer REDACTED" ^
  -H "Content-Type: application/json" ^
  -d "@move_payload.json"

Payload:

{
  "snippet": "My-Snippet",
  "rulebase": "pre",
  "destination": "before",
  "destination_rule": "UUID2",
  "folder": "My-Folder"  <----------  Only added for testing purposed. Response always says folder is undefined
}

Response:

{"_errors":[{"code":"API_I00013","message":"Your configuration is not valid. Please review the error message for more details.","details":{"errorType":"Operation Impossible","message":"Folder undefined doesn't exist. Please create it before running the command"}}],"_request_id":"REQUEST ID"}