[keycloak-dev] Custom attributes on registration and account management

[Stian Thorgersen]

I think this is something to look at next year. We don't have the resources
to do it properly now. My vote is to add it to the agenda for F2F.

On 6 November 2015 at 14:36, Marek Posolda <mposolda at redhat.com> wrote:

> On 05/11/15 17:11, Bill Burke wrote:
> >
> > On 11/5/2015 5:46 AM, Marek Posolda wrote:
> >> I wonder if we should improve handling of custom attributes in
> >> freemarker templates and their validation. Let's assume that I want to
> >> add custom attribute "birthday" and I want to add it to all screens
> >> where user can create/edit account. I can see those issues:
> >>
> >> - Admin will need to edit 3 separate freemarker templates (registration,
> >> account management, update profile page) to have this attribute
> >> displayed on all those places.
> >>
> > we've discussed this before. The problem is formatting in each of the
> > UIs. Often ordering of attributes is important. Grouping of attributes
> > is a must too.
> >
> > i.e. Address, State, Country, Postal Code
> >
> > These 4 attribute must be grouped together, and address must come before
> > state, and so on.
> >
> > You might also have a "Billing Address" group that needs to come after
> > Home Address group.
> I am not seeing an issue with ordering? The same order you configure in
> admin console, the same is used in template. It's classic sorted list,
> not special tricks needed IMO. The grouping some attributes can be
> easily addressed too IMO.
> >
> > So, we'd have an automatic way for displaying attributes, then the
> > developer would think "that looks like shit" and want to format things
> > himself.  Stian seems to think that CSS will solve this problem, but I'm
> > not convinced.
>

CSS can do a hell of a lot more than you think it can ;)

But, I agree it can't always cover everything - that's why I've been saying
we need to be able to define templates, but at a smaller granularity.
Having to define the whole update-profile page just to add an attribute is
not very elegant.


> I agree we can't address all possible sort of issues, but IMO it's good
> to have something, which will address 90% of cases? We can provide types
> (like combobox "Gender" with values "male" / "female" ). We can also
> handle multivalued attributes. And most importantly we can provide
> validations for all 3 screens. People won't need to write their own Java
> validators when they want something simple like ensure "mandatory" field
> present or validate with regex. They will still have possibility to
> inject the custom validator if they want it.
>
> At least validation is must IMO as there is no way to add custom
> validation for account mgmt or update profile right now.
>
> What we can't easily do is client-side validation and stuff for
> display/hide something based on value of other attributes (For example
> display attribute "Favourite car sign" just if selected gender is "male"
> ). But not sure if this is often requirement.
>
> I am seeing lot of similarity with your kc-provider-config directive in
> admin console. It can't address all "generic" sort of things and
> client-side stuff etc. But for most cases, it's sufficient.
> >
> > Also the look and feel could be quite different between registration,
> > update profile, account management, and the admin profile.  IMO, it
> > would end up being easier to just edit the freemarker pages directly
> > than to have to define each attribute and how it is grouped, ordered,
> > and displayed on each of the pages within an admin console UI.
> >
> >
> There could be 3 checkboxes where can admin select if he wants to add
> field on registration, account mgmt and update profile. I am not sure if
> we need anything for admin console as we already have "Attributes" tab
> for users, which is almost ok IMO (we don't have nice solution for
> multivalued attributes).
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151106/dc54a030/attachment.html