Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Legal update option issue #12

Closed
ghost opened this issue Sep 21, 2020 · 3 comments
Closed

Legal update option issue #12

ghost opened this issue Sep 21, 2020 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@ghost
Copy link

ghost commented Sep 21, 2020

When I want to update my terms of use, I use the legal update option. However, this only works once. When I want to make an update again, the legal update does not require approval from users, it does not work.

@luke- luke- added the bug Something isn't working label Dec 10, 2020
@luke-
Copy link
Collaborator

luke- commented Dec 10, 2020

@yurabakhtin Can you please check on occasion why the reset button does not work? It is important that the "Legal Update" tab is filled with text, but it still doesn't work for me.

@yurabakhtin
Copy link
Contributor

@luke- As I understood you tell about the red button "Reset confirmation" on the page /legal/admin/page?pageKey=terms.
I see the button removes records only from DB table contentcontainer_setting for all users, i.e. it makes to again accept new terms for all users.
But when a user clicks "Accept" this code also memorizes this action in Sessions - https://github.com/humhub-contrib/legal/blob/master/Events.php#L107. And for checking firstly the flag is used here https://github.com/humhub-contrib/legal/blob/master/Events.php#L76. It means the user will be requested to accept new terms only after next log in action when Sessions will be cleared. I tested and it works as I described.

If we want to request new/reset terms immediate even if a user already accepted previous/old terms then we should remove the flag from Sessions and keep only in DB, but I think the current behaviour is normal, and it seems the cache in Sessions was implemented for optimization.

@luke-
Copy link
Collaborator

luke- commented Dec 10, 2020

@yurabakhtin Thanks for looking at this. Let's leave it then, the cache is very important.

@luke- luke- closed this as completed Dec 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants