This is a list of suggestions for the open source community to consider implementing on a branch.

• Automatic population of personal profiles from external sources - Consider implementing the population of a knowledge workers profile from other sources, such as contact information specific to the company, linkedin or an MS word doc. This would be a great consideration; but is a huge effort compared to the benefit for the ES team at this time.

• Provide Knowledge workers with an option to send emails to two address - There are some situations where users many be working for one company; but located at another company. Please consider the option to provide knowledge workers a location to enter an additional email address. it would be very important that if we change Eureka to allow content in the notification email, that the secondary email address contain any content (as it would most likely be a non-primary company email address). Note: Not being implemented in the LMCO instance because of the risk of sending LMPI to an email address other than within the LMCO company.

• Make the profile page configurable, allowing the Root Organization Coordinator to choose various fields that will be displayed on a knowledge workers profile, making it more customizable for various organizations

• Provide a banner to that Eureka Users can use in their email - For other social networks, (like LinkedIn,) there are banners that you can add to your email signature which link directly to your profile. Can they be added to Eureka? This way, people can promote and encourage others to utilize Eureka.

Alternate suggestion:

• allow arbitrary number of email addresses (some companies have multiple per person), or perhaps up to 3 emails.

• provide system-wide configuration settings that apply to the domain part of the email addr:

  • domains.allow

  • domains.deny

Perhaps make it even more general by using regex on the entire address instead of just the domain part. In that case, the files could be called email.allow and email.deny.

In principle, domains.allow and domains.deny would work like either hosts_access(5) or the cron.allow/cron.deny per crontab(1).