Giters

amschaal / bioshare

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Keep emails?

samhunter opened this issue · comments

commented

The iLab project management system has the ability to send messages via email, but also keeps all emails associated with a project so that it is easy to review all communication associated with a project. This is great for old projects where emails can be tough to track down.

One of the down sides of the iLab system is that you HAVE to use the iLab system to send emails.

Could Bioshare keep emails sent from within the system ordered chronologically, but also attach a project ID to the subject line (or maybe somewhere in the email) so that "reply to all" includes a BioShare email address, where all messages caught and logged to the proper project, even when they are sent from a different email client?

commented

To summarize, it seems you'd like Bioshare to:

  • Add project ID to subject line
  • Keep records of emails sent (so they can be viewed chronologically)
  • Ingest emails sent to Bioshare with project ID in subject line

Adding a project ID to the subject line would be trivial, and would allow email clients to group them better. It would probably be useful to have the more human readable share name in the subject, but we may start to have pretty long subjects.

I'd really like to give some thought as to whether we want the system tracking emails. As for sharing emails, by default anyone who has been shared with has received an email. Is it useful to see a record of those emails? As for custom emails sent, who should be able to see those - only the sender, share admins, everybody? Obviously there are some considerations as to how to implement it, and perhaps whether it is worth the time and overhead to support the feature.

The last feature is the most difficult. Processing emails requires having its own mail server with custom email processing scripts, which can add quite a bit of libraries, configuration, and maintenance. Projects that support email processing do so because communication between users is a central part of the application's functionality. I'm not really sure that tracking and relaying communications is central enough to Bioshare's goals to prioritize the considerable amount of work involved.