+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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev