![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
Filter entries by tags AND security level
Title:
Filter entries by tags AND security level
Area:
tags, access filters
Summary:
It would be great to have a straightforward way to filter someone's current entries by both tags and security level, at the same time.
Description:
Currently, you can filter someone's entry by tag, e.g. user.dreamwidth.org/tag/banana would display all User's entries tagged 'banana' .
You can also filter it by security level, e.g. user.dreamwidth.org/security/public . This would display all User's current public entries.
But there is no obvious way (AFAIK - please correct me if I'm wrong) to do both at once, e.g. if you could use user.dreamwidth.org/security/public/tag/banana to display all User's current public entries tagged 'banana'. And some people have hundreds of entries per tag, so checking all by hand might not be practical.
This would be useful for if you need to quickly check if something a person told you is public knowledge before running your mouth about it in your own journal ("Looks like User's banana posts are all access-locked. I'd better ask them first before posting publicly about meeting them at the banana festival!") or, potentially, for checking your own security levels ("I try to make sure my posts on lutefisk are in an opt-in access group for my fellow lutefisk enthusiasts, but I think I might have forgotten to filter a few. Let me just check user.dreamwidth.org/security/access/tag/lutefisk and the same for security/public/tag/lutefisk to make sure of that.")
Potential drawbacks:
- it might hit the database too hard? IDK.
- people have custom security groups with / in the title, and people have tags with / in the title, and this would make it more difficult to form a URL, not matter whether it's /security/level/tag/tagname, or /tag/tagname/security/level.
This suggestion:
Should be implemented as-is.
16 (40.0%)
Should be implemented with changes. (please comment)
6 (15.0%)
Shouldn't be implemented.
0 (0.0%)
(I have no opinion)
17 (42.5%)
(Other: please comment)
1 (2.5%)
no subject
example: tag/picspam?security=public
no subject
no subject
I like azz's idea below too it is more user-friendly than having to type it in
you can already search for two tags at a time also but I'm on my phone and don't remember the syntax for that ottomh, I can look it up l8r if u want. I think it is limited to only 2 right now tho. but still handy.
eta: nm found it in faq it's tag/tag1name,tag2name?mode=MODE
and where I wrote MODE put either "or" or "and" (and gives only posts with both tags)
iirc can stack with security level filtering too I think
/tag/tagA,tagB?mode=and&security=private
no subject
Display all the tags in some sort of sensible, sortable fashion
Take into account corner cases like me (who has a bajillionty tags, imported from LJ -- I swear I'm trimming them down, but it's slow!)
Display all the security levels in a way that takes into account who you are and what you can see (for my own account, I'd see public, access, private, and all the filters; for an account where I'm in the circle, I'd see public and access, and access would silently include filters I'm on; for a community where I'm admin: public, access, admins; community member: public, access; non-circled: public)
Let you select or type in the elements you want to include, in the way you want to include them.
Allow full Boolean logic.
Spit out the query when you hit go.
I'm actually slightly against having the output be URL-based simply because a full Boolean query with an arbitrary number of arguments could possibly exceed the allowable URL length.
Apply appropriate account-based restrictions in order to protect performance. (Because I expect this might be one hungry search.)
no subject
Being able to cross-reference multiple tags would be... well, I'll try to keep this comment G-rated, but there are a whole lot of otherwise pleasurable activities I'd be less excited about getting to do.
no subject
no subject
Whatever the UI, I suspect this is a fairly major RFE, and I don't know what the database implications might be, but it'd definitely be nice to have.
no subject
no subject
no subject