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