[keycloak-dev] Supporting date/time of consent in the model

[Geir Ole Hiåsen Stevning]

I like that solution, with 2 timestamps for create and lastUpdated + the
admin view. I'll have a look at how much work and how fast I can get a PR
up.

On Tue, Sep 13, 2016 at 2:13 PM, Marek Posolda <mposolda at redhat.com> wrote:

> +1
>
> Will be also good to display timestamp in admin console IMO.
>
> The question is if it's sufficient to put date on UserConsentModel as in
> scenario like:
> - User authenticates in time1 and gives consent to client "foo" with 2
> roles and 2 protocol mappers
> - In the meantime admin grants new role "bar"
> - Another login in time2, user will need again to consent the newly added
> role "bar"
>
> So should be timestamp set on time1 (when consent was created) or on time2
> (when there was last update) ? Or should we rather have 2 timestamps
> ("createdDate" and "lastUpdateDate" )? Another possibility will be the
> timestamp on every role and protocolMapper, but this looks like quite an
> overhead.
>
> So maybe 2 timestamps for create and lastUpdate and display both in admin
> console in "consents" tab table will be sufficient?
>
> Marek
>
>
> On 13/09/16 10:51, Stian Thorgersen wrote:
>
> I've got no issues with us adding it. If you add it to the DTO-like
> objects and implement support for both JPA and Mongo as well as add tests
> for it I'd be happy to accept a PR. Would also need updates to the
> Liquibase changelogs to add any required fields (assuming that's required).
>
> Marek - do you have any comments?
>
> On 13 September 2016 at 10:42, Geir Ole Hiåsen Stevning <
> gostevning at gmail.com> wrote:
>
>> Hi!
>>
>>
>>
>> We have a use case where we need to know the time for when an End-User
>> has given consent. Would it be possible to add a Date-like field in either
>> UserConsentProtocolMapperEntity, UserConsentRoleEntity or
>> UserConsentEntity, as we are using the JPA provider.
>>
>>
>>
>> Furthermore, propagate this field in the corresponding DTO-like objects
>> as UserConsentModel etc. Doing this will probably mean that additional
>> providers will need to populate the field, i.e. mongo.
>>
>>
>>
>> Is this something that you guys think is a good idea? I would be able to
>> create a PR if you would like that.
>>
>> --
>> Geir Ole H. Stevning
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>


-- 
Geir Ole H. Stevning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/b42963b9/attachment-0001.html