Deployer definable backend for ToU acceptance date
Description
Environment
Activity
I don’t know the context value/etc. offhand, but modulo the details I guess a trigger could help with it. (ETA: I guess from eyeballing it, it probably is the flow ID so that’s likely correct, which is helpful.)
We’re probably not going to get the API in place to access these records for this version but I can repurpose the request into that and it’s absolutely on the agenda to do, not just for this one use case.
There is also an undocumented but supported StorageService access REST API in the code already, it’s just that it requires knowledge of the storage layout, which the enhanced API is meant to avoid the need for.
I’d rather not mess with a custom storage implementation.
I think the alternative pull method is probably the better approach.
Maybe a stored procedure to trigger off of inserts / updates to context = 'intercept/terms-of-use'
?
@Liam Hoekenga Before I spend time on this, I need to clarify, I have no practical way to change the flow other than to “add” something. I can make it call a function that will have to understand some fairly involved state information in the format we’re managing it, but it will also have to invoke a storage service operation (and by definition it can only “get” the existing consent records from that StorageService).
I’m starting to think this isn’t really helpful and that I would instead advise the more heavyweight solution, which is a custom StorageService implementation you’d have to build for your needs, or the alternative a pull model where we just expose an API to query for specific user records on demand.
Another option here, or in parallel, is that we know we need an API to expose consent storage, so a pull model for the external system that needs the data could be used, but I suspect it’s more practical here to push it since the pull side wouldn’t really know which users to query.
My recollection is that the TOU design is pretty centered on the consent contexts and the storage around that, so I think we “just” add a callout to invoke code to run when acceptance happens, to give people the additional signaling.
There is the more aggressive suggestion, which is to say if you want to do more with the data, build a dedicated StorageService and wire it up for these use cases, and you can make your plugin do anything you want it to, but that’s obviously a Java development task, not lightweight.
We have a local flow that is basically a ToU-style flow. We need to store the acceptance date in LDAP instead of the shibboleth storage backend. We would like to migrate to something more standard - we could probably use the ToU flow or the Warning intercept if we could store the acceptance date in a location of our choice.