Yes, this is another possible solution. For instance, you can throw an error in the overridden OnDeleting method of your user class descendant. Alternatively, you can handle the IObjectSpace.Committing or other suitable events to execute the same protection logic.

Thanks for sharing your real-life experience, Chris. Would you please clarify how you implemented this protection in your app for both cases: 1. when a user attempts to delete his/her account; 2. when a user was deleted by another user? The second solution is of the most interest for me. Thanks for your time in advance.

Hi Dennis, I'm not sure if these comments should fire an email notification, but at my age I do forget to check these things...

I'm not too sympathetic to users getting themselves into this situation, but I'll share what I've done for a product which does see use by more "challenging" users.

I've added an Appearance rule to hide the Delete action if the UserId == CurrentUserID() to protect from self-deletion.

I've also added a Validation rule that admin accounts can only be deleted by other admins. I think this was to prevent users deleting admin accounts and leaving the system without an admin account.

Additionally, my user class contains an enabled/disabled flag. So, there's another validation rule which prevents an admin account from being disabled if there are no other active admin accounts.

The combination of these 3 changes seems to have satisfied the client. I'm sure that there are many more permutations which will allow a user to lock themselves out of the application.

Ah - just spotted the "Notify me" checkbox.

Thanks for your extended answer, Chris!

Thanks for sharing your thoughts on this, Manuel. I would also greatly appreciate it if you elaborate more on your current solutions for both cases: 1. when a user attempts to delete his/her account; 2. when a user was deleted by another user. The second solution is of the most interest for me. Thanks for your time in advance.

Hello,

"2. when a user was deleted by another user."

There would be no problem if the XAF could store a actually logged users. This feature should be implemented first as a upgrade of the Security System. My customers always want to see who is actually working at the moment.
The simple check IsLoggedOn should be enough. It would by managed by appropiate events: OnLoggedOn, OnLoggedOff.
Another cool upgrade would be CanMultipleLogin. If the user is logged on one machine, he cannot log in on another one. Of course the administrator or another authorized user can manually logoff user or just set his IsLoggedOn property to false.

If we will have the possibility to define the user's login state, we can solve the nr.2 problem easily.

Thanks

On a tangent.... we've extended our application to contain UserSessions, so logging in creates a UserSession instance, logging out releases this. These are simply classes which collect login/logout time, device, user info. So, notionally you could use this to see active users.. provided they log out correctly.

We also use the same construct for our WCF server/clients which are consumed by Windows Mobile clients. These allow management to relate users to devices, infer where they are physically and what they're doing, and send messages... this is for a Warehousing system.

Once you're gathering the usage data you can also analyse load/usage.

@Chris: Thanks for commenting on this one too. BTW, do you currently handle cases when applications were shutted down via the Task Manager or lost electricity (e.g. with some sort of a timer/service that updates user records with no recent activity)? I remember we were also discussing similar solutions with other users (e.g., https://www.devexpress.com/Support/Center/Question/Details/S30919/), but they were handling simple cases too.

Short answer, yes Dennis.

Longer answer... our application infrastructure supports the notion of batch jobs. The batch jobs can do a number of "things" like run script code, or predefined batch processes (with parameters).

We can run the XAF application using command line parameters. One of these parameters is /RunCommandBatch=BatchId. When the XAF application is run in this way, it starts up, executes the batch process, and logs any errors etc, returns an int to Windows re. run success and shuts down.

Then, we use Windows Task Scheduler on a server to periodically run batch processes e.g. hourly, weekly, daily.

One of these processes (within a batch job) will expire orphan UserSessions.

The usersessions are essentially treated as tokens in our WCF calls, once they're expired they need to be regenerated in order to receive webservice responses to requests.

You could probably accomplish the same using a WorkFlow service.

Much appreciated, Chris

I'm with Dennis on this - it's a complex issue when you add in multiple platforms, people wanting to run multiple instances on the same machine, RDP/ICA with load balancing, Windows Hibernate and Sleep functionality, people working in different Time Zones from HQ etc - quite a minefield.

Am I correct that in the client application, you manage this with the default security permissions (Delete = Deny)? I meant the Delete Action is unavailable in the MyDetails and other Views by default or these user views are unavailable completely?

no, default sec. is allow all (we still use old sec. system) - but the views are not available (not user listview, no mydetails view). also, the delete action is not available in general for all objects - we allow delete only in listview - so an user would not really have the possibility to delete himself or others.

That's clear, thanks! And very safe I guess:-)

The use-case I had to deal with was the Admin user deleting themselves (above)... and then blaming the software.

The project concerned is almost "shrink-wrap" software where the user base seems hell-bent on making life awkward.