----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 12 March, 2015 3:48:46 PM
Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things
On 3/12/2015 10:41 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Thursday, 12 March, 2015 1:57:21 PM
>> Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things
>>
>>
>>
>> On 3/12/2015 1:40 AM, Stian Thorgersen wrote:
>>> I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not
>>> referring to the claim mapping work you've done, it's something
else.
>>>
>>
>> I opened two jiras. One, a "claim validation" jira and another
>> broker->Usermodel mappers. That should have covered what 311 is not
>> doing.
>
> Not IMO. We really need to have something that defines how the internal
> user profile looks like, attribute validation, what attributes are
> required, etc.. Also, I really don't think we should require users to
> modify registration screens and admin console if all they want to do is
> for example to add a DOB field.
>
I disagree. They will be editing these pages anyways to get the look
and feel they want. As i said over and over, you'll just be re-creating
HTML within the data model.
As I've said several times they don't need to change the pages to modify the
l&f that's the whole purpose of CSS. Have you looked at cengarden that I sent you
links to? Have you looked at the sunset theme example I've added?
I have no idea what you mean about re-creating HTML within the data model. What I'm
talking about is something like
A user profile is defined as something like:
Name Type Required Validation
--------------------------------------------
First name string required ...
Last name string required
Email string required
DOB - date - optional
Address address
We then populate the registration field using those values. We can have templates for how
to display individual types. That means users only have to edit a small snippet of html
instead of editing and maintaining the whole registration template.
>>
>>> Before we can do a release we need to make sure that database migration
>>> works (I know they don't atm as social providers and social links are
>>> lost). We also need to add transformation of JSON exports and
>>> representations so older versions can be imported into 1.2.0.Beta1.
>>>
>>
>> Not sure, but json imports from older versions should be backwards
>> compatible. We're just doing migrations via json export/import right?
>
> No, we migrate the database directly.
>
https://github.com/keycloak/keycloak/blob/master/misc/UpdatingDatabaseSch...
>
>>
>>>>
>>>> I'm going to try and close existing bugs and implement features
needed
>>>> for
jboss.org guys over the next 2 weeks as well as test out master to
>>>> make sure things still work.
>>>
>>> With regards to
jboss.org guys we shouldn't just add features because
>>> they
>>> request it. Take for example KEYCLOAK-1045, which was easily solved with
>>> we already have. Another one is KEYCLOAK-1051, which I think is a
>>> horrible
>>> idea.
>>>
>>
>> I don't want to just add features either, but some of their things are
>> valid...i.e. finding out if a user is logged and who they are without
>> doing all the token stuff.
>
> That's exactly one of the things that are not necessary, I've added a POC
> that uses keycloak.js, which they where happy with. See KEYCLOAK-1045 and
>
http://stianst.github.io/jbossorg/index.html.
>
I'll take a look, but IIRC there was a different issue described (not
1045), where a static home page shouldn't have to perform a full login
and obtain a token just to know whether or not a user is logged in and
who they are.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com