User soft deletion

[parlt91]

What does this PR change?

Remove functionality for users to 'hard' delete users from the webUI API and spacecmd.
Deactivate should be used instead to serve as a soft deletion mechanism that can be reverted if needed.
This way references to the deactivated user e.g. Recurring Actions will be kept if the user is disabled (as opposed to deleted).

The UserFactory.deleteUser() function was preserved since we use it to clean up API tests
See: BaseHandlerTestCase.tearDown()

The stored procedure to delete users from the db will also be kept since we still want to able to delete users when deleting an organization.

GUI diff

Before:

After:

• DONE

Documentation

• Documentation issue was created: TODO

• Will add documentation changes once this PR is approved

• (OPTIONAL) Documentation PR

• DONE

Test coverage

• Unit tests were adapted

• Cucumber tests were adapted

• DONE

Links

Fixes https://github.com/SUSE/spacewalk/issues/21035

• DONE

Changelogs

Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository

If you don't need a changelog check, please mark this checkbox:

• No changelog needed

If you uncheck the checkbox after the PR is created, you will need to re-run changelog_test (see below)

Re-run a test

If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:

• Re-run test "changelog_test"
• Re-run test "backend_unittests_pgsql"
• Re-run test "java_pgsql_tests"
• Re-run test "schema_migration_test_pgsql"
• Re-run test "susemanager_unittests"
• Re-run test "javascript_lint"
• Re-run test "spacecmd_unittests"

[github-actions]

Suggested tests to cover this Pull Request

• allcli_sanity
• srv_mainpage
• srv_user_api
• srv_sync_channels
• proxy_cobbler_pxeboot
• srv_distro_cobbler
• proxy_as_pod_basic_tests
• srv_cobbler_distro
• srv_first_settings
• srv_wait_for_reposync
• srv_rename_hostname
• srv_cobbler_profile
• srv_monitoring
• srv_maintenance_windows
• srv_user_configuration_salt_states
• proxy_branch_network
• srv_cobbler_buildiso
• minssh_salt_install_package
• min_deblike_monitoring
• srv_power_management
• min_salt_mgrcompat_state
• allcli_software_channels_dependencies
• srv_content_lifecycle
• minkvm_guests
• srv_task_status_engine
• srv_patches_page
• srv_logfile
• srv_docker_cve_audit
• srv_enable_sync_products
• srv_create_repository
• min_empty_system_profiles
• min_ansible_control_node
• srv_reportdb
• min_retracted_patches
• srv_add_rocky8_repositories
• srv_organization_credentials
• allcli_reboot
• min_bootstrap_ssh_key
• srv_manage_activationkey
• min_deblike_salt_install_package
• buildhost_docker_build_image
• srv_custom_system_info
• minssh_bootstrap_api
• srv_advanced_search
• srv_scc_user_credentials
• min_rhlike_ssh
• allcli_update_activationkeys
• srv_datepicker
• min_salt_openscap_audit
• srv_change_password
• srv_user_preferences
• srv_cobbler_sync
• min_salt_install_with_staging
• allcli_config_channel
• min_salt_software_states
• srv_channels_add
• min_bootstrap_api
• min_bootstrap_reactivation
• min_rhlike_monitoring
• min_rhlike_salt_install_package_and_patch
• min_config_state_channel_api
• buildhost_osimage_build_image
• srv_group_union_intersection
• allcli_action_chain
• min_salt_pkgset_beacon
• buildhost_bootstrap
• srv_virtual_host_manager
• min_cve_id_new_syntax
• min_deblike_ssh
• srv_check_channels_page
• srv_dist_channel_mapping
• min_config_state_channel
• srv_change_task_schedule
• min_salt_minions_page
• srv_delete_channel_with_tool
• srv_notifications
• min_deblike_remote_command
• sle_ssh_minion
• srv_salt
• min_custom_pkg_download_endpoint
• allcli_software_channels
• sle_minion
• minssh_move_from_and_to_proxy
• srv_users
• srv_push_package
• min_docker_api
• srv_check_sync_source_packages
• srv_sync_products
• allcli_system_group
• srv_handle_config_channels_with_ISS_v2
• srv_delete_channel_from_ui
• srv_restart
• srv_power_management_redfish
• min_bootstrap_negative
• min_activationkey
• srv_clone_channel_npn
• min_rhlike_salt
• min_salt_formulas_advanced
• srv_handle_software_channels_with_ISS_v2
• srv_manage_channels_page
• min_salt_migration
• min_recurring_action
• min_salt_minion_details
• min_salt_lock_packages
• min_deblike_openscap_audit
• srv_menu_filter
• srv_check_reposync
• min_check_patches_install
• min_virthost
• srv_power_management_api
• min_move_from_and_to_proxy
• min_project_lotus
• min_config_state_channel_subscriptions
• srv_payg_ssh_connection
• min_timezone
• min_salt_user_states
• srv_activationkey_api
• minssh_ansible_control_node
• min_deblike_salt
• srv_docker
• buildhost_docker_auth_registry
• min_deblike_salt_install_with_staging
• min_cve_audit
• min_rhlike_remote_command
• srv_channel_api
• proxy_retail_pxeboot_and_mass_import
• min_bootstrap_script
• min_rhlike_openscap_audit
• srv_docker_advanced_content_management
• srv_salt_download_endpoint
• proxy_register_as_minion_with_script
• min_salt_install_package
• srv_menu
• min_monitoring
• min_change_software_channel
• min_action_chain
• srv_osimage
• minssh_action_chain
• srv_create_activationkey
• min_salt_formulas
• allcli_overview_systems_details
• srv_disable_local_repos_off
• min_ssh_tunnel

[agraul]

Before looking at the code, I have a fundamental question: Is "soft deletion" in line with regulations such as the GDPR?

So far I'm under the impression that Uyuni needs to have a way to delete user data and not just hide it, but I'm not law expert.

[wweellddeerr]

Apart from the regulation issues raised by @agraul, which I agree are relevant, the changes in Java LGTM.

[cbbayburt]

Also not an expert but to my knowledge, we're allowed to keep such data as long as it has a use for a functionality that serves customers' needs according to GDPR. I believe this is a valid case.

[cbbayburt]

I don't know if this has been discussed before, but from the UX perspective so far I imagined "soft delete" would be completely transparent to the user. That is, we would still have the "Delete" function in the GUI/API, but effectively that would hide the user from all UI instead of removing the data completely. This would be separate disabling.

They might miss their "Delete" button :D

Any thoughts @parlt91 @admd ?

[agraul]

Also not an expert but to my knowledge, we're allowed to keep such data as long as it has a use for a functionality that serves customers' needs according to GDPR. I believe this is a valid case.

GDPR includes a right to have your personal data deleted (Article 17). Of course it's not applicable in all cases (e.g. a company can't delete an invoice with your name for X years because it has to store them for bookkeeping purposes), so the question is: Is there a situation in which a Uyuni user can demand deletion of their user data from the Uyuni "hoster"? I think the answer is yes (e.g. you stop using a hosted Uyuni service and want your data deleted).

None of us is actually an expert in law, and we can spend hours trying to argue how to interpret the GDPR or other, similar, laws. Instead I propose we keep a way to delete/anonymize user accounts. Maybe just a table for admins of deactivated accounts that has a button: delete deactivated user Joe. Anonymization would also work (removing first/last name, changing username), if that's needed for auditing of Uyuni itself.

[cbbayburt]

I'm not sure if any of this applies to us at all since all the data in question is actually hosted by the user. We're not keeping any data in our domain.

They can exercise their right to delete all data basically with sql DELETE statements :)

[cbbayburt]

I think @admd can ping the Legal team to address any concerns, but I don't think we need to proactively spend any extra effort on this.

[agraul]

I'm not sure if any of this applies to us at all since all the data in question is actually hosted by the user. We're not keeping any data in our domain.

Right, we just provide the software that stores the data in question. It might not be our problem legally since we don't offer hosted Uyuni ourselves, but to me that's not good enough. I don't want our users to have to fight our product just to do what they are lawfully required to do.

They can exercise their right to delete all data basically with sql DELETE statements :)

Aren't we striving to be API-first? Is this a serious proposal to ask Uyuni operators to run delete statements because we want to drop something from the API?

[admd]

Personally, I don't think this is a problem honestly as we are not storing any data at our end as Can has pointed out but I will clarify with the legal team anyways.

Removing user completely gets us in different problem. There is requirement to keep track of all the actions that are performed by a user on the server. If we do allow deletion of user, we lose track of all actions that user has performed. Now again I am not sure how should we handle this ideally.

I will clarify this with the legal team and will get back to you on this one.

[srbarrios]

Personally, I don't think this is a problem honestly as we are not storing any data at our end as Can has pointed out but I will clarify with the legal team anyways.

Removing user completely gets us in different problem. There is requirement to keep track of all the actions that are performed by a user on the server. If we do allow deletion of user, we lose track of all actions that user has performed. Now again I am not sure how should we handle this ideally.

I will clarify this with the legal team and will get back to you on this one.

If I may, a good approach would be to decouple sensitive user data from the identifier that we need, to track the actions of that user.
In other words, have some anonymization procedure that allow us to delete user data that can impact on GDPR rights, but allow us to keep having some identifier for our historical data.

[github-actions]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[cbbayburt]

Still waiting for a final answer from Legal.

[github-actions]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 10 days.

[github-actions]

This PR was closed because it has been stalled for 10 days with no activity.