We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Newly created tags and lists can be viewed by guests despite these settings:
$ sqlite3 storage/database.sqlite sqlite> select * from settings where key like '%private_default'; id|user_id|key|value 1|1|links_private_default|1 13|1|notes_private_default|1 14|1|lists_private_default|1 15|1|tags_private_default|1
It respects the setting, or assumes a private default which is less likely to lead to an issue for the user
Presumably this can be fixed here https://github.com/Kovah/LinkAce/blob/main/app/Repositories/TagRepository.php#L20 but I don't know this framework that well to know what function to call to check this setting, and was hoping this might be a 3-minute change for you
Verified on demo system running v1.12.0, at least for tags (I assume lists is the same, as I had this issue locally as well)
The text was updated successfully, but these errors were encountered:
Hi, thanks for taking your time to report this and even verifying it on the demo setup. Will have a look as soon as possible.
Sorry, something went wrong.
Make lists and tags private according to the user setting when create…
abcd914
…d from links (#644)
Thank you for resolving this! :)
Successfully merging a pull request may close this issue.
Bug Description
Newly created tags and lists can be viewed by guests despite these settings:
How to reproduce
Expected behavior
It respects the setting, or assumes a private default which is less likely to lead to an issue for the user
Presumably this can be fixed here https://github.com/Kovah/LinkAce/blob/main/app/Repositories/TagRepository.php#L20 but I don't know this framework that well to know what function to call to check this setting, and was hoping this might be a 3-minute change for you
Client details
Verified on demo system running v1.12.0, at least for tags (I assume lists is the same, as I had this issue locally as well)
The text was updated successfully, but these errors were encountered: