Best practice to "deactivate" users


we use kirby to create a school website. Hence many pupils are registered as users. As they change classes over time and regularly leave the editors team we’d like to deactivate these users rather then delete them to show the correct authors even when they are not part of the editors’ team (anymore).

What is the best practice to handle this kind of requirement?

What i could think of is:

  • add another attribute “inactive” to each user
  • change role into the new role “inactive”
  • leave everthing as is, which get’s very cumbersome over time

Appreciate your suggestions :slight_smile:

Best, Thomas E.-E.

I’d probably change the role of these users to a role with no panel access (so that these users cannot log in to the Panel anymore, which wouldn’t be possible with an attribute).

However, keep in mind that over time you will pile up useless users, which could also result in a performance impact when searching or filtering users if the number increases over a certain limit.

Then there is also the question if you should really keep user data over an endless time frame, if students have long left the school.

What information do you show for each user? Just the name?

thanks for your quick answer :slight_smile:

What information do you show for each user? Just the name?

merely, it’s their current class and the given name.

An alternative could be to store this data about the pupils in pages in the content folder. Then you can delete the actual user and keep the user page.

Hi @lukasbestle ,

thanks for this idea, however i am not quite sure if ii got it correctly. You mean there should be a kiind of profile page per user and rather than referring to the user we would refer to this profile page? In this case we’d have to keep the user information and the profile page in sync, right? Or would you replace the user with the profile page once a user got deleted?

Best, Thomas E.-E.

I assume you currently use user blueprints to store the user data like the class and given name directly in the account. This approach is very useful if the accounts are kept, but breaks as soon as a user gets deleted.

So I’d recommend to move these fields to profile pages per user. The page UIDs can match the usernames in site/accounts so that existing references in other pages (author field etc.) still work. Once all data has been migrated, you can delete the fields from the user blueprint and update your templates to use the profile page instead of the user object (a custom field method like toProfile() can be helpful so you can simply replace all toUser() methods with toProfile()).

So to summarize, I’d recommend to migrate everything to profile pages and not just the users you want to delete. With the profile page setup, you can delete any user at any time.

If you want to automate the creation of the profile pages, you can use a user.create:after hook for example.

Which route you go (special user role without Panel access or profile pages) is not important in the end, both ways will work and each have their own advantages and disadvantages.

ok, thanks for this detailed explanation. I think this could be a good way to solve my issue.

In addition to your changes i would have to change the panel links to “user profile” page and also the users view, right?

You can certainly do that for an optimized user experience, yes. But it’s not required for the setup to work. The profiles would move to the site area and can also be managed directly from there.