You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The intention of resolve_vfolder_rows() in the manager.api.vfolder module is to accept either an UUID or a human-friendly vfolder name. However, the primary caller, @with_vfolder_rows_resolved decorator did not try to convert the match-info value to UUID and has always passed it as str.
The result is that even the client places UUID in the vfolder REST APIs (/folders/{here}/...), it was always interpreted as vfolder names, not IDs.
We had a plan to add a new set of vfolder REST APIs as /folder/{id}/..., but I think we can just embrace the ID-based queries by fixing @with_vfolder_rows_resolved to work as originally intended.
The text was updated successfully, but these errors were encountered:
Summary
The intention of
resolve_vfolder_rows()
in themanager.api.vfolder
module is to accept either an UUID or a human-friendly vfolder name. However, the primary caller,@with_vfolder_rows_resolved
decorator did not try to convert the match-info value to UUID and has always passed it asstr
.The result is that even the client places UUID in the vfolder REST APIs (
/folders/{here}/...
), it was always interpreted as vfolder names, not IDs.We had a plan to add a new set of vfolder REST APIs as
/folder/{id}/...
, but I think we can just embrace the ID-based queries by fixing@with_vfolder_rows_resolved
to work as originally intended.The text was updated successfully, but these errors were encountered: