Larger organizations tend to deploy a multitude of valid mail alias definitions for their members. They might be formed of the elements first name, last name, middle name, user name together with example.com, sub1.example.com etc. Now within Filr the email address as stored in the local database in a single value field. This causes a bad user experience in the following scenario which occurs frequently in my organization: An internal user is encouraged to use Filr instead of abusing the mail system by sending email attachments to her or his coworkers. She or he will then paste the already existing list of email addresses in the sharing dialogue box of Filr.
In case an address matches the one stored in the Filr database everything is fine and the respective internal user will get a notification about the shared items. But this is by pure chance. In the likely case the address is a different alias than the one known to Filr the person will get an invitation to register a new Filr account for this email address. Thus the user will end up with an internal as well as an external account. In order to access the shared data she or he will have to log in with the external one, and for working with the own data the internal account has to be used. This is very confusing and inconvenient.
I see two possible enhancements for Filr to improve on this behavior:
1) Make the email address in the Filr user record a multiple value field. Filr should be able to identify an internal user if any of his mail alias definitions is specified. Ideally the routine importing from LDAP will allow for multiple entries ot the field emailAddress and not just one like it is currently implemented. This mapping should also support multi-value fields as sent from the LDAP server.
2) Allow the administrator to merge external and internal accounts into a single internal one. This might put additional stress on the help desk server administrators and likely cause confusion with respect to passwords. So solution 1) will likely be the preferable one.

by: Günther S. | over a year ago | Administration