It would be useful (to me) if RapidSetup could clear the user limit state when the user limit is disabled.
Right now, I have to configure and enable it, then disable it to clear it.
I just tried setting up a user limit. I had it in the enabled and triggered state. Disabling it resulted in the trigger state going low. Is that not the behavior you are asking for?
Perhaps I am misunderstanding the question. Are you trying to disable it before it is enabled/configured?
I am confused how it could be triggered before that state.
Perhaps you could provide some example code showing how you are configuring your limit and when you want to disable it?
Sorry it took me a few days to get back with you. Thanks for the reply.
The limits I’m working with are all one-shot. The peculiar state in which I cannot disable them is when they’re already disabled (because the user limit fired), though they are still triggered. I’d like to be able to disable/clear them with one action.
No worries.
For the time being I recommend continuing as you were (Enable then disable it).
We will take the recommendation under advisement but also feel it is important to protect the latching behavior of one-shot limits.
All I would like to be able to do is clear the triggered state of a user limit that has already triggered. In order to clear it now, I have to re-enable it first.
You know better than I do whether such a feature would turn out badly for your customers, but I wouldn’t mind listening to an explanation as to why allowing someone to clear the triggered state of a disabled user limit would pose compatibility or other problems.
If implemented and used properly such a feature should pose no compatibility issues.
The reluctance to immediately implement this feature has more to do with the required behavior of clearing the state being technically possible currently through re-enableing. Additionally we see some benefit in the current system requiring a bit more intentionality to clearing one-shot limit.
1 Like
As for my closing arguments, I would like to point out that in the recent past I’ve had to add some configuration parameters to RapidSetup in order to re-enable the user limit before I could disable it again. I think this was in part due to bugs/misbehavior of the APIs (e.g. some fields were listed as “invalid,” and so I had to put something in there). It was not impossible or hard. It was just a hassle that I didn’t see the value of.
Also, if someone wanted only to clear the triggered state of a user limit without re-enabling it (and potentially having it re-fire), it seems like reasonable behavior to want to merely clear the triggered state without risking a re-fire (or requiring a few other clicks, selections, etc.).
Thanks for the info, @nikolas. I trust you guys to do what’s best. I’ll even let you get in the last word. (-8
All good points.
We will revisit adding this feature once some of the more urgent software changes have been completed.