<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    More emails for one account are simple, you need one to be main for
    login purposes and to be used to send "forgot pwd" and similar
    emails to, we have it now. Rest emails may be just in common
    attribute (it allows to store more values). Question is if you want
    to support validation/verification process for these additional
    emails and consider them in uniqueness tests ;-)<br>
    <br>
    More accounts with same email is more tricky ;-)<br>
    <br>
    Vl.<br>
    <br>
    <div class="moz-cite-prefix">On 18.3.2016 14:46, Stian Thorgersen
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAJgngAczHEa9CWWbzEeA5f3cBQmXbGWURQRev2yPLcjLTP-5tw@mail.gmail.com"
      type="cite">
      <p dir="ltr">+1 Primary or "login" email should be left on user
        entity. We need to consider how we're going to support having
        more than one email associated with one account as well as
        multiple accounts with same email. I'd say we'd have a login
        email, but also contact emails.</p>
      <div class="gmail_quote">On 18 Mar 2016 2:41 p.m., "Marek Posolda"
        &lt;<a moz-do-not-send="true" href="mailto:mposolda@redhat.com">mposolda@redhat.com</a>&gt;
        wrote:<br type="attribution">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor="#FFFFFF" text="#000000">
            <div>+1 for have unified mapper for properties and
              attributes. That's very easy to do, we can just fallback
              to setAttribute/getAttribute if there is not property .
              LDAP UserAttribute mapper is already unified and is doing
              like that.<br>
              <br>
              Having the basic attributes in separate table might
              theoretically have some performance impact. For example if
              email is stored as attribute, then each searching by email
              needs to join 2 tables instead of one. There is also DB
              constraint to enforce unique email. So maybe at least
              email worth to keep as it is?<br>
              <br>
              Marek<br>
              <br>
              <br>
              On 18/03/16 13:36, Stian Thorgersen wrote:<br>
            </div>
            <blockquote type="cite">
              <p dir="ltr">+1 Makes sense to me. Especially the part of
                not having two different mappers. It could still be
                useful to have a get/set for common attributes, but they
                would just pass through to attributes rather than
                separate fields.</p>
              <div class="gmail_quote">On 18 Mar 2016 1:17 p.m.,
                "Vlastimil Elias" &lt;<a moz-do-not-send="true"
                  href="mailto:velias@redhat.com" target="_blank">velias@redhat.com</a>&gt;

                wrote:<br type="attribution">
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
                  <br>
                  as part of planned persistence storage SPI changes we
                  talked about on<br>
                  f2f we should probably consider removing of first
                  name, last name and<br>
                  email from UserModel property, but implement them as
                  normal user<br>
                  attributes with predefined names.<br>
                  <br>
                  This unification should simplify few things, for
                  example separate<br>
                  mappers for attributes and properties in Clients and
                  Identity Providers<br>
                  configuration, which may be hard to understand for
                  beginners (questions<br>
                  like "what the hell is difference between user
                  properties and<br>
                  attributes?", "What user properties are available
                  there?").<br>
                  <br>
                  This should also simplify implementation of User
                  profile validation SPI<br>
                  we talked about on f2f meeting.<br>
                  <br>
                  What do you think?<br>
                  <br>
                  Vl.<br>
                  <br>
                  --<br>
                  Vlastimil Elias<br>
                  Principal Software Engineer<br>
                  Developer Portal Engineering Team<br>
                  <br>
                  _______________________________________________<br>
                  keycloak-dev mailing list<br>
                  <a moz-do-not-send="true"
                    href="mailto:keycloak-dev@lists.jboss.org"
                    target="_blank">keycloak-dev@lists.jboss.org</a><br>
                  <a moz-do-not-send="true"
                    href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
                    rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
                </blockquote>
              </div>
              <br>
              <fieldset></fieldset>
              <br>
              <pre>_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
            </blockquote>
            <br>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team</pre>
  </body>
</html>