8:29 a.m.
+1
On 06/11/15 15:23, Stian Thorgersen wrote:
Password policies needs to be made into an SPI as well
On 6 November 2015 at 15:23, Stian Thorgersen <sthorger(a)redhat.com
<mailto:sthorger@redhat.com>> wrote:
You're right validation is required now. I feel a new Validation
SPI coming up?
On 6 November 2015 at 15:21, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
Sure, if it's not a blocker for jboss.org <http://jboss.org>
team to not have it in 1.0 ? I guess dynamic templates can be
postponed, but at least missing validation for account mgmt
and update profile is quite a gap IMO.
I've discussed this with Vlasta a week or two ago (and that's
one of main reasons to write this email btv :-) )
Marek
On 06/11/15 15:04, Stian Thorgersen wrote:
> 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(a)redhat.com <mailto:mposolda@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(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev