Mentions PoC

[mtomilov]

Refs #9281

Adds @mentions support in the API, emails will be addressed separately.
All of create / get / edit / search endpoints now support them.

Testing API

• Run migrations make db
• Login as devdata_admin and generate API token from http://localhost:5000/account/developer
• Create annotation

   curl -X POST --location "http://localhost:5000/api/annotations" \
   -H "Authorization: Bearer <token>" \
   -H "Content-Type: application/json" \
   -d '{
           "uri": "https://www.google.com/",
           "text": "**hello** <span>world</span>"
       }'
  

  Mentions can be already put in the text here and will be returned in the response.
• Edit annotation

   curl -X PATCH --location "http://localhost:5000/api/annotations/<url safe id>" \
       -H "Authorization: Bearer <token>" \
       -H "Content-Type: application/json" \
       -d '{
               "text": "Hello <a data-hyp-mention data-userid=\"acct:devdata_admin@localhost\">@devdata_admin</a>, take a look at this\nHello <a data-hyp-mention data-userid=\"acct:devdata_user@localhost\">@devdata_user</a>, take a look at this"
           }'
  

  But I think it's easier to test via edit on already created annotation.
• Search annotations
  curl -X GET --location "http://localhost:5000/api/search" \ -H "Authorization: Bearer <token>"
  Mentions will be returned here as well

Testing emails

Notifications are sent only on creation for now

• Create annotation

   curl -X POST --location "http://localhost:5000/api/annotations" \
   -H "Authorization: Bearer <token>" \
   -H "Content-Type: application/json" \
   -d '{
           "uri": "https://www.google.com/",
           "text": "Hello <a data-hyp-mention data-userid=\"acct:devdata_admin@localhost\">@devdata_admin</a>, take a look at this\nHello <a data-hyp-mention data-userid=\"acct:devdata_user@localhost\">@devdata_user</a>, take a look at this"
       }'
  

• Check h/mail folder for incoming mail

[mtomilov]

We'll probably want to parse userids from text_rendered html.

[marcospri]

I wouldn't be shy about importing anything from sqlalchemy. I mean speling the whole from sqlalchemy import select, ....

[mtomilov]

No problem, is this the recommended way?

[mtomilov]

Copied from emails/reply_notifcation.py for now

[mtomilov]

We will need to factor in groups / permissions / limits here as well to avoid sending notifications when not appropriate.

[acelaya]

Can any of these be None? (Other than the display_name)

[mtomilov]

Good question
uri can also apparently be false at least in the db, not sure when it makes sense but still.

[acelaya]

I think it actually makes sense. We will not want to link users in the LMS context, for example.

[acelaya]

In hypothesis/client#6787 (comment), we were discussing that perhaps we don't need to expose the username here, is it can be extracted from the userid.

I don't have a strong opinion though.

[mtomilov]

It will be coming from the mention itself like this. It seems better to just store the info from the get go, especially considering the work Marcos has done on user renames already.
So we'll be storing the username at the time of mention on the mention.

[acelaya]

Oh, right. This is the username the user had at the time the mention was created, right?

[mtomilov]

Yeah, it's missing from the PoC due to some back-and-forth going at the time. Sorry for the confusion.

[acelaya]

thanks!