[Solved] My Account access problem

3
I have a strange entity access problem with the standard edit My Account. If one user opens this form the person is able to change its password, but when another person opens this form the change password is greyed out and cannot be changed. At first I thought I made an error in the user rights. But after checking this is not the case. Both have the user role User. The user role User has access to Administration (I have not changed a thing in this module). And I checked the other roles these persons have and all roles they have extra they all have the checkbox Administration/User. The only strange thing I can see is that the standard form MyAccount in the properties the Navigation/visible for is set to none. This seems a bit strange because the form is opened (and this should not be happening or am I missing something about the security rules here). But even changing this to visible for User which in my opinion should be the standard for this form does not change the behavior. What else can influence the entity access of this property? (and I have checked the model with a collegue of my (Frans Verschoor) and we are both at loss why this is happening). [UPDATE] If I create a new user and give him the role of User everything works as should be. Now I strip a user who is not able to change the password of all roles and only give him the User role it still does not work. The user is not able to change the password. How can this be? [UPDATE2] Found it. I had an entity with the generalization administration account. In this module I had set the security on read only for certain roles. Never realized this also was then applied to the generalization. Regards, Ronald
asked
1 answers
1

Just guessing here Ronald. Depending on when your application was originally created, your user accounts may be defined in the Administration module, with an object of Account that is a specialization of the System/User object.

If your application is more recent, it may be defined in LicensePoolManager/Account which is also a specialization of System/User. If it is older you may have your user accounts defined in some other object that derives from the User object.

Could the difference that you are seeing be because one of these accounts was created directly in the System/User object (from the Administration...Users menu, while the other was created through the Administration/Account object. In the first case there would be no entry in the Administration/Account object (just a record in User), while in the second case the entry would exist in both the User and Account objects.

Your change password form may be using the Administration/Account object as the data source, in which case if would not work for one user, but would for the other.

HTH

answered