Simon ([personal profile] swaldman) wrote in [site community profile] dw_styles2012-09-11 12:04 pm
Entry tags:

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

momijizukamori: (dreamsheep | styles)

Re: Question...

[personal profile] momijizukamori 2012-09-12 09:39 pm (UTC)(link)
To add to what [personal profile] swaldman said above - if you think having tags display like that would be a benefit for the DW community as a whole, make a [site community profile] 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.
marahmarie: my initials (MM) (Default)

Re: Question...

[personal profile] marahmarie 2012-09-15 04:10 am (UTC)(link)
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).