Show Advanced KnowledgeHide Advanced Knowledge

Second email address for user accounts

1 Initial Problem

In some situations it is very helpful to store a second email address for user accounts. For example trainees in companies or authorities have a private and a business email address and no access to both in every case; it should be possible for them to store both email addresses in their personal ILIAS profile.
So they can be notified in both cases, when they are working at home and in case they are present in the office. With only one email address users with no concurrent access to both email addresses (e.g. it is technically prohibited by their employer) must decide permanently which email address it is better to store in ILIAS.

2 Conceptual Summary

To solve this problem it is technically necessary to: 

• Add a new database field 'EmailHome' (analogous to 'PhoneHome') in table 'usr_data'
• Add a new email input field to the personal profile form
• Add a new email input field to user profile form in the global and local user administration
• Add a new checkbox to define the visibility in the user's public profile
• Handle this email address in the user export/import and all API functions (currently only SOAP)
• Add a new section for this email address to the 'Standard Fields' section of the global user administration
• Respect this field in the export of course and group participants
• Respect this field in the global user search (see: ./Services/User/LuceneObjectDefinition.xml)

Users should have the possibility to decide whether or not ILIAS should send external emails to the new email adress as well. Therefore a new checkbox 'Sent notifications to private email address' should be added to the mail options/settings form.
 
The second email address should be left out of consideration for specific (except for courses and groups, see chapter below) CSV/XML/Excel exports, e. g. in tests, surveys and in table filters of specific services.

3 User Interface Modifications

3.1 List of Affected Views

• Administration > User Management > List of users (as an optional table column)
• Administration > User Management > 'Add User'
• Administration > User Management > 'Edit User'
• Administration > User Management > 'Standard Fields'
• Administration > User Management > Extended User Search
• User search provied by ilRepositoryGUI
• Personal Data and Profile
• Courses > Members > Export Participants > 'Start CSV/Excel Export'
• Groups > Members > Export Participants > 'Start CSV/Excel Export'
• Profile
• Settings > Mail Settings
• Mail  > Options

3.2 User Interface Details

• None, except respecting the new field in the views mentioned above, analogues to other user profile fields.

3.3 New User Interface Concepts

• None

4 Technical Information

• Performance: There may be a performance impact because the indivual setting has to be checked for every email recipient.
• Dependencies:
  • User Service: Field configuration, visiblility, input, export, import
  • Search: see ./Services/User/LuceneObjectDefinition.xml

5 Contact

• Idea / concept: (René Sens, Bundesverwaltungsamt, rene.sens@bva.bund.de, 022899 358-7315)
• Maintainer: Jansen, Michael [mjansen] for Mail, Meyer, Stefan [smeyer] for User Service
• Implementation of the feature is done by Jansen, Michael [mjansen]
  

6 Discussion

Amstutz, Timon [amstutz], Jan. 12. 2017: Could this use case also be handled by integrating Multiple Accounts for a User? The need for a second mail adress to me somehow hints, that a user is using two different accounts on ILIAS merged into one user.

Kiegel, Colin [kiegel] 2017-01-24: I completely understand the requirement. However the solution does not scale very well. What if some installation (or user) wants to have a third email field?

• What if there was a new type 'email' for custom fields (aka user defined field)?
• Each installation could opt-in to define X additional email address fields
• The mail settings should be adapted to support forwarding to custom email fields
• ILIAS could ship with a pre-configured 'private email' field - but admins are able to DELETE it.

The only temporary drawback I can think of is that custom fields don't support translation yet. But I think this would be a much cleaner solution.

Note: I basically made a very similar suggestion to move existing hard-wired social media fields to pre-configured custom fields here >> Update Step. The same problem about lacking translation arises. However I am sure this drawback will be fixed within some reasonable time, now that we have the SIG Language Support to push things. ;-)

The SIG Language Support already has this feature request, where we want to introduce an official UI component that handles multilingual input for single+multiline fields. This idea could then be used for custom fields.

Kunkel, Matthias [mkunkel], January 25, 2017: I would prefer a label like 'Second E-Mail' instead of 'Private E-Mail'. We do not know if the second mail address is always a private one or maybe another job or university account.

JourFixe, ILIAS [jourfixe], JAN 30, 2017: We appreciate the feature request and schedule it for 5.3. We prefer the label 'Second E-Mail Address' and we would like to have a modified settings screen where the dropdown 'Incoming Mail' is changed to a radio group with sub-options for 'local and forwarding' and 'to external mail...'. This sub-option allows to specify to which mail address a mail is sent.

7 Implementation

{please give a description of the final implementation and add screenshots if possible}

Test Cases

Test cases completed at August 03, 2017 by Matuschek, Nadia [nadia]:

• C18583: Standardwert bei Maileingang im Administrationsmenü setzen
• C18584: E-Mail an beide E-Mail-Adressen empfangen (lokal und Weiterleitung)
• C18585: E-Mail nur an zweite E-Mail-Adresse empfangen (lokal und Weiterleitung)
• C18586: E-Mail nur an erste E-Mail-Adresse empfangen (lokal und Weiterleitung)
• C18587: E-Mail-Weiterleitung an beide E-Mail-Adressen bei erstelltem Forenbeitrag (lokal und Weiterleitung)
• C18588: E-Mail-Weiterleitung an zweite E-Mail-Adresse bei erstelltem Forenbeitrag (lokal und Weiterleitung)
• C18589: E-Mail-Weiterleitung an erste E-Mail-Adresse bei erstelltem Forenbeitrag (lokal und Weiterleitung)
• C18590: E-Mail-Weiterleitung an beide E-Mail-Adressen bei erstelltem Forenbeitrag (an eingetragene E-Mail-Adresse)
• C18591: E-Mail nur an zweite E-Mail-Adresse empfangen (an eingetragene E-Mail-Adresse)
• C18592: E-Mail-Weiterleitung an zweite E-Mail-Adresse bei erstelltem Forenbeitrag und nutzerveränderter Weiterleitungseinstellung (an eingetragene E-Mail-Adresse)
• C18593: E-Mail-Weiterleitung an zweite (nicht hinterlegte) E-Mail-Adresse bei erstelltem Forenbeitrag und nutzerveränderter Weiterleitungseinstellung (an eingetragene E-Mail-Adresse)
• C18594: E-Mail-Weiterleitung an beide E-Mail-Adressen bei Übungsabgabe (an eingetragene E-Mail-Adresse)
• C18595: Hinweismeldung bei nicht hinterlegter zweiter E-Mail-Adresse und Weiterleitungseinstellung auf diese E-Mail-Adresse

Approval

Approved at 03.08.2017 by Sens, René