[Bug]: Unable to filter based on "assigned_object_id" - no alternative (Device ID?) field available

[kirk444]

NetBox Secrets plugin version

v1.10.1

NetBox version

v3.7.1

Steps to Reproduce

After updating from 3.6 / 1.9 I found that my scripts that rely on using the REST API to query and filter on "assigned_object_id" no longer function. It seems that "assigned_object_id" while part of the returned object, is not filterable anymore. In previous versions this worked, it's only after updating to 3.7.1 / 1.10.1 that it has stopped working.

In looking at the behavior of e.g. dcim.interfaces I see that they now use a "device_id" instead of "assigned_object_id" to define the device.

In looking at the docs, it seems that there is still a (filterable) "assigned_object_type_id" but I have no idea what this value is, as it's not part of the returned json objects.

Expected Behavior

I expect "https://netbox/api/plugins/secrets/secrets/?assigned_object_id=416" to return secret objects with "assigned_object_id=416".

Observed Behavior

An unfiltered list of all secret objects is returned.

[abhi1693]

This is not a bug. Secrets can be attached to any object and filtering just using the object id has no meaning because any object can have that I'd in django. You do need to specify the assigned object type as well as the plugin doesn't make assumptions that it has to be device model.

[kirk444]

Is the documentation

netbox-secrets/docs/rest-api/working-with-secrets.md

Line 184 in 7fe8d27

$ curl http://netbox/api/plugins/secrets/secrets/secrets/?assigned_object_type=dcim.device&assigned_object_id=103 \

wrong, or is the inability to do what is documented a bug?

[abhi1693]

If you have found a bug in the REST API, raise an issue by providing a comprehensive and detailed report. Begin with the creation of any necessary database objects, and explicitly detail every step taken. Ensure to include the exact sequence of operations performed, using the current stable release of NetBox. When documenting a bug in the REST API, it is crucial to reconstruct the raw HTTP request(s) involved. Do not use client libraries such as pynetbox for this. Your report should be clear and thorough, allowing others to replicate the bug accurately.

[kirk444]

I don't know if it's a bug, or if the documentation is simply no longer correct. The thing in the documentation used to work, but it doesn't work anymore. I'm not sure if that's expected or not.

[abhi1693]

There was an incorrect commit released in v1.9.1 that went out undetected due to incorrect tests. Try with v1.10.2 and let me know

[kirk444]

Updating to 1.10.2 has restored the original behavior. Thank you for your help, and for this project.