The user collections are stored in redis, and linked to the user using [the user id][0]. This ID is entirely different from that in the auth(entic|oris)ation system, unless we get the go-ahead to [migrate the user accounts][1].

The auth(entic|oris)ation system provides the following endpoint(s) for getting user details

• `/oauth2/user/`: Note the trailing forward slash (/). This endpoint provides user data such as the user's ID, email and name, and their group membership information.

Since we know the form that the user account are stored in redis[1], we can use that to search for user collections.

The steps would be something like:

• User registers afresh using their email and (possibly new) password
• User logs in
• System searches for user with the same email in redis
• If user with similar email is not found, do nothing
• If user with similar email is found, retrieve their old user-id
• Use old user-id to identify their collections
• If no collections are found using the old user-id, do nothing.
• If at least one collection is found using the old user-id present user with option to "migrate data"
• User click the "migrate data" button
• System changes user-id on the identified collections from the old user-id to the new user-id

#### Anonymous Collections

Users can create and work with collections without being authenticated to the system. Such collections (which I dub "anonymous collections") are ephemeral. They were linked to the session[2] via an anonymous user_id.

In the older system, a user was able to import such anonymous collections by selecting "Import existing collections" when they logged in (see the `import_traits_to_user` function in the sessions[2] module). We need to maintain this feature. This will probably require reworking the code, to get rid of the sessions[2] module while retaining most of what it does.