Evaluator Invitation Queue

[3mcd]

Issue(s) Resolved

Resolves #109

Test Plan

[kalilsn]

I'm worried about this change, since not everyone has a first and last name. Is there some reason we need to separate these and require both?

I would prefer if we store people's name in a single column and split it where needed. Or at least make the lastName column nullable, which is what ORCID does.

[3mcd]

I think we should go with last name nullable for now. We have a lot of issues on V6 with names since contributors only have one name field. Dutch names are apparently a huge headache esp. with a single name field.

[gabestein]

Eric's right, last name is needed for citation splitting purposes. But can definitely be nullable. For context, see:

knowledgefutures/pubpub#1063
knowledgefutures/pubpub#784

[kalilsn]

It's possible I'm not completely understanding how this is used, but if the extra fields let an integration add additional variables at runtime, will we have any way to tell users what those variables are (on our imaginary documentation pages)?

[kalilsn]

This particular case seems like it could instead be solved by allowing the emails endpoint to take a pubId and offer {{ pub.* }} fields in the template context if that's passed.

That said, I guess it's already unclear how users should find out about the email syntax, since it's defined by core, but used by integrations. I'm hesitant to just say that integrations are responsible for describing the variables available because I think we will probably want to use the same template code for sending emails within core.

[3mcd]

The invite link is tricky because it's kinda complex. It's an HTML element, which Unjournal has already expressed hesitation about using, and composed of 5 separate tokens, which makes the structure of the link even harder to understand.

Having a shorthand for common integration-specific URLs seemed like a decent way of solving this problem. The extras can't do anything regular interpolation/tokens can't already do. So it's not really introducing new/arbitrary runtime behavior. Just a mechanism for small partials/shorthands. extras aren't registered or anything. They're aliases just used in that single request to sendEmail.

[kalilsn]

The invite link is tricky because it's kinda complex. It's an HTML element, which Unjournal has already expressed hesitation about using, and composed of 5 separate tokens, which makes the structure of the link even harder to understand.

Yeah, this makes sense and I understand not wanting to make them responsible for constructing that link. I think that's an issue that will probably keep coming up with these token links. Maybe we can eventually make that easier in whatever editor we end up using for these templates.

Having a shorthand for common integration-specific URLs seemed like a decent way of solving this problem. The extras can't do anything regular interpolation/tokens can't already do. So it's not really introducing new/arbitrary runtime behavior. Just a mechanism for small partials/shorthands. extras aren't registered or anything. They're aliases just used in that single request to sendEmail.

I agree that we should make all of this info available in the email templates, and we should make it simpler to construct those URLs. And I'm not asking you to change this right now. But I was thinking about David's comment today where he asked what variables were available in the email template. If we want to have some user-facing documentation about this template syntax and the available variables we have to either:

• Put it in core, which means these extras can't be documented since they're defined in integration code.
• Make the integrations responsible for displaying that documentation, since only they know what extras they've defined

I'm a little uneasy about the second option!

[kalilsn]

I think it's ok to delete the invite pubs, but this seems like an endpoint we probably won't want to make available to anyone else, or we'll need to implement some kind of soft deletion.

[3mcd]

Agreed, soft deletes are a must. I added a ticket here: https://github.com/pubpub/v7/issues/136