The current implementation of audit log for authentication could result in DB becoming too large, so we should implement a simple @scheduled job to delete the content which are older than 30 days
@deepu105 : I am willing to tackle this one. 馃槃 . I was thinking, should we give the user to choose the schedule duration (30 days or whatever they want) or is it sufficient to keep the 30 days hard-coded for now?
Adding the duration in the property file is better IMO.
The same case is also should be for removing not active users, currently, it is hard-coded to 3 days.
IMO, best is to have an admin screen where admin has the option to change property values at runtime.
@deepu105, @pmverma : Wonderful, I'll start working on this with configurable values for removing non-active users and audit log deletion. 馃槃
No need to choose anything lets just set it to 30days by default. It's trivial to change if needed in code. Maybe we can make it property in the spring boot application.yaml files
A property would be in the case of microservices and centralized configuration
Configurable is best. Many enterprise users have to keep logs for years, and not everyone has off-site duplication or Splunk despite being "enterprise."
I've created the pull request. Please feel free to let me know if you see any issues or anything else needs to be added. 馃槃
@SudharakaP maybe you should consider squashing your commits into one single for a simpler history when merged.
@gmarziou : Thanks, but maybe I am understanding this wrong but isn't it more appropriate to squash merge after the pull request is reviewed?
Well maybe but I always do it this way and this is how it is recommended in our contributing guide
@gmarziou : Okay, I'll do this starting now; thanks for letting me know. 馃槃 But what's the best place to have a discussion about this (any any other questions) with everyone? Do you guys have a public channel where all JH members/devs participate?
Here is an example where Vishal did it and you can see it several from several forced pushes, github manages it nicely even though some review comments are no longer attached to their initial commit
Here is an example where Vishal did it and you can see it several from several forced pushes, github manages it nicely even though some review comments are no longer attached to their initial commit
Thanks for the example; got it now 馃槃
Do you guys have a public channel where all JH members/devs participate?
Not fully public: https://groups.google.com/forum/#!forum/jhipster-dev and https://gitter.im/jhipster/jhipster-dev-team
Fully public but with very few dev team members: https://gitter.im/jhipster/generator-jhipster
Thanks much; the problem with the first one is I cannot post (I think it's only for members); the second one, I can post because there's a bug in gitter; but it's supposedly private; so I don't think it's appropriate. But that's fine I'll post in the public gitter I guess. 馃槃
@gmarziou : I've squashed it as you suggested. Please let me know if you see any further issues. 馃槃
You squashed by you kept the commit messages unedited, so it contains a lot of duplicates. I would suggest you amend the commit message. Ideally when you squash, you also edit the message to summarize the final state to describe what you did and to remove intermediate steps.
@gmarziou : Sorry about that, I've done another squash with the comment properly updated. Let me know if you see any issues. 馃憤
@gmarziou : I've just pushed the change for retention-period as well (https://github.com/SudharakaP/generator-jhipster/commit/a13bb4ae8e7583bb2232694d69ea07f8446cfd5d#comments) 馃槃 Let me know if there's any other issues; even if they are nit-picky. 馃槃
Looks good to me. 馃憤
@gmarziou : Thanks :+1:
@DanielFran : If you see any other issue please feel free to let me know; I cannot get the travis or any azure tests pass since the jhispter-framework pull request needs to be build first.
And on that note, I've found time and time again there's some Azure test or Travis tests that fails for invalid reasons. Maybe this is too much to ask, but would it be possible for me to get access to restarting the tests when that happens again so that I don't have to wait until someone restarts ? :stuck_out_tongue_winking_eye:
You don't have to wait for someone, just close and re-open your PR, it'll restart CI.
@gmarziou : Thanks. :+1: Didn't think about that :smile:
Although that runs all the tests which takes quite a bit of time and most times it's just one check that fails on me. :smiley_cat:
Most helpful comment
You don't have to wait for someone, just close and re-open your PR, it'll restart CI.