[SIMS] SIMS Behaviour Management Somewhat Flaky

[DavePriorHLS]

Hi all,

Bear with me, this is my first post

We have recently used the Behaviour Management function in SIMS to record and run our detentions. Works quite well, nice and easy to use, teaching staff see it as a positive replacement to the paper system.

However...

It appears that anyone can delete and/or define new Detentions

A bit of a drawback, to which there doesn't appear to be any easy fix. I've raised a requirement on CAPITA (1106-906831), but I need most of the civilised world to vote positively for this before CAPITA will consider looking at it. Interesting way of handling customer requirements

1 - can I ask you to vote for the requirement please ?
2 - has anyone found this problem and got a work-around that I can implement ?

Many thanks in advance

[creese]

1106-901225 Permission to delete a behaviour incident removed from Class Teacher.

1011-808436 Set permissions in Detentions so that only staff with selected permission can create or delete Detention Sessions

1006-726256 Remove ability for class teachers to be able to delete detention sessions

I could trawl back and find more similar requests. Sadly they are all ignored or swept aside

[Sivadam]

System7 allows you to clone the default groups, such as Class Teacher, and you can edit the permissions in these cloned groups.
These Groups are upgradebale via future releases. unlike in Sysman6.

So............... If the functionality does not suit (error or not!), then you can have your own Groups with Permissions tailored to the school!

[DavePriorHLS]

System7 allows you to clone the default groups, such as Class Teacher, and you can edit the permissions in these cloned groups.
These Groups are upgradebale via future releases. unlike in Sysman6.

So............... If the functionality does not suit (error or not!), then you can have your own Groups with Permissions tailored to the school!

Hi Sivadam - not sure how that helps me. Are you saying that there is a Permission I can set to do with creation/deletion of Detention records ? I can't find it - help please !

@creese - doesn't look good, but can I count on your vote pls ? Could you spread the word and maybe this time will be different ?

Many thanks

[creese]

@creese - doesn't look good, but can I count on your vote pls ? Could you spread the word and maybe this time will be different ?

Many thanks

I searched because I remember, vaguely, a discussion with Capita concerning this. Likewise logging.

We had an incident where a parent who was also a teacher was suspected of 'amending by deletion' a behaviour incident.

[vikpaw]

As creese says, it's not just detentions that suffer from lax security, the incidents themselves are not protected. I imagine it's all under the same umbrella, and there are equally as many change requests to give finer control over the behaviour editing.
Sysman7 doesn't change the underlying permission structure (as far as i know) so it's not going to add a Edit (own) level, which is what is required.
I will vote, but you get the feeling with change requests that -

Sadly they are all ignored or swept aside

, despite what people say about them being reviewed, when something this important (dangerous) is mentioned many times in multiple forums, it shouldn't need to go to a user review / vote. Someone high up should just get it fixed.

[DavePriorHLS]

@Vikpaw - Thanks for the vote, hopefuly we can get something done.

@All It does all sound a bit like the tail wagging the dog here - CAPITA are supposed tio be the suppliers here, and us the customer. I'm guessing that the formal route to CAPITA is via our respective LAs - is it perhaps time we put pressure on our contacts there, to put pressure on CAPITA to react more sympathetically (in fact, react at all!) ?

[creese]

@All It does all sound a bit like the tail wagging the dog here - CAPITA are supposed tio be the suppliers here, and us the customer. I'm guessing that the formal route to CAPITA is via our respective LAs - is it perhaps time we put pressure on our contacts there, to put pressure on CAPITA to react more sympathetically (in fact, react at all!) ?

The process in a nutshell is... a group of users (LA and Schools) meet in a room. The trawl through the Change Requests and discuss. They vote on those to keep. A second vote is taken to prioritise. Capita then decide if the voted requests are viable and do them based loosely on their priority and user priority.

All very democratic.

[DavePriorHLS]

@Creese Just so I understand; the Change Requests that are discussed - are they the ones that have had the magical 200 votes already ?

[creese]

@Creese Just so I understand; the Change Requests that are discussed - are they the ones that have had the magical 200 votes already ?

It's a very leaky filter system. Eventually getting an end result of a few changes that might happen.

A slightly tongue in cheek overview of the process, but fairly accurate.

[vikpaw]

It's a very leaky filter system. Eventually getting an end result of a few changes that might happen.

A slightly tongue in cheek overview of the process, but fairly accurate.

You'd think that rather than just the votes, a product manager would review them all, and also maybe a developer or two. Just to get a feel for what people think of the system. Things like this, which come up from time to time, should have all related CRs consolidated, so the vote count makes it worthy. Or if a product manager picks up on something that is more likely a bug or failure of workflow, then it can be acted on straight away.

It just seems it's way to easy to be told that something is not currently a feature and so needs a change request. I have a field that i can't access in my independent version of SIMS, it looks like an oversight, but rather than fix it, i have to lodge a change request and hope enough people have the same issue, find it and vote on it within a small enough timescale for it to be discussed at a meeting. Just shocking!

[creese]

You'd think that rather than just the votes, a product manager would review them all, and also maybe a developer or two. Just to get a feel for what people think of the system. Things like this, which come up from time to time, should have all related CRs consolidated, so the vote count makes it worthy. Or if a product manager picks up on something that is more likely a bug or failure of workflow, then it can be acted on straight away.

It just seems it's way to easy to be told that something is not currently a feature and so needs a change request. I have a field that i can't access in my independent version of SIMS, it looks like an oversight, but rather than fix it, i have to lodge a change request and hope enough people have the same issue, find it and vote on it within a small enough timescale for it to be discussed at a meeting. Just shocking!

I've been on a couple and the product manager was there. They have their list. So anything they have on their is taken off the final list on the day.

[vikpaw]

I don't get what you mean.
Also, do they review All CRs at these meetings or just popular ones?

[creese]

I don't get what you mean.
Also, do they review All CRs at these meetings or just popular ones?

Have you seen the list of change requests? There are not enough hours in the day to review them all. Add to that, a lot repeat themselves.

Put it this way, I've never created a change request. I occasionally vote for something very significant that I think from experience will reach the final list.

Capita have their agenda, the users their's. Guess who wins.

[Sivadam]

The most recent Software Development Consultation meeting I attended was the recent Nothern version of the SLG Consultation, run by the Product Manager. The summary of the views of the two meetings have been circulated to the participants for further comment/clarification and information should be published on SupportNet shortly. Seeing the views of the two different meetings demonstrates the exceedingly difficult job that Capita have in prioritising their development plans! I have many priorities, which I voice quite regularly, but so has every other user of SIMS. Obviously those priorities differ for each individual!
The number of votes on a CR is significant, but some less well supported ones are often prioritised. This can be as a result of the Capita staff understanding the issue in advance of a meeting. Or it could be pointed out by participants of the meeting why that particular CR should be a priority! And Capita Staff do listen! And I can vouch for the fact that they do react to the advice and requests of users!