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
I would like an optional parameter on /add_tags/get_siblings_and_parents that would have the ideal_tag field show the ideal tag on the tag service under which it's keyed.
e.g. if a user has thigh-highs as their ideal tag for thighhighs in my files (which they set as higher precedence), but the PTR has thighhighs as the ideal tag, this option would make thighhighs be returned as the ideal_tag for the PTR's service key, but thigh-highs would still be the ideal_tag for the my files service key. Right now, per your docs (see screenshot below), it displays according to the user's preferences only.
My use case is that I want to have the program I'm writing, which cleans up pending tags for users before they push them, to respect remote tag services' preferences over user-specific idiosyncrasies. This is "greener" in the sense that most people don't override remote tag repo's siblings, so it means less processing for most clients. Plus, it just seems cleaner and more polite.
The text was updated successfully, but these errors were encountered:
I would like an optional parameter on
/add_tags/get_siblings_and_parents
that would have theideal_tag
field show the ideal tag on the tag service under which it's keyed.e.g. if a user has
thigh-highs
as their ideal tag forthighhighs
inmy files
(which they set as higher precedence), but the PTR hasthighhighs
as the ideal tag, this option would makethighhighs
be returned as theideal_tag
for the PTR's service key, butthigh-highs
would still be theideal_tag
for themy files
service key. Right now, per your docs (see screenshot below), it displays according to the user's preferences only.My use case is that I want to have the program I'm writing, which cleans up pending tags for users before they push them, to respect remote tag services' preferences over user-specific idiosyncrasies. This is "greener" in the sense that most people don't override remote tag repo's siblings, so it means less processing for most clients. Plus, it just seems cleaner and more polite.
The text was updated successfully, but these errors were encountered: