djrscally

Oh sweet, thank you.

Err, no. All schools have to pay a fee, it's just the level of fee in slight dispute. The ICO told me the lower tier so that's what I've paid.

Bump again! The original closing date passed but we'll be extending it shortly.

I'm pretty certain you can tell Facility and Progresso apart now. EDIT: So you get this for Progresso: Advanced Learning Progresso 18.5.6.0 2018.1.2 ISTR that Facility has a separate value.

Bump for exposure

I am leaving my current post which is therefore going to be open, and we need to replace me asap (so if you're interested, don't wait till closing day to apply please!!) It's a great place to work, extremely supportive and involved SLT and colleagues all round. The role allows a lot of creativity and autonomy in trying out and bringing in new systems and processes, with a real variety of work. I've enjoyed myself here for 4 and a half years. http://www.southfieldgrange.org.uk/_site/data/files/users/10/484CD6BE96EC6D871B17383DDB96974A.pdf https://www.tes.com/jobs/vacancy/data-manager-bradford-1142563 EDIT: Feel free to PM me if you want to talk about the role; I'll send you my email.

They haven't been for a few years now.

Sure but it's definitely enough to qualify as personal information and fall under the GDPR, albeit with a crazy low risk of it actually happening and impact if it does.

It depends who you are though. You and I obviously couldn't but someone who knew the school a little like the parent of one of the kids in the class probably could.

It depends what they're calling small. The DofE will suppress results where there's less than 5 students for that very reason, so if they're calling a group of 5-10 kids small then sure I'd buy that.

Oh good grief.

Ah cool, sorry I misunderstood. Fair enough I suppose. Why are the council's refusing to accept them out of interest?

I think that the adequacy of TLS itself is well established (and all Office 365 / GalaxKey / Egress do is host a page that displays the message to which the recipient connects via TLS), but there are operational problems associated with relying on the standard TLS mail transmission that mean I wouldn't be comfortable with that. You cannot rely on your staff to use that site to check a recipient is safe. They are highly unlikely to do it imo, and even if they do if it reports that it's not safe they'll likely just send the mail anyway. If a recipient is safe, that doesn't mean their server is set up to send mails over TLS so you might receive replies sent in the clear. There are a ton of problems with relying on TLS mail imo. It is my firm opinion that this is the problem of those organisations, not our problem. We shouldn't downgrade our security to accommodate their crappy practices. EDIT: although I appreciate that isn't helpful when you need to send something to them and can't!!

Bromcom was definitely there last year; I specifically sought them out to have a play.

Sure; ask away. Docs here if you haven't seen them: https://progresso.docs.apiary.io/ What emails were you sending out of curiosity?

You can't natively as we have no access to the database. Historically I've used the API or scheduled reports to dump data into a reporting database and run them from there.

I think most folks are following some adaptation of the IRMS retention schedule, which is on Page 37 of this document: https://cdn.ymaws.com/irms.site-ym.com/resource/collection/8BCEF755-0353-4F66-9877-CCDA4BFEEAC4/2016_IRMS_Toolkit_for_Schools_v5_Master.pdf

Err yeah bit weird. I would have expected it to show #Error to be honest since CInt("R") is not a valid operation. I think there are reports in Progresso that document the shared datasets. Look for ones called AL_tmp_* - if you run those it returns a list of the fields and I think has the data type there

Alright; so start from a fresh copy of that report and do the following: 1) Add a new parameter called "Phase" with labels "Primary" and "Secondary" and whatever values you like as long as they're distinct; I'll go with "P" and "S". 2) Select "Phase" in the list of parameters and mash the Up arrow on the UI above the Parameters list until it's higher than "LearnerList" (This deals with the forward dependency thing) 3) Edit the "PR_Learners" dataset, go to Filters. Add a new Filter and set the Expression to =Switch(InStr(" 1 2 3 4 5 6 ", Fields!Year_Code.Value) > 0, "P", InStr(" 7 8 9 10 11 12 13 14 ", Fields!Year_Code.Value) > 0, "S", True, "X"). Set the Operator to "In". Set the Value to [@Phase] 4) Edit the "Attribute Learners" Parameter, go to "Default Values". Set the Dataset to "PR_Learners". Set the Value field to "LearnerID" When you run the report you should now be able to select either "Primary" or "Secondary" or both and have only the appropriate Years come through. Be aware this does break the "Learner Attributes" parameter though, so strip that out (unless you actually want both, in which case it gets a bit more complex). If you want more granular control just call it "Year" instead of Phase and make the Expression in Step #3 simply be [Year_Code] and the Value be [@Year].

So you want two versions; one showing just Primary kids data and one Secondary kids data? The simplest method is to replace the filter on Learner Attributes. You could add Dataset filters to the PR_Learners dataset to filter to the right Years for Primary / Secondary, and then edit the "Attribute_Learners" parameter to draw its default values from the LearnerID fields of PR_Learners instead of PR_Learner_Attributes. If you want to maintain the ability to filter on attributes in addition to Year it's slightly more complicated; let me know if that's the case.

Forgot to reply before, sorry.I think everything about this scenario sounds like a nightmare to be honest. You are right of course that generally speaking software running in a production environment should not expose PII in the logs. I guess the reason I'm saying I'd approach this differently is that in my experience, lots of 3rd party software like this places personal data on disk in some fashion. For example, Groupcall's Xporter has a ton of services running through it to push data into various applications after taking it from our MIS: all of those put PII of some description into .xml files on our server. So, you might have a bigger problem than some software negligently dropping out data in logs; some of those extractors might be doing it deliberately, particularly with Wonde involved given their software is a competitor to Groupcall's Xporter and presumably works similarly. I would really really think about this one again. Given you have access to that data, I'd say you need to formally count as a data processor for it.

It doesn't matter whether you WILL. It matters whether you CAN. If you're the server administrators then your data processing agreement with the controller needs to cover ALL the data that touches that server at any point ever, and your potential access to it is not unauthorised. Now if you actually went and read it, for no good reason, that's possibly a different matter. Just like you can potentially read the SIMS data but won't because you're all upstanding people. If you want to be really diligent about it, go back to the "separate accounts for each supplier's program" thing and have all their stuff run from C:\users\supplier instead of Program Files. Limit your staff's logins to the server so they don't have access to those folders unless they need to elevate to Administrator for some reason. This really only changes the perception though IMO. EDIT: Also: You mean they can just rdp to the server and install something?

Oh sorry I misread you, but you're saying that YOU are unauthorised? I thought your point was the other services on the server could have access to the data. Mind you; if you're an administrator on the server, I think you have access to the SIMS data anyway via methods like this: https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/connect-to-sql-server-when-system-administrators-are-locked-out?view=sql-server-2017 If you're an administrator on the server, you surely have access to everything on it. Isn't your agreement with the controllers written in a way that accounts for that? Just wanted to add; fully agreed.

I was more thinking a different user for running than installation.

I think that at this point this is probably more the school's problem than Contact Group's. The excess of data in logging is daft and you're right to call them on it, but exposing some personal data in logs for a limited time is probably legit and the fact that personal data is available in plain text on a server is not a breach of data protection principles provided only people authorised to see that data can access it. If anyone connecting to the server can access anything on it (and particularly if the account that's running a particular processor's software can access data they shouldn't) then that's a problem with their user and process controls. I think that the schools ought to be setting up their server such that Tom's programs, Dick's programs and Harry's programs have their own user account to runas, and that those accounts should not have access to the directories of the other people's programs.