Changes to TagDetails
Hi Styles people :-)
I've just finished working on Bug 1723 and, pending reviews etc, it will probably appear in a code push soon. It makes a couple of changes to how things in the TagDetails class behave, so I thought I should do a post here and warn you.
Firstly: The use_count variable currently gives the total number of posts on which a tag is used. This will change to the number of posts visible to the current user on which the tag is used. This fixes a privacy issue, whereby somebody without access could see how often the journal owner wrote about that tag in locked posts. Note that for performance reasons, the new value will sometimes be an approximation. It may be accurate or it may underestimate. It should never overestimate.
Secondly: There is a data structure called security_counts, which is not used by any of the DW official styles, and which I suspect nobody actually used because half of it didn't work. Here's how it will work in future:
Note that security_counts{"group"}, which used to exist but frequently gave the wrong value, is deprecated. There is no way to provide this info for access filter groups without thrashing the database.
Also, security_counts{"friends"} is deprecated because it never worked anyway! It has been replaced by security_counts{"protected"}.
I hope that all makes sense; please ask questions if you have them.
-Simon.
EDIT: I realised that we can do security_counts{"group"} properly for journal owners, because we can assume that they can see all groups. There's still no way to work it out for other users without database-thrashing. Unlike before, for those who can see it it will now give the right number ;-)
I've just finished working on Bug 1723 and, pending reviews etc, it will probably appear in a code push soon. It makes a couple of changes to how things in the TagDetails class behave, so I thought I should do a post here and warn you.
Firstly: The use_count variable currently gives the total number of posts on which a tag is used. This will change to the number of posts visible to the current user on which the tag is used. This fixes a privacy issue, whereby somebody without access could see how often the journal owner wrote about that tag in locked posts. Note that for performance reasons, the new value will sometimes be an approximation. It may be accurate or it may underestimate. It should never overestimate.
Secondly: There is a data structure called security_counts, which is not used by any of the DW official styles, and which I suspect nobody actually used because half of it didn't work. Here's how it will work in future:
- security_counts{"public"} will give the number of public posts on which the tag is used.
- security_counts{"protected"} will give the number of friends-locked (members-only for comms) posts on which the tag is used, if the current user has access to those posts. If not, it will be undefined.
- security_counts{"private"} will give the number of private (admin-only for comms) posts on which the tag is used, if the current user has access to those posts. If not, it will be undefined.
- EDIT TO ADD: security_counts{"group"} will give the number of posts on which the tag is used that are locked to access groups (also called access filters). This will only be visible to the journal owner (admin for comms). If the current user is no the journal owner, it will be undefined.
Also, security_counts{"friends"} is deprecated because it never worked anyway! It has been replaced by security_counts{"protected"}.
I hope that all makes sense; please ask questions if you have them.
-Simon.
EDIT: I realised that we can do security_counts{"group"} properly for journal owners, because we can assume that they can see all groups. There's still no way to work it out for other users without database-thrashing. Unlike before, for those who can see it it will now give the right number ;-)
Question...
(While I await an answer I'm thinking of tagging something currently public on my DW with an access-only tag to see how that prints out on the Tags page - in terms of styling the CSS for greater visibility of those tags on that page, it never occurred to me before that I might want to style for split usage, too.)
Re: Question...
So in the example that you give, if you were logged out at present you would see "foo: 20". With this change, you will see "foo: 17".
Re: Question...
This was not the expected behavior...both posts aren't public, yet the HTML is identifying the one tag used on both of them as indeed public, and thanks to that I can't style one access-level (access-only) to differentiate it from the public use of the same tag - the access-only posts tied to that split-use tag get lost on the Tags page, in other words, since there is no picking them out through HTML and CSS.
Will this behavior change once the bug fix goes live, or are we stuck with it? (And if we're stuck with it, maybe I need to make a post to DW Suggestions ..so in other words, if I'm using the "about" tag twice, once publicly and once on an access-only post, I want it to either print twice on the Tags page with the right HTML class appended to each link in the source, or else I would like to see DW come up with new split-usage HTML classes that we can style with CSS for exactly such scenarios.
Re: Question...
Once this patch goes live it will become possible for a layout (or a style layer) to be written to show the extra "split" information of how many times the tag is used at what security level. So somebody could make a style layer that does that. Being fairly new to DW, I'm not sure whether that's a suggestion for
Re: Question...
I'm also thinking I might be at most one of three people on DW who actually styles and uses their Tags page this way, and when Denise is kind enough to let me slip a suggestion in every now and then (my failure rate is through the roof; I can't get most of my ideas posted at all) I want them to be upvoted like mad, because I really believe in all the things I'm suggesting. So I probably won't make an effort on this one despite my desire for it.
Re: Question...
Well, we already generate the "correct HTML" for what the site is supposed to do at present. What you are after is totally reasonable, but it is not the current design.
If we were to change the design, I think that it would be done by changing an S2 layout to do this. This is already possible for individuals to do on their own journal, although I appreciate that it does require a knowledge of S2 (which I don't have - I had to ask for help when testing the back end of this!).
There is no reason that it "ought to be worked into the upcoming patch". The patch is a fix to a specific bug, and that bug does not include the change that you would like. It would be wrong of me to make changes like that on my whim or yours, and the patch would probably be (rightly) rejected if I did.
If you think that all users should see the split tag information, that is a perfectly valid point of view and IMHO it is a reasonable thing to suggest on
If you don't think that's appropriate, for whatever reason, but you would still like it for your own journal, then you could ask here for help from people knowledgeable in S2 to make a layer for your journal that does this.
One of the good things about the styles system is that if one person wants their journal to look or work differently to everybody else's, that is often achievable! (and it is certainly achievable in this case)
I hope that makes sense. Feel free to ask if anything is unclear. Although I'm probably not the best person to answer style-related queries ;-)
Re: Question...
I'm afraid I worded that wrong, sorry. It was late and I was drunk, if it makes you feel any better. What I actually meant was: "[...]that could theoretically be worked into the upcoming patch". Of course, given what you said in your last reply, it seems your patch would be rejected if you had done that, so even my amended statement would still be false. But it was still worth a try. :)
What you are after is totally reasonable, but it is not the current design.
If we were to change the design, I think that it would be done by changing an S2 layout to do this.
I think I'm following you here, but my still-present confusion stems, I guess, from the terminology: to me "design" is "changing the way a web page looks" while to you "design" seems to mean (or may also mean) "changing the underlying HTML structure". My point was I wanted someone to patch the backend to change the underlying HTML structure (by adding the ability to the system to generate, ideally, just one more HTML tag restricted correctly by access for all split-usage scenarios), but not necessarily the web page itself.
But! Your use of the word "design" to mean "change the underlying HTML structure" makes me realize I'm going after this all wrong, that my idea to DW Suggestions should be to automatically print out the usage next to all tag[s] on all journals for all users, so that no end user ever has to use the ":after" psuedo-class, like I do, to make it visible again (click for a rudimentary example of the end result of my theoretical Suggestion): http://i.imgur.com/AcEgu.png
Then it's a global, system wide change that allows end users to see exactly how each one of their tags is being used at each moment without hitting the Manage Tags page, searching through the source, or clicking on any tag links to find out. If a user does not want this behavior then DW can either make it opt-in or we can use CSS to make ourselves opt-out (ideally, both). So yes, I'm actually thanking you for my confusion since I think it just gave me a good idea
that's probably going to get shot down regardless - I have a miserable track record with these things. :)Thanks for all the information, again...
Re: Question...
If it's something you want just for yourself, it's more a question for this comm - or I could probably write you up an override that'd work in pretty much any of the existing layout layers. I hacked something together in a few minutes for Simon when I was helping him test the security stuff, so I know what that bit of the code looks like.
Re: Question...
The problem with me taking the s2 code from you for this is I never split usage on my tags. That's not to say I never will, but until I do, I don't really need the s2 for that. This is one case where my concern was more for the feature simply being available to all users in case any of us want to use it (and again, one day I might: if it becomes available to all users, though, then problem solved).