I'm hoping that someone else has encountered this issue. We are trying to identify the trigger of when this happens, but so far, we haven't been able to do so. The group that we are on CPS v 12.3 using RDP. This has occurred 3 different times and so far we haven't been able to correlate it to any changes of any kind, but a user, and it has been just a single user in each circumstance, will log into CPS in the morning to start work and get an error stating that they do not have any security. These have never been new users, but when you look at their profile in CPS, it appears that they are not in any security group, and they have no security to do anything. We have had to rebuild their profile in order to resolve the problem, but we'd be very interested in learning what may be triggering this behavior.
I'm very curious about this issue. I've been managing multiple AD-integrated CPS instances since around 2006, and never encountered this. We're also in an RDP environment.
If the affected user can log in, then gets a security error, do they at least have the Main Menu permission? I haven't tested this recently, but I don't believe a user can log in without the Main Menu permission.
Are you AD-integrated? My first thought is that the most likely scenario is a user account has unexpected permission to modify security privileges, and they are doing so. I have seen a lot of instances where CPS security is not in, shall we say, an ideal configuration.
Under the assumption you haven't checked this yet, you can check who can administer CPS privileges by going to administration > User and Resource Management > Users > Security > Security by Permission. Then in the permission list, go to Main Menu > Administration > Adminstrative Security > Set Security. That will display the security groups and users that are able to manage security privileges.
-dp
Have the affected users ever been set to Inactive? I had a similar case a few months back that support was unable to determine the root cause. We ended up setting the permissions manually for those users instead of using security groups.
When I check the last modified time for the affected users, it showed midnight as if it was part of some job but support insisted it was not.