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(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Geir Ole H. Stevning