Marci

EOS650D, Baader Solar Film, Canon 18-250mm kit lens, ISO100 @ 1/640, F5.6

We're (still) using it fine with O365 SMTP configured old-fashioned stylee manually with Basic auth, rather than the newer "proper" intergration. **shrug**

OK - so, if you head to Bromcom QuickReports, domain to Staff Absences > add all fields and take it out to excel... what do the start and end times there show for the impacted records?

Vision odata’s been tanked for days, and part of the solution has seen data field types switch from datetime to datetimezone on the feed. Fairly sure all this is due to underlying changes being put in place for v2 rollout on both PartnerAPI and Vision oData endpoints, and shenanigans have occurred under the hood. Wouldn’t surprise me if all these things are related given this has taken place in the midst of various attempted fixes for the Vision outage approaching v2’s planned launch on 29th. Whether all of this has impacted the thirdyparty user soap api is anyone’s guess.

I've been wanting parity across the feeds for years. Back when we first switched in 2018, I developed everything based on CloudMIS feeds, (incorrectly) assuming whatever I designed for CloudMIS we could then just swap the oData endpoint out for Vision and it'd then work for bringing in multi-school/multi-year data (because there was no documentation around any of this and I hadn't yet been given access to the Vision feed). Ended up having to rewrite months of work due to this incorrect assumption. Table names, structures within those tables, and even the data-type of individual fields vary from feed to feed.

Yes, you can make a quickreport that takes out whatever data domain, and patch that in via live feed (get data > from web > paste livefeed URL for quickreport, accessible from reports list > select report > actions > livefeed). For Behaviour events... set QuickReport Data domain dropdown at top middle to "Behaviour Event Records", then for auto-refreshing direct from the livefeedURL, tick the "All Date Intervals & Filters" button, set the Date Interval on the domain to "Show All". Add whatever needed from the field list. The output of that is the equivalent of what we get from Vision - all BehaviourEventRecords recorded in the system for as long as you've been using the system. For exporting CSV archives for a specific timeperiod, set the Date Interval to the specific date range, export, and bring the CSV in from a Sharepoint repo. Don't use the "runtime" switch on anything that you'll be consuming direct via livefeed - you can't provide parameters on a livefeed request.

Roles & Permissions > Reporting > oData Admin Feed. That's about it. You can either access the feed in it's entirety, or you can't access the feed (as far as I'm aware). Without that ticked, users will get: With it ticked, they'll get everything.

"Old" Method is still working absolutely fine for us... we've never bothered changing to oAuth as last we tried it had to be linked up using a Tenancy Admin account, with no option to change the identity it then sent as.

They did. Recording is on Vimeo… COO section: 3m 26s to... CTO section: 7m 38s to... CIO section: 16m01s to end

You'd define that on your date table over in PowerBI... then the date of the attendance mark would determine wk1 or 2 from your attendance table's relationship with the date table.

This has been working for us for 8 years...

Agreed on all points, and likewise (well, my boss has) ^^^ (except we've been at it with them for 8 years, which means we started with old-oldUI. NewUI for us will be the third UI overhaul staff will have had to get to grips with, hence we're still on the middle-ground OldUI)

We use automated events (something along lines of screenshot below scheduled to run at an appropriate time after close of your p5 registers) to deal with this so no-one needs to do the actual sanctioning - system takes care of it, and staff have eyes on it via PowerBI report that refreshes itself.

By the looks of things they're subdomaining bits out... eg: CloudMis odata now gets syphoned off to misodata.* (this was put in place during the last round of 429s back in Nov I think) Bits of CloudMIS itself randomly get redirected to appsapi.* (this has started happening since the current mitigation was put into effect) ...gives them finer grained traffic shaping / resource provisioning etc rather than the one overarching set of rules / restrictions applied at cloudmis.* level applying to everything passing thru that front end request router, as well as redistributing the load in general. I suspect the knock on effect of this is impacting endpoints used by the mobile apps etc Same is happening within bits of CloudMIS eg: builtin reports all fail if you happen to end up on the appsapi.* URL via signpost-switching across schools as can't CORS across to the reporting engine at mis-reporting.* (workaround: logout, log back in, go direct to school in question. Pretend the signpost-switcher doesn't exist) Minification still fails on majority of generated css assetts and bloats them up to be larger than if minification was never attempted due to the debug output being written into the final delivered files (always has).

JS and CSS assets have been failing to minify server side and been delivered in full-fat form for at least 2 years or so. At a glance there were only ever a handful of actual image assets. Rest of the payload is either from XHR calls or fonts.