[keycloak-dev] Supporting date/time of consent in the model
Geir Ole Hiåsen Stevning
gostevning at gmail.com
Wed Sep 14 06:38:26 EDT 2016
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
On Tue, Sep 13, 2016 at 2:13 PM, Marek Posolda <mposolda at redhat.com> wrote:
> 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
> So maybe 2 timestamps for create and lastUpdate and display both in admin
> console in "consents" tab table will be sufficient?
> 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:
>> 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
Geir Ole H. Stevning
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the keycloak-dev