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

Question...

[marahmarie]

Will the new system for tags split the value when it prints it out? So say you've made 20 posts tagged "foo" but only 17 are public, two are protected and one is private. Will the system print the tag three times on the journal's or comm's Tag page for the admin/journal owner, in order to visibly reflect the split usage? (I'm assuming it currently does not do so.) Will it print such a tag out twice for others who have access to it but are not the admin/journal owner? Or will you see the tag on that page only once no matter how many different ways it's used (public\private\access-only) and how many levels of access you have?

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

[swaldman]

Not unless somebody writes a style that does that. The information will be available for styles to use (in theory it already is, although it doesn't work right), but the only immediate change to existing styles is that the number next to the tag will not include posts that you don't have access to.

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

[marahmarie]

Just tested splitting a tag ("about") between one public and one access only post. Normally, if the tag were used just for access-only posts tied to it, my CSS would print [access-only] after said tag on the Tags page. But by adding a public "about" tag to my originally access-only "about" tag, it converted the HTML list class used for both tags to "visibility-public", rendering my special CSS for access-only tags useless (since now it has no access-only HTML class to catch and apply my custom CSS to).

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

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

Re: Question...

[momijizukamori]

To add to what swaldman said above - if you think having tags display like that would be a benefit for the DW community as a whole, make a dw_suggestions post about it - the fix is fairly simple, but it's a definite change, and there would need to be some decicions made about implementation.

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

[marahmarie]

Thank you very kindly for the offer, but I probably won't take you up on it just yet. I've spent a few days rolling it around deciding what to do and some misread of something swaldman said above makes me realize I want to make a different (and probably better) suggestion to DW Suggestions - now that I think about it, I'd prefer to see all users have the tag access-level visible on all tags (restricted by the user's access level, of course) on the Tags page, which might also solve the split-usage problem, since I think I can probably roll that into the same Suggestion.

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