-
Notifications
You must be signed in to change notification settings - Fork 44
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
FR: Conditions #24
Comments
@fuzzylogiq why not make a first start script that includes a recon, which will update jamf pro (or whatever) that this machine is updated? https://github.com/kc9wwh/macOSUpgrade is a good starting point for something like that. |
It's not that I want to control when the initial notification goes out, I know I can do that with management, it's just that once a notification has been scheduled by yo_scheduler, it is then offered to users who log in unless the whole queue is cleared. So user A gets message, upgrades the machine to Sierra, then user B logs in and the message to upgrade to Sierra comes from the yo_scheduler queue, even though it's irrelevant now. |
Oh OK, I get you. Its a feature I am not using with yo, in fact, didn't even know you could queue stuff like that :) |
@fuzzylogiq give me an idea of what sorts of things would be useful. The scheduler currently handles my use cases, but there are lots of ways people may want to deliver notifications, so the sky's the limit. I'm looking to add some scheduling features for the next release. |
How hard would it be to have conditions to evaluate before sending a notification, kind of like the predicates that Munki uses?
I ask because I wanted to put out a Yo notification to users inviting them to upgrade their OS, but I don't want cached ones to go out to users who log in after the OS has been updated.
The text was updated successfully, but these errors were encountered: