I'm not quite sure what GREED means by giving a permission breaks something else but it is much easier to view and change the permissions for a group. And they are introducing the concept of Capita providing a 'template' group, eg Class Teachers, which can then be cloned and permissions altered. It is then saved as a custom group.
I was on the testing yesterday as well and came away quite pleased with what I had seen in System Manager 7 and also relieved that we don't use SLG here as the problems with parent users and contacts seems to be a major one.
SysMan6 used to cause issues in the past but it has been pretty stable for the past couple of years. It just would not do everything that it ought to do.
The issue of Parent/Contact DB Users has been around since SLG was released (and maybe even with its predecessor).
System7 is able to resolve these issues!
@34 - cloning groups has always been possible, unless they are making it easier. You've always been able to make your own group, then add a pre-defined role, and remove the bits you don't want, or add them as the case may be...
Vik, the idea of classifying the Capita supplied groups as a template group is to stop the problem whereby users, having modified one of the existing groups, had any changes they had made overwritten by a SIMS upgrade. All cloned groups will become custom groups so will not be affected when the the upgrade updates the template groups. I should have made this clearer in the original post.
Yes, mostly what Sivadam said is what I meant, but it is good to know that has settled down recently.
Oh and Mike, I notice we are getting festive again!?
[EDIT: Before I get a negative rep, I am asking the question, not encouraging arguments as was previously noted when I asked! :/]
Festive? Maybe others didn't think so ..............
Hmmmmmmmmmmmm! One wonders where all that posting went ............. And why ............ ?
@34 - i notice somebody on SupportNet state that for a cloned group, based on a template group, that when there is a system upgrade makes a change to the template group, this change will propogate to the cloned group. At least that is what i understood. Is it that, perhaps, that you were referring to?
I still don't think it's a great feature, as the idea of cloned/custom groups is that you want to control the permissions, not find that something is added automatically. Plus where those permissions are dependent, it could cause a problem. I have had occasions when a permission has been added such as access to homepage panels, and they wouldn't work until i manually added them, however i was happy with that, as it meant i was aware of the change, and could choose to apply it or not.
I'd prefer a bit more clarity in the permissions, and the linking, and perhaps some detailed notes on any changes that occur during updates.
If anyone can clarify further that would be helpful..
Until Capita support custom groups my feeling is they should be withdrawn completely (Of course it would be much better if Capita did support them) I'm sure this will get raised at the second UAT session tomorrow which I am attending.
Please raise the issue at the session tomorrow. Custom groups should be supported (i.e. they shouldn't go wrong) although we can't help with groups that you have created and tell you why they aren't working. Crashes are a completely different matter.
Exactly my point splatthecat, so please do raise it. That's why i would like some more detailed notes on changes that are made, as i can't see that a blanket upgrade to a template and thus it's child clones is helpful. Especially if it's going to add / take away functions, it could completely overwrite the purpose of the cloned group.
There's debate going on in SupportNet at the moment about access to Next of Kin details, and it's very troublesome.
I think anyone that uses custom groups should just be told that it's at their own risk. I'm happy to manipulate as required. I doubt very much the changes will block much that is already working, it's more likely just going to restrict access to some new functionality.
Some permissions issues are complex, such as the need to have permission to view Next of Kin details for staff, in order to view their timetables, even though it doesn't show the NoK in the timetable! This is an old example, so it most likely fixed now, but you get the idea. Things like that can cause an unknown error / crash which can be unexplainable.
It would be good to have a change matrix for the permission structure at each upgrade. Not just the perms spreadsheet, much more granular. That way, anyone wishing to take advantage can see simply what has been added (or removed) and where. Then we'd be able to troubleshoot our own issues. At the moment i think the blanket answer is that we can't be helped as it's too complex, and this is right, especially considering how long it takes on the current sysman to just load the full list of permissions (couple of minutes for me.)
Good Luck you guys. I am sure you will enjoy it!
Don't forget to ask for the retention of the Backup routine - for us Sysmen that may wanna produce a backup for SupportNet and UAT without having to rely on the Tekkies having to use Solus! Yep! I raised it last week!