Add TTO email as attribute for Institutions, email completed forms

[Koeng101]

Is your feature request related to a problem? Please describe. When signing MTAs, we need to send back the counter signed MTA (the MTA we get from Stanford) to the original signer (the institution we ship to).

Describe the solution you'd like When we upload a countersigned MTA before shipping material out, we would like for this to notify the other signatory in an email (ie, send the MTA attached to an email sent to that other institution's TTO)

Describe alternatives you've considered

Anything else? This would probably entail adding in a field to "Institutions" of the TTO's email address, plus getting some type of email form system going.

[vsoch]

This sounds like something we would need SendGrid for.

To clarify - this countersigned MTA is after the user signs and uploads, and then the lab downloads (does something with) and re-uploads? Would a re-upload of the MTA by the lab always result in emailing the signatory the form?

I'm not sure how sending files works with SendGrid, but minimally we could prepare some kind of file served from FreeGenes. Is there any reason we couldn't use the email address associated with the user account that created the order (instead of adding another field?) The issue with adding another field is that it's not saved to the database, so it would require yet another copy paste. I'd say we use the user account email and then if there is issue, address it later.

Still working on freegenes python and the composite parts endpoint!

[Koeng101]

To clarify - this countersigned MTA is after the user signs and uploads, and then the lab downloads (does something with) and re-uploads?

Yes, this is correct

Would a re-upload of the MTA by the lab always result in emailing the signatory the form?

Yes

Is there any reason we couldn't use the email address associated with the user account that created the order (instead of adding another field?)

Yes, the user account isn't the target for the information - that is the tech transfer office of the university (oftentimes, those two people are pretty separated from each other).

The issue with adding another field is that it's not saved to the database, so it would require yet another copy paste.

Can we just add another field to the database?

Still working on freegenes python and the composite parts endpoint!

Awesome!

[vsoch]

We aren't currently storing personal information like addresses, etc., so what we would need to do is add a field, have the field go forward for the lab to receive (along with the other shipping fields) and then be required for the re-upload of the MTA (and still not saved).

[Koeng101]

I completely understand that for personal information, like user account information, but this is for a Tech Transfer Office's email addresses, which aren't really personal, they're specifically for this kind of information for institutions. They're also usually online anyway (https://doresearch.stanford.edu/research-offices/otl-office-technology-licensing)

MTA (and still not saved)

Are MTAs not saved in our database?

[vsoch]

Just the pdf files on the filesystem - not the fields that get written into them.

[Koeng101]

I hate to resurrect an old topic - but why not just save them as fields in the database? MTA files are really important to have saved securely, and I presume backups are most robust with the database.

[vsoch]

We need to take every effort to not store personal information in the database. We have the MTA files saved securely, and that's probably a compromise because they do have names and addresses.

[Koeng101]

Couldn't we just have informed consent there? People can make decisions on whether or not their information is stored - in this case, they can opt out of our system by not ordering something. Perhaps a

WE SAVE THE OPENMTA IN OUR DATABASE TO PRESERVE THE ITS DATA. IF OUR DATABASES ARE HACKED, ANY INFORMATION IN THE OPENMTA MAY BE LEAKED

or something along those lines before people order things.

[vsoch]

We already save the MTA - just to be clear - you want to save complete names, addresses, emails, alongside that? :/

[Koeng101]

I'd precisely like the MTAs to be saved in a way we make sure they do not go away and we can easily send them to people. I'm agnostic to method there, but seems like the easiest way is database.

Remember, these mostly aren't personal information: it's lab and institution addresses, which are almost always online. On the topic of names: we want to be able to address people by a name, and that can be a pseudonym - though I'm guessing most people who are using our system couldn't care less that their name (or pseudonym) is saved in a database.

On email addresses: we need a way to contact these people.

From a different framing, the primary reason we want people to sign the OpenMTA is so that MTAs go away (since unfettered redistribution is legal with the OpenMTA) - in order for that to hold any weight that we can depend on, we need good records of their use. The vast majority of users, due to the type of work they do, have systems which basically make that information public. The minority of users who really really care about saving of names and addresses we can't operate with in the first place until we have a robust network of OpenMTA documentation going out of our institution.

Even Stanford doesn't really seem to care about my information - They keep my actual personal email right on their website (https://profiles.stanford.edu/185216) for public viewing. In order for someone to get that on our specific node, they'd have to hack our system itself to just get my email and name.

[Koeng101]

Like, to be technically considered an institution you literally need to have a public address (https://www.guidestar.org/profile/82-3886459)

[vsoch]

I need to talk to my colleagues again about this - I'm not even happy to have it stored as PDF but realize that's an extreme. Stanford profiles shows information that (via a user profile) they have consented is ok to show. As the developer of a web server I am hugely uncomfortable with having full names and addresses stored in the database, especially if it can be avoided. This goes much deeper than "But I found it here so it must be okay" and into GDPR and a lot of policy that is over my head. Until there is certainty about these details, I will continue to take the most conservative option.