CadlaM (13th January 2009)
In August we installed a new server and, with SIMS Support help on-site, moved the SQL database and SIMS over to it. Before moving we did the Aug update.
Later one of our admin people noticed that when trying to edit the Father's details of a pupil (but OK with Mother's details) SIMS crashed. See attached screenshot. She could still enter a Father's details from scratch.
Eventually realised that crashing was the rule for most users, and that only one user COULD edit Father's details. A user wih many more permisson groups.
Worked With Capita Support but they were unable to reproduce the fault. Once they found that we had one custom permisions group they were unable to provide further answers.
By giving one of the admin users ALL the Group Permissions that the successful user had, then stripping them out one at a time, I found that we can now only do this particular type of edit with "Fees Manager" in permissions.
Anyone had an experience like this? No users had to have this permissions group to edit before the Aug Update/move.![]()
Well if the great Capita can't fix it, I'm not sure I can.
I've just found KB73960 (attached)
If that doesn't work. Perhap delete the student and recreating them. This will ofcourse open a whole can of worms. (The students history etc)
PS: Stupid vBulletin\EduGeek admin\mod not allow me to upload .html
PSS: SORRY, SORRY, SORRY Oh great and powerful EduGeek Admin\Mod!! lol
We had this issue and after running the 'Validate Memberships' routine as a sysadmin all was fine.
I think I came accross this kb in my search for a match to the error. Superficially it has same message.
Not quite what I am getting. The user who can edit, gets to edit all and any Father's details. But all the users who can't, can't. No details of any Father of any pupil on the system can be edited until the illogical group is applied.
Work around is OK, as its mainly one person who does all the edits, but it's not right.
![]()
If you'd like to identify yourself to me, I will see what we can do to help you. User defined permission structures should not cause this issue. Try assigning one of our standard permissions to a person and see if it still occurs.
CadlaM (13th January 2009)
Interesting comment about 'Validate Memberships', I think I have only run it as the user(s) with the problem. not as sysman. Thanks, worth a try.

I heard about this exact problem, and it depended on the route taken to change the details.
So if you are in a students record and go to their contacts and try to edit, then it crashes out.
If you go via the link for contacts (little man in front of an envelope) and then search for the Father and then edit it is fine. Is that the workaround you are using?
Sometimes the route taken does make a difference, and i suppose different permissions apply.
It reminds me of the time when in order to see staff timetables you had to to have the next of kin permission. somehow, the system was drawing that data out even though it wasn't required and thus caused a crash.
I guess it will be sorted in a future update.

We had a similar error which was due to human error - no finish date at pupils' last school... hence the kids were in two places at once!
Crashes here too when editing several pupils in a row.
I've started to lose access to a growing number of modules despite being in the system manager group.
I also can't get it to not show certain staff details without crashing. Aparently I need to allow the group to see the staff timetables. If only there was a staff timetables permission.
Tried it that different route in. Works that way. Another workaround that allows me to turn off fees permissions for the admin user.
Now I just have a training issue![]()

I'd appreciate thanks via the 'thanks' button (hint hint).
CadlaM (13th January 2009)
@ Vikpaw - Thanks for the info, but where is the Thanks button?
But your message has reminded me......
Capita may yet have a fix. was slated for Nov update but missed the cut-off date.
Nov 30 2008
"Hello Colin
The fix has passed testing and is awaiting authorisation. This means it should go out in the December release baring any major complications. "
@ PhilNeal - Probably more thanks to you, But I'll wait for the December update that the fix was due in before confirming
(8¬)>

CadlaM (13th January 2009)
There are currently 1 users browsing this thread. (0 members and 1 guests)