Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistencies when updating a Collection's visibility #864

Open
algernon opened this issue Feb 2, 2024 · 0 comments
Open

Inconsistencies when updating a Collection's visibility #864

algernon opened this issue Feb 2, 2024 · 0 comments
Labels

Comments

@algernon
Copy link

algernon commented Feb 2, 2024

The docs say that if I want to update a Collection's visibility - to, say, public - I need to send {"visibility": 1} to the /api/collections/{alias} endpoint in a POST request.

However, that doesn't work.

Steps to reproduce

❯ curl -s "http://localhost:9080/api/collections/algernon" \
       -H "content-type: application/json" \
       -H "Authorization: Token ${TOKEN}" \
       -X POST -d '{"visibility":1}'
{"code":400,"error_msg":"Supply some properties to update."}

Workaround

Digging around in the source, I discovered that I need to use the public property for this. That works.

Expected behaviour

However, when retrieving a collection's info, public is serialized as a bool, so I have no way of knowing whether the blog is unlisted, private, or password protected. The only state I can be sure of is if public: true, then the collection is public. If it is false, it can be either of the three.

It would be nice if the API matched the documentation, and that if visibility would be included in the collection properties in response to a GET request to /api/collections/{alias}. Keeping public there too, for compatibility is fine too. I just wish I could both retrieve the full range of visibility settings, and set them consistently: with the same key, and same type as they are retrieved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants