[keycloak-dev] How to render claim data entry and display?

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 2:59:13 PM
> Subject: Re: [keycloak-dev] How to render claim data entry and display?
> 
> 
> 
> On 2/23/2015 8:21 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, February 20, 2015 3:15:19 AM
> >> Subject: [keycloak-dev] How to render claim data entry and display?
> >>
> >> I'm not sure how to render claims within the admin console, registration
> >> page, and in the user self service pages.  The thing is that generically
> >> rendering user metadata can look quite ugly.  Address is one example
> >> where the grouping and ordering of each attribute is important to look
> >> nice.  There are other instances where you need to group types of data
> >> together (home phone, fax, work phone, mobile).  Then there is the
> >> problem of what claim data do you show on what pages which is harder
> >> than it seems, for example, registration page might only require a
> >> mobile number, but admin console and user profile page might want to
> >> show home, fax, work too.  You would end up having to define a data
> >> model that captured metadata for each page type (registration, user
> >> profile, and admin console).  Finally, if you have generically rendered
> >> claims, what happens when the user wants to override this rendering and
> >> put their own formatting, .css types, etc. in?
> >>
> >> This leads me to think that we should just punt to the developer.  In
> >> this case, there would be no data model for claim types and everything
> >> would be driven simply off of UserModel.attributes.  Develoeprs would
> >> have to extend the admin console and account themes and we would provide
> >> a template for referencing UserModel.attribute data within Angular HTML
> >> (admin console) or Framemaker (account service, registration page).
> >
> > For registration page and account management I think supporting simple
> > attributes in the default template would be good enough. Users can then
> > extend the templates if they need something more. In the future we can
> > look into creating widgets that can display certain things so users don't
> > have to extend the whole template, but just parts of it.
> >
> > For the admin console it would be best not to require users to extend IMO.
> > We should be able to allow users to view and edit complex attributes (at
> > least a complex attribute that is a list of simple, rather than complex of
> > complex). Initially we could just display the JSON for the complex
> > attribute directly, then create an view/editor for it later.
> >
> 
> I just don't want us spending time implementing and maintaining an HTML
> editor for something the user will usually be extending a theme for anyways.

Yes, I totally agree, but that wasn't what I proposed though. What I'd propose we do is:

* Admin console - just list claims, sorted by name. For simple types we display the value and allow editing with input text. For complex we display json and allow editing in textarea. In the future we can add a feature that allows view/edit complex attributes directly.
* Registration and account management - only display simple types. We should provide some mechanism for choosing which are displayed and order. For complex types or better control on how it's displayed (other than a simple list of label, input) users are expected to extend the template. In the future we can add a feature that allows extending parts of a template, which would make it easier to edit and also maintain in the long run. For example instead of overriding the whole registration page a user could override just the form part, or even just how a specific claim is displayed.

> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>