Closed sfadschm closed 3 years ago
If I understand this correctly, this would be for cases when an active user updated a template, like from an admin dashboard or something? I'm not a big fan of the Model affecting the Session data, but I understand the concept. If a controller or something is updating a template on behalf of a logged-in user, why wouldn't it just update the user's setting as well?
If I understand this correctly, this would be for cases when an active user updated a template, like from an admin dashboard or something?
Exactly 😄
I think you're right about keeping the session out of the model and rather handle that in the controller.
However, I would like this to be shipped with the package, as it could cause some confusion after updating a protected
setting, if the developer himself did not handle updating the session as well (example: me).
Thats just my opinion however, if you feel this should rather stay with the developer to handle, thats fine 😄
I like the concept, but I think this is not how I would like this handled. Because the model event only gets the ID(s) it means another database call just to deal with the session, which could be handled promptly by the developer wherever the original database call is made. I don't know if this will be a common case (a logged-in user modifying a template), but a compromise might be looking into wiping all the session values using the cache with deleteMatching()
- that would need some more research though.
but a compromise might be looking into wiping all the session values using the cache with
deleteMatching()
This is basically how I am doing it at the moment, just that there does not seem to be a removeMatching()
method for the session unfortunately, but right know, a simple loop unsetting all settings-
-keys does the trick.
Lets leave this with the controller/developer then. Thanks for the input!
When updating a template in the database via the Model/Entity, the cache and templates storage is clear by
clearTemplates
. However, if the value of the changesSetting
is already stored in the session of the current user, it will persist until$ttl
is over.While I don't think we can reset the changed
Setting
in the sessions of all active users, we can at least do it for the current user who submitted the changes.