Changes to TagDetails

[swaldman]

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:

• 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.

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 ;-)

Comments

Re: Question...

[swaldman]

That's intended behaviour (so far as I'm aware), and not changing. The visibility-* class doesn't refer to the visibility of posts that have the tag, but to the visibility of the tag itself. This equates to the least-restrictive security level at which the tag appears, because if you can see at least one post with that tag then you can see the tag.

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 dw_suggestions or a request for dw_styles or dreamscapes.

Re: Question...

[marahmarie]

I'm sorry it has to be in a style layer even once the bug goes live, that there's no way to separate split-usage on the server side and generate the correct HTML for the end user without having said user compile more s2 on their end on a per-user basis just to get it done. I'm not even sure I understand why that has to be. So while my idea of posting it to Suggestions might sound OK, I'm trying to figure out *why* I should suggest anything that ought to be worked into the upcoming patch.

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...

[swaldman]

I fear there is a bit of misunderstanding. Let me try to address it, bit by bit. I apologise if I explain what you already know; I'm new to this comm and thus I don't know what your level of knowledge is.

I'm sorry it has to be in a style layer even once the bug goes live, that there's no way to separate split-usage on the server side and generate the correct HTML for the end user without having said user compile more s2 on their end on a per-user basis

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!).

So while my idea of posting it to Suggestions might sound OK, I'm trying to figure out *why* I should suggest anything that ought to be worked into the upcoming patch.

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 dw_suggestions, where people would discuss the pros and cons of the idea.
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...

[marahmarie]

There is no reason that it "ought to be worked into the upcoming patch".

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...