dafad_dew

Hi, Quick a about class charts and its reporting accuracy. For background, we have sanctions system in place, but sometimes a sanction has multiple reasons. Sorry, I only have limited experience of it's UI... I suspect teachers are pressing multiple buttons in the UI for the same sanction and it's being registered more than once for a pupil. This would obviously cause the reporting of these to be quite a bit out.... So, questions are: - is this easy to do in the UI? - if so, is there a way of preventing it? - how can I easily clean the data to get accurate reports? Thanks, Dd.

There are countless examples identifying "caching" as the problem, but caching is no more risky than any other data storage/retrieval. It's usually a step added on at the end to improve responsiveness or performance, and doesn't always go through the same rigorous tests. One of the benefits of a cloud based system is (hopefully!) reduced infrastructure costs. But you only get that benefit with multiple schools sharing infrastructure - which may well include databases and web front-ends/servers. Almost every step has to to verify that data belongs to the same organisation as the person logged in. And if there's one tiny piece of code where that check is missing, you can get data for another school back. Or data for every school! This makes these systems much harder to test properly, and it's extremely easy to slip up, particularly when adding new features. Expect to see more of this kind of stuff. This clamour for "cloud" MISs isn't always a good thing!

Looks to me like a very very carefully worded statement...! Look away, there's nothing much to see! "no access to any other data that was not on the homepage of the school's Arbor site." so the seriousness depends on what gets displayed on a school's homepage. Hmmmm..... The most worrying bit is that it was "caused by an internal release which incorrectly stored caching data". An "internal release" should be totally isolated from live, customer sites, so the main explanations I can see are either: - Their internal and live/production releases share components and/or data stores (Ouch!) and/or - Their release process isn't robust (another Ouch!) and/or - Their QA processes aren't robust (ditto) or... it wasn't really an "internal release" and this is just a play on words Wouldn't be surprised if this was down to a missing WHERE clause along the lines of WHERE School_ID = when getting data from the cache. Without it, it would show data previously cached for any school. And that's not a minor issue at all.