warning message for disabled dates too soon to work

Carey Black
5 hours ago
https://github.com/Internet2/grouper/blob/d4203497033c8e7cb814fcd07be6115172823fc9[…]eware/grouper/app/loader/GrouperDaemonEnabledDisabledCheck.java
keeps track of when it last cached data.
Which is set by
https://github.com/Internet2/grouper/blob/d4203497033c8e7cb814fcd07be6115172823fc9[…]eware/grouper/app/loader/GrouperDaemonEnabledDisabledCheck.java
queryTime = System.currentTimeMillis() + (1000L * GrouperLoaderConfig.retrieveConfig().propertyValueInt("changeLog.enabledDisabled.queryIntervalInSeconds", 3600));
3600 is the default value if it is not set to something in the config stack.
So it defaults to a value of "now"+ 1 hour. ( and stored in mills )
And
https://github.com/Internet2/grouper/blob/d4203497033c8e7cb814fcd07be6115172823fc9[…]eware/grouper/app/loader/GrouperDaemonEnabledDisabledCheck.java
checks the "now time for the job running" vs the 'lastQuery' value.
If now is after the last "max time value looked for to build the cache" then
https://github.com/Internet2/grouper/blob/d4203497033c8e7cb814fcd07be6115172823fc9[…]eware/grouper/app/loader/GrouperDaemonEnabledDisabledCheck.java
would be called with a new "max time value looked for to build the cache"
ELSE
It only looks at the cached data
https://github.com/Internet2/grouper/blob/d4203497033c8e7cb814fcd07be6115172823fc9[…]eware/grouper/app/loader/GrouperDaemonEnabledDisabledCheck.java
at least that is how I am reading it. :slightly_smiling_face: HTH.

Jeffrey F Williams
5 hours ago
That behaves much more like I was expecting! Depending on where you want that behavior to land, you may need to slide your duration window back a bit to allow for propagation. I had a membership with a 3 minute window and it came in around the 15-20s mark and left around the same mark 3 minutes later.
That helps a lot! I'll make a note to update the doc for that piece as well! Thanks!

Chris Hyzer
17 minutes ago
there is overhead for that. we werent really assuming people would have a lot of 3 minute duration memberhips... if there are adjustments we need we can do that :slightly_smiling_face:

Carey Black
15 minutes ago
there is overhead for that.
Fast, Accurate, Cheap.... Pick two.

Carey Black
11 minutes ago
But from a "users perspective" ( lacking any knowledge of the back end details ) :
expiration dates can be set to the second.
which implies that, in Grouper, memberships could expire "any second of the day"
propagation to external systems MIGHT be understandable as "delayed" due to multiple jobs running at different times.
The internal caching that the configuration setting of changeLog.enabledDisabled.queryIntervalInSeconds does is not documented nor understandable without reading the code.
So this is a complete blind spot for a "user".
And for the record Jeffrey is not a "user". He has used Grouper for more than a while and it was not clear to him at "first glance". ( Nor me till I went poking at the code. ) (edited)

Carey Black
4 minutes ago
@mchyzer

If there is a "unspoken rule" with expiration dates, then maybe the UI should warn the user about the value they are setting on the membership/group when they make than change?
AKA: value is < changeLog.enabledDisabled.queryIntervalInSeconds and cache was last gathered at some time .
WARNING: This time can not be currently accommodated. The earliest possible value is (do some math in the background) bla . Would you like to use that value instead?

Chris Hyzer
1 minute ago
it will expire to the second, but it is not assumed you will make an expiration date in the future less than an hour away (or whatever the default threshold is)
New

Carey Black
< 1 minute ago
assumed you will make an expiration date in the future less than an hour away
Then that could be the definition of the warning message.