<nick> @chdorner there's nothing that would stop me flagging my own annotations, is there?
<chdorner> nope
<nick> right
<nick> I'm wondering why flagging doesn't appear to be updating the "flagged" key on QA
<nick> (haven't checked prod atm)
<chdorner> are your API requests authenticated with your user?
<chdorner> the same user who flagged the annotation?
<nick> d'oh
<nick> sorry, I forgot two things at once
<nick> a) API requests in the browser aren't authed
<nick> b) `flagged` isn't global
<nick> yep, it's working fine :slightly_smiling_face:
<chdorner> :slightly_smiling_face:
<nick> ok, testing hiding at the moment, and I'm not sure it's quite working as expected
<nick> I have a test group with two users: one the group creator, one not
<nick> the group creator hid an annotation by the other user
<nick> and oddly, while both users can still see the annotation on activity pages (as expected)
<nick> the group creator can't see it in the client
<nick> it doesn't seem to be being returned from the API
<chdorner> huh, that's weird
<chdorner> both use cases run through the same code path
<chdorner> I'll check it out on qa quickly
<nick> I've added a third user, and they can't see the annotation in either place (good), but I do notice that the annotation count on the search page is wrong
<nick> (i.e. the count includes the hidden annotation)
<chdorner> the search page meaning activity pages?
<nick> yep
hslack has quit
hslack joined the channel
<chdorner> huh, it works fine for me on QA
<chdorner> this is what I did: I have three accounts: chdorner (group creator), tester1, tester2 1. tester1 annotated https://qa.hypothes.is/docs/help 2. all three accounts can see the annotation on the group activity page + in the sidebar 3. for giggles: tester2 made an API request to flag the annotation (`PUT /.../flag`), chdorner got an email 4. chdorner made an API request to hide the annotation (`PUT /.../hide`) 5.
annotation both on the group activity page + in the sidebar - tester2 cannot see it anywhere
<nick> huh, ok
<nick> let me check what's gone on with this one, then
<nick> @chdorner but I take it the annotation count on the activity pages is still incorrect for tester2?
<chdorner> ah, let me check
<chdorner> nope, it's correct as well
<nick> hmm
<nick> this sounds suspiciously like the annotation in question didn't correctly reindex, no?
<chdorner> your problem?
<chdorner> or that it works for me?
<nick> my problem
<chdorner> so your problem is that the group creator can't see the annotation
<nick> I'm looking at the database and the moderation entry is there correctly
<chdorner> after it's been hidden?
<nick> yep
<chdorner> hmm, I don't think that's a reindex issue
<chdorner> because not returning it in the search result would mean it's been indexed correctly
<chdorner> otherwise we wouldn't filter it out
<chdorner> you can try updating the text of the annotation and see what happens
<chdorner> I'm trying again locally to see if the websocket server does everything correctly as well
<chdorner> hmm, it doesn't seem to remove the hidden annotation through the websockets
<chdorner> I'll add it to the checklist of my card
<nick> oh, I have a suspicion I know what's going on here
<nick> give me one sec to check
<nick> hmm, maybe not
<nick> I was wondering if maybe the `terms` filter for group wasn't behaving the way we expected for users who are admins of multiple groups
<nick> but the documentation at least implies it should work correctly
<chdorner> fwiw, my group creator that I used for testing is a group creator on multiple groups
<nick> ah, ok, as usual in these cases, I'm being an idiot
<nick> I made the annotation on `https://hypothes.is/docs/help`, it seems.
<nick> And so viewing on `https://hypothes.is/docs/help` _would_ show the annotation to the moderator, except that we haven't deployed the code there.
<nick> While viewing on `https://qa.hypothes.is/docs/help` doesn't work because it's a different URL.
<nick> Checking `https://qa.hypothes.is/api/search?uri=https://hypothes.is/docs/help&group=JDV7XyiD` manually and it all works fine.
<nick> :+1: :rocket: :cake: etc.
Action: nick pushes green button
<chdorner> Yay!
<nick> This is good, because as you say, I couldn't see how that could be wrong without something being really spectacularly broken in our search code.
<nick> @chdorner lo and behold, it works in prod ;)
<dthompson> nick: Or, more charitably, the fact that our QA and production environments are visually indistinguishable and share a database makes it *very* easy to end up looking at the wrong URL.
<robertknight> ^ Related to this, I was thinking about testing of moderation and flagging yesterday.
<robertknight> One way that we could start to dogfood it would be to enable the flagging button behind a feature flag for all users (not just third party users as is currently the case) and make Hypothesis admins moderators of the Public channel. We can also test it out in our own groups of course - but there will be more annotations that we actually want to smite in the public channel.
<dthompson> I like that idea, @robertknight. I was thinking it’d be helpful to have some way to do a controlled rollout and be able to test it in production, and that looks like a pretty neat solution.
<dthompson> Related: I think being able to roll these things under a feature flag and test them in production is *massively* helpful, and we should do more of it. When we built the first prototype of study groups at FutureLearn, we learnt a *huge* amount from rolling it out on a fake admin-only course and having a play with it.
<nick> Yep, agreed, and while we haven't done that much of it since you've been here that is actually something we've done in the past
<nick> Up to and including using feature flags to manage the migration of our entire annotation persistence layer from Elasticsearch to Postgres. (Buy @chdorner a beer or three and get him to tell you about that one...)
<nick> The only sticking point with @robertknight's idea is that we don't have group moderators :slightly_smiling_face:
<nick> At the moment there's only one group moderator, and that's the group creator.
<chdorner> Well, Dan will get all the flagging emails ;)
<robertknight> Right - what I imagined is that somewhere we have some logic like this: ``` # Pseudo McCode is_moderator = group.creator == request.authenticated_user ``` Which we could change to ``` is_moderator = group.creator === request.authenticated_user or request.authenticated_user.is_admin ```
<robertknight> Is that possible / reasonable?
<dthompson> I _believe_ the current check is for whether the current user has `admin` permission on the annotation’s group. Currently I think that comes from this line – https://github.com/hypothesis/h/blob/11ee254ab0... – and I think we could add something similar to the `WorldGroup` class.
<chdorner> The email sending works a bit different, it only works for one user and that's `group.creator`
<chdorner> How about we just prioritise group moderators and launch flagging in the public channel once that's done?
<robertknight> At the very least I think we should enable ourselves to test flagging / moderation with first-party accounts in groups.
<robertknight> Which means enabling the ‘flag’ action in the client for first-party users behind a feature flag.
<robertknight> Unless that involves a bunch of extra backend work which I’m not aware of?
<chdorner> Yes I totally agree, but I'm not really sure it's worth doing a hacky implementation allowing multiple people to moderate
<chdorner> There's a clear path we and our partners want to allow multiple moderators, a minimal MVP is not super hard, there was a spike about that
<robertknight> > Yes I totally agree, but I’m not really sure it’s worth doing a hacky implementation allowing multiple people to moderate Right, I’m fine with that. We don’t need to do that to enable use of the feature end-to-end.
<robertknight> Is there anything in the implementation that restricts it to third-party accounts or does it work fine with private groups created by first-party accounts?
hslack has quit
hslack joined the channel
<nick> @robertknight it works fine -- the only limitations are in what the client displays at the moment
<chdorner> and the `__world__` group doesn't have a creator, so nobody is allowed to hide annotations, and nobody gets emails
<chdorner> basically: flagging works fine, hiding doesn't
<robertknight> But hiding works in private groups?
<robertknight> That’s all we need for internal testing.
<chdorner> yes
<chdorner> emails as well
<robertknight> Great. So OK if I submit a PR to enable the flag action for all users (not just third party) behind a feature flag?
<chdorner> @nick h#4497 needs a rebase, presumably just the imports because I merged the resources moving PR