Repeated "Update to helper components available" Notification Emails

[foigus]

Ever since AutoPkg .50 went live, it appears that AutoPkgr is emailing a notification about that release with every AutoPkgr run.

Note I also received a single notification I received about the actual AutoPkg AutoPkg recipe, so it doesn't appear to be that recipe that's the issue.

[franton]

Confirmed. I am seeing this every time AutoPkgr is scheduled to run on my work machine. That's three now for every six hours it's run.

[eahrold]

@foigus, @franton
This is the current expected behavior since it's simply a routine run at the end of each schedule, but maybe we should handle it with a little more finesse. It'd easy enough to set it up to only send notifications once each new version.

I sort of like being nagged to update, but can see how that's not for everyone.

So once notification per new version sound like a better approach to you?
Votes - Thoughts?

[franton]

Hi Eldon,

That sounds perfectly acceptable to me. However I normally have AutoPkgR’s emails go into their own email folder. I think I need to revise my email rules as the emails sent in this instance went straight into my inbox instead.

[eahrold]

Because you were filtering by subject string?

[franton]

Yes. I'd check and confirm but it's a national holiday for the next five days starting today so no access to the office. I guess i'm putting up with this for a few days!

[foigus]

Possibly consider emailing every couple days or once a week? I have AutoPkgr running three times a day fwiw.

[eahrold]

@foigus good call, I like the idea of once a week even better.

[futureimperfect]

@eahrold I like this idea too, although it should probably be customizable.

James Barclay

On Jul 19, 2015, at 09:34, Eldon Ahrold notifications@github.com wrote:

@foigus good call, I like the idea of once a week even better.

—
Reply to this email directly or view it on GitHub.

[eahrold]

@futureimperfect What are you thinking for options? Include an every time op?

[futureimperfect]

Yeah, or default to notifying every run and allow users to tune how often they get notified for any given update.

James Barclay

On Jul 19, 2015, at 12:10, Eldon Ahrold notifications@github.com wrote:

@futureimperfect What are you thinking for options? Include an every time op?

—
Reply to this email directly or view it on GitHub.

[homebysix]

I agree customization would be great, but let's default to once per week. We want "maximum annoying" to be opt-in, not opt-out. :-)

[eahrold]

Agreed. Here's what I'm thinking now...

• One time only
• Once a week (default)
• Once a day

[eahrold]

Where should we park the UI Elements?

It seems like a "Notification" type, but could be considered a "Schedule" type (and there's more room there).

[homebysix]

I agree it should be in the Notifications tab, and that's tricky because the Notifications tab is running out of space. We could do something like this, with "Configure..." leading to the once/daily/weekly options mentioned above.

But that adds an extra click and obfuscates a setting that should be visible at a glance.

Or we could just make the window bigger:

I'm on the fence but leaning towards the Configure button as a short term solution and dynamic tab sizing as the long term solution.

[poundbangbash]

If the options are just going to be once/daily/weekly would a popup menu in place of the Configure button make sense?
If it’s going to be able to be customized more like the Schedule tab options then the expanded window would be fine or dynamically expand it when the box is checked. For me, I expanded the window larger than default to see the recipes and repos on the other tab. Since the window size stays that big between tabs there is extra room on my setup, but of course others may vary.

I’d also suggest either having a hover/popup explaining what “component tools” are or including that in the verbiage “…to component tools (e.g. AutoPkg, git, munki tools) are available…”

-Eric

On Jul 20, 2015, at 11:57 AM, Elliot Jordan notifications@github.com wrote:

I agree it should be in the Notifications tab, and that's tricky because the Notifications tab is running out of space. We could do something like this, with "Configure..." leading to the once/daily/weekly options mentioned above.

https://cloud.githubusercontent.com/assets/7801391/8781496/3946c25c-2ec4-11e5-891f-7a8397964534.png
But that adds an extra click and obfuscates a setting that should be visible at a glance.

Or we could just make the window bigger:
https://cloud.githubusercontent.com/assets/7801391/8781592/d47f6f26-2ec4-11e5-9ced-29aaed3291c0.png
I'm on the fence but leaning towards the Configure button as a short term solution and dynamic tab sizing as the long term solution.

—
Reply to this email directly or view it on GitHub #379 (comment).

[eahrold]

I just pushed a branch. I opted for the popup for both space and because it kept the code more concise.
I agree we should probably do something more specific with the language, I'm open to suggestions...

https://github.com/lindegroup/autopkgr/tree/integration-frequency

[homebysix]

This looks good! I'll test it out.

You can ignore my branch. Yours is better.

[eahrold]

And one last detail as to the current "expected" behavior.

If the only thing available is an integration update, it will report based on the set frequency, however if some other element is causing a report to get sent, such as a new download or an error, the integration update information will be included reported.

Does that sound sensible?

[homebysix]

That sounds sensible to me. I'll clarify that in the UI.