There’s also the amended or additional information that can be published on the event by the Sqn before publishing.
A fair point.
Another question/scenario…
- I create a Wing level event (perhaps with some outline details in the description to give early visibility) and units push it to the portal.
- Later down the line I wish to add a formal calling letter
- A bit later I add JIs
So on and so forth…how does the system deal with that? Do the cadets get notified when new stuff is added?
When I add stuff to the ‘files’ tab on a Wing event, can I still choose the ‘cadet portal’ tick box and they will automagically appear in the cadet view of the event?
They shouldn’t be published in the first place.
This is a little selfish isn’t it? Surely the Cadets should choose what they wish to do but you’re hiding an event from them that they may wish to attend away from the unit?
And what do we think will happen in this scenario? An interview with their sector commander and then nothing… the Cadets still lose out.
Instead we have staff emailing out chasing OCs to publish stuff making more work anyway as the OC then not only has to respond to the emails but then also publish the event.
That’s exactly my point.
Staff only events shouldn’t be published to Cadet Portal - They will however be on SMS - so if everything from SMS were to get pushed automatically to Cadet Portal then the cadets would be able to see them.
That is down to the Wing staff to take up with those few OCs who aren’t pushing the events.
They’re going to be in the minority so it is no reason to adopt a ‘sledgehammer to crack a nut’ approach of pushing everything and making more work for the rest of us just because a few can’t toe the line.
In particular the “more work” in your scenario is more work for the “crusty OC” who didn’t pull their finger out and advertise it to their cadets in the first place… and frankly I couldn’t care less about their work load.
If the squadron has a long-standing commitment they may choose to prioritise that over some other squadron’s event. That is absolutely their call.
We have binned attendance at major wing events for reasons such as this and, while we may try to accommodate both, if we have promised well in advance to assist with something then we are honour-bound to do so.
Interesting view… not one that would be taken well in most Wings.
Not sure you understand unit commanders that well, I suspect there will be a large chunk of units not publishing stuff and requiring chasing. As @redowling says, stats would be useful.
You’re making a decision for the Cadet in not even advertising it though, there is nothing to say any one will sign up but the lack of advertisement on the portal is limiting it’s power.
People will still see events happening via Facebook/Twitter etc anyway and then find their own way to go and ignore the squadron event, this happens. So why not just advertise everything?
I equally couldn’t care less how that view is taken by any Wing or indeed by you.
We’re talking about the hypothetical OC who doesn’t bother publishing events to their cadets - They wouldn’t end up with more work if they did the decent thing in the first place. So why should I care? It would be extra work entirely of their own making; and their workload doesn’t affect me in any way.
This is how these things work… Everyone says “This is what would make my life easiest…” and then the people developing the solution look at the big picture and choose the best compromise.
That may very well be the case - but the extra work load should be on those units; not on the rest of us who are doing it right!
SMSv5 and ACTO10 are making great leaps in empowering OCs, but suggestions of bypassing the squadron’s control of how it runs just undoes a lot of that good work.
Which email address is it going to?
Please god, not the OC for absences.
Please.
As an absolute priority
It will need to be - it is the only email address that we can guarantee will be in use!
The ideal would be for each Sqn to select to which address absence notifications are sent.
I’d quite like to catch sight of them as the Adj, and I dare say a Trg Off might like them too… However if it were a case of wanting to ensure they’re seen then I’d have thought that sending them to the generic account would be the best option.
That being said, it’s only for information as whoever is entering the register for that night will see them anyway.
I do think that the ability to see a “look ahead” of all absences already entered would be most useful.
We currently maintain a list of planned absences and I’m regularly looking it when finalising training - over the Summer holidays in particular.
Would be interesting to hear from @james_elliott if that is truly how it went or if there is something else driving the lack of ability to automatically publish Wing/Region events.
It is already there, with a summary on the dashboard and more details if you follow the questionmark
I’ve never had a cadet file an absence so I have no idea if it actually works though.
I don’t really care about cadet absences - they are all free not to turn up if they choose.
Getting the staff to tell me when they aren’t available if a much bigger problem.
You may see it as a “lack of ability” others would look at it as a conscious decision towards best practice.
Brilliant!
I’ve not had cause to use it yet, having only gone live yesterday.
Indeed they are, but I certainly like to know in advance if possible. It would reduce the number of times I have to change the plan at 5 minutes notice because half the group I was expecting have all gone off on a school trip or such.
I’m not saying the ability to remove the functionality of hiding an event. Just that the default should be to show the event and if a unit wishes to they have to go in and hide it.
Perhaps we could have a vote - and then all those people who’d like it to be the default can spend their free time hiding all the unnecessary staff courses, &c from everyone’s cadets on behalf of the rest of us.
Or whoever created the event just doesn’t tick the button for it to be advertised in the cadet portal…
That might work for some events, but perhaps I misunderstood your idea that all events get pushed to the portal.
Do we perhaps have three threads of discussion going on here?
One which says “everything should go to portal by default” (which is where I came in a while ago);
One which says “everything which is manually pushed to the portal bypasses Sqns” (perhaps what you are saying?); and one which says “leave it as is, where Sqns manually push”.