Erase organization command in server CLI by touilleMan · Pull Request #12172 · Scille/parsec-cloud

touilleMan · 2026-02-09T12:57:10Z

No description provided.

AureliaDolo · 2026-02-09T13:06:27Z

+  encrypted workspaces metadata (e.g. content of folder, list of blocks for each file version).
+- A blockstore (e.g. S3) containing the blocks (i.e. encrypted pieces of data that compose the files).
+- On top of that, each Parsec client having access to the organization has an encrypted local database
+  containing a copy of the certificates, metadata for the workspaces its has access to, and a subset


Suggested change

containing a copy of the certificates, metadata for the workspaces its has access to, and a subset

containing a copy of the certificates, metadata for the workspaces it has access to, and a subset

AureliaDolo · 2026-02-09T13:11:23Z

+
+   Blockstores have their own backup strategy. Typically AWS S3 allows for a bucket to
+   have an history so that a data removal can be cancelled.
+   You should pay attention to this to ensure the blocks have actually been removed.


Do we expect them to be removed from the history too ?

The goal here is to permanently erase all data from a given organization, so we expect the administrator to remove the history.
However this is not Parsec responsibility since blockstore configuration is specific to the administrator needs (see #12172 (comment)).

AureliaDolo · 2026-02-09T13:12:10Z

+organization using the local cache (e.g. creating a new file in a workspace or
+reading an existing file that is in cache).
+
+To prevent the users from accessing the local cache, the local configuration and data should be manually removed:


by the user themselves ?

This can also be done by an administrator that has remote access to the machine. Here we don't specify how things should be done but what should be done.

I'd rephrase it like this:

Suggested change

To prevent the users from accessing the local cache, the local configuration and data should be manually removed:

The local cache can be safely erased by manually deleting the local configuration and data for the device having access to the organization:

IMO we should add a note or warning to explain how to identify which device is linked to the organization (device id is displayed in the "My Devices" when logged-in... maybe we should consider displaying it in the Home page as tooltip or detail button ?)

Actually, in other sections of the docs we suggest using the CLI for that, e.g.:

The <DEVICE_ID> mentioned below refer to the device used to access the
organization. You can find out which is your device ID by running:

.. code-block:: bash

parsec-cli device list

AureliaDolo · 2026-02-09T13:15:43Z

+
+.. warning::
+
+   This operation cannot be undone. Make sure you have a backup of any data you may need before


nit: maybe add the command to make a backup in the warning message ?

Again, the administrator is responsible for the backup strategy, so we cannot provide a one-size-fits-all command here (typically "backup any data" may refer to do a PostgreSQL snapshot and storing it on cold storage, or it may refer to simply have a user start a Parsec client and copy/paste the files still needed)

There is already a section describing how to make a backup, we should link to it. See my next comment/suggestion.

AureliaDolo · 2026-02-09T13:17:57Z

+
+.. note::
+
+   After erasing an organization, it is possible to create a new organization with the same name


What would be the expected error on the client side if they haven't deleted their local data and a new organization with the same name is created ?

If their parsec client would just look offline that may be confusing if the same entity re creates an organization and expect to enroll the same people.

The client will get an error complaining the organization is not found on the server (even if a new organization with the same name is created, since they don't have the same root verify key)

I've added a word about this in the note 👍

⚠️ I think we should move up this whole note from the step 1, maybe to the first or second section.

Otherwise one may think that it is OK to create an org with same name just after step 1 (postgresql), before step 2 (blockstore cleanup).

IMO, regardless of Parsec internals, the erasing procedure should be treated almost as a" transaction", step 1 to 3 should be performed as a whole before attempting to create a new organization with same name.

AureliaDolo · 2026-02-09T13:20:20Z

+        "- No trace of the organization will remain, so it will be possible to re-create another organization with the same name."
+    )
+    click.echo(
+        f"- The organization's blocks won't be erased from the blockstore, you should instead manually remove the {display_bucket_path} top level directory from it."


Suggested change

f"- The organization's blocks won't be erased from the blockstore, you should instead manually remove the {display_bucket_path} top level directory from it."

f"- The organization's blocks won't be erased from the blockstore, you should manually remove the {display_bucket_path} top level directory from it."

mmmarcos

Some suggestions regarding the docs, mostly about wording or rephrasing.

I didn't review the code.

mmmarcos · 2026-02-10T13:52:28Z

+Where & how the data are stored
+-------------------------------


Suggested change

Where & how the data are stored

-------------------------------

Where is the organization's data stored?

----------------------------------------

mmmarcos · 2026-02-10T13:55:26Z

+- A PostgreSQL database containing the certificates (e.g. user/devices/workspaces) and
+  encrypted workspaces metadata (e.g. content of folder, list of blocks for each file version).
+- A blockstore (e.g. S3) containing the blocks (i.e. encrypted pieces of data that compose the files).
+- On top of that, each Parsec client having access to the organization has an encrypted local database
+  containing a copy of the certificates, metadata for the workspaces it has access to, and a subset
+  of the blocks (depending on local cache configuration).


Suggested change

- A PostgreSQL database containing the certificates (e.g. user/devices/workspaces) and

encrypted workspaces metadata (e.g. content of folder, list of blocks for each file version).

- A blockstore (e.g. S3) containing the blocks (i.e. encrypted pieces of data that compose the files).

- On top of that, each Parsec client having access to the organization has an encrypted local database

containing a copy of the certificates, metadata for the workspaces it has access to, and a subset

of the blocks (depending on local cache configuration).

- A PostgreSQL database containing certificates (e.g. users, devices, workspaces) and

encrypted workspace metadata (e.g. folder contents, block list for each file version).

- An S3 blockstore containing the encrypted file blocks.

- On each Parsec client having access to the organization: An encrypted local database

containing a copy of the certificates, workspace metadata it has access to, and a subset

of the encrypted file blocks (depending on local cache configuration).

mmmarcos · 2026-02-10T14:04:18Z

+When no longer in use (or for legal reason) an organization can be erased from the Parsec server.
+
+In practice this means:


Suggested change

When no longer in use (or for legal reason) an organization can be erased from the Parsec server.

In practice this means:

When no longer in use (or for legal reason) an organization can be erased from the Parsec server

following these steps:

mmmarcos · 2026-02-10T14:06:21Z

+1. Removing everything (certificates & metadata) related to the organization in the PostgreSQL database.
+2. Removing the blocks from the blockstore.
+3. Removing the remaining data from the clients.


I'd use "delete" (or erase) since "remove" may indicate persistence.

Suggested change

1. Removing everything (certificates & metadata) related to the organization in the PostgreSQL database.

2. Removing the blocks from the blockstore.

3. Removing the remaining data from the clients.

1. Delete certificates & metadata from the PostgreSQL database.

2. Delete the encrypted file blocks from the blockstore.

3. Delete remaining local data from Parsec clients.

mmmarcos · 2026-02-10T14:08:43Z

+Step 1: remove from PostgreSQL
+------------------------------


I'd make these steps (1, 2, 3) subsections of "Erasing data"

Suggested change

Step 1: remove from PostgreSQL

------------------------------

Suggested change

Step 1: remove from PostgreSQL

------------------------------

Step 1: Delete certificates from PostgreSQL

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

mmmarcos · 2026-02-10T14:32:50Z

+
+.. note::
+
+   After erasing an organization, it is possible to create a new organization with the same name


⚠️ I think we should move up this whole note from the step 1, maybe to the first or second section.

Otherwise one may think that it is OK to create an org with same name just after step 1 (postgresql), before step 2 (blockstore cleanup).

IMO, regardless of Parsec internals, the erasing procedure should be treated almost as a" transaction", step 1 to 3 should be performed as a whole before attempting to create a new organization with same name.

mmmarcos · 2026-02-10T15:13:29Z

+Step 3: Clients cleanup
+-----------------------


Suggested change

Step 3: Clients cleanup

-----------------------

Step 3: delete local data from Parsec clients

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

mmmarcos · 2026-02-10T15:22:48Z

+For this reason, an end-user is still able to use his Parsec client to work on the
+organization using the local cache (e.g. creating a new file in a workspace or
+reading an existing file that is in cache).


Suggested change

For this reason, an end-user is still able to use his Parsec client to work on the

organization using the local cache (e.g. creating a new file in a workspace or

reading an existing file that is in cache).

For this reason, users are still able to use the Parsec client to work on the

organization for actions relying on the local cache such as importing a new file

or reading an existing file that is in cache.

mmmarcos · 2026-02-10T15:31:09Z

+   - config: ``$XDG_DATA_HOME or $HOME/.local/share/parsec3/<device_id>`` (e.g. ``/home/alice/.local/share/parsec3/e68b7131394749a4bbd279bd087e6ae6``)
+   - data: ``$XDG_CONFIG_HOME or $HOME/.config/parsec3/libparsec/devices/<device_id>`` (e.g. ``/home/alice/.config/parsec3/libparsec/devices/e68b7131394749a4bbd279bd087e6ae6``)


Suggested change

- config: ``$XDG_DATA_HOME or $HOME/.local/share/parsec3/<device_id>`` (e.g. ``/home/alice/.local/share/parsec3/e68b7131394749a4bbd279bd087e6ae6``)

- data: ``$XDG_CONFIG_HOME or $HOME/.config/parsec3/libparsec/devices/<device_id>`` (e.g. ``/home/alice/.config/parsec3/libparsec/devices/e68b7131394749a4bbd279bd087e6ae6``)

- config: ``$XDG_DATA_HOME`` or ``$HOME/.local/share/parsec3/<device_id>`` (e.g. ``/home/alice/.local/share/parsec3/e68b7131394749a4bbd279bd087e6ae6``)

- data: ``$XDG_CONFIG_HOME`` or ``$HOME/.config/parsec3/libparsec/devices/<device_id>`` (e.g. ``/home/alice/.config/parsec3/libparsec/devices/e68b7131394749a4bbd279bd087e6ae6``)

mmmarcos · 2026-02-10T15:32:31Z

+organization using the local cache (e.g. creating a new file in a workspace or
+reading an existing file that is in cache).
+
+To prevent the users from accessing the local cache, the local configuration and data should be manually removed:


I'd rephrase it like this:

Suggested change

To prevent the users from accessing the local cache, the local configuration and data should be manually removed:

The local cache can be safely erased by manually deleting the local configuration and data for the device having access to the organization:

IMO we should add a note or warning to explain how to identify which device is linked to the organization (device id is displayed in the "My Devices" when logged-in... maybe we should consider displaying it in the Home page as tooltip or detail button ?)

touilleMan requested a review from a team as a code owner February 9, 2026 12:57

touilleMan force-pushed the cli-erase-organization branch from c58fc2c to 9fd277c Compare February 9, 2026 12:57

AureliaDolo reviewed Feb 9, 2026

View reviewed changes

FirelightFlagboy reviewed Feb 9, 2026

View reviewed changes

Comment thread docs/hosting/administration/erase_organization.rst Outdated

Comment thread server/parsec/cli/erase_organization.py

Add parsec erase_organization CLI command for the server

8e8f3d3

touilleMan force-pushed the cli-erase-organization branch from 9fd277c to 8e8f3d3 Compare February 10, 2026 09:46

touilleMan requested review from AureliaDolo and FirelightFlagboy February 10, 2026 09:46

mmmarcos reviewed Feb 10, 2026

View reviewed changes

	containing a copy of the certificates, metadata for the workspaces its has access to, and a subset
	containing a copy of the certificates, metadata for the workspaces it has access to, and a subset

	To prevent the users from accessing the local cache, the local configuration and data should be manually removed:
	The local cache can be safely erased by manually deleting the local configuration and data for the device having access to the organization:


		.. warning::

		This operation cannot be undone. Make sure you have a backup of any data you may need before


		.. note::

		After erasing an organization, it is possible to create a new organization with the same name

	f"- The organization's blocks won't be erased from the blockstore, you should instead manually remove the {display_bucket_path} top level directory from it."
	f"- The organization's blocks won't be erased from the blockstore, you should manually remove the {display_bucket_path} top level directory from it."

		Where & how the data are stored
		-------------------------------

		When no longer in use (or for legal reason) an organization can be erased from the Parsec server.

		In practice this means:

		Step 1: remove from PostgreSQL
		------------------------------

-Step 1: remove from PostgreSQL
-------------------------------
+Step 1: Delete certificates from PostgreSQL
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-Step 3: Clients cleanup
------------------------
+Step 3: delete local data from Parsec clients
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

		- config: ``$XDG_DATA_HOME or $HOME/.local/share/parsec3/<device_id>`` (e.g. ``/home/alice/.local/share/parsec3/e68b7131394749a4bbd279bd087e6ae6``)
		- data: ``$XDG_CONFIG_HOME or $HOME/.config/parsec3/libparsec/devices/<device_id>`` (e.g. ``/home/alice/.config/parsec3/libparsec/devices/e68b7131394749a4bbd279bd087e6ae6``)

Uh oh!

Conversation

touilleMan commented Feb 9, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mmmarcos left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants