This was partially discussed in #225 (comment) and other similar older discussions.

The current approach of having 2 separate entities (users and profiles) to manage the application users is not very convenient and has several drawbacks:

• It is confusing (and unnecessary) to have both user and relation type fields.

• Setting a profile field value during user create is too verbose and nonintuitive. Currently the process requires sending multiple non-transactional requests:

  // create the user model
  await client.users.create({
    email: "[email protected]",
    password: "123456",
    passwordConfirm: "123456",
  });
  
  // authorize as the previously created user
  await client.users.authViaEmail('[email protected]', '123456');
  
  // update the user profile associated to the previously created user
  await client.records.update('profiles', client.authStore.model.id, {
     name: "test",
     anotherCustomField: "Lorem ipsum...",
  });

• The profiles collection has create and delete API rules, but they are not really useful. Furthermore, because an empty profile is created automatically on user create, the profiles create API rule is not actually triggered (unless the profile record was deleted and then created manually).

• Because the users api doesn't have API rules, currently everyone is allowed to create a new user.

• In addition to the above, there also no easy support for full "manager-subordinate" users management.
  While one user could be allowed to edit the profile data of another user, currently it is not possible, without using PocketBase as framework, to allow for example one user (eg. manager) to completely manage or delete another user (eg. subordinate).

Considering the above shortcomings, I propose to merge the user models and the profiles collection into a new single system collection called users.

This basically means that:

• We will remove the user type field and migrate it existing usage to a relation type field (pointing to the new users collection).

• We will be able to use the new collection's API rules to better control who can access and perform each crud user operation.

• We will be able to create/update a user with just one request, something like:

  await client.users.create({
    email: "[email protected]",
    password: "123456",
    passwordConfirm: "123456",
    name: "test",
    anotherCustomField: "Lorem ipsum...",
  });

• Because of the specifics and the edge cases related to the system fields (email, verified, password) we will have to modify the default behavior of the record_upsert form.

While I'll try to automate as much as possible the required DB changes, this unfortunately will not be fully backward compatible.
Of course, there will be a detailed migration guide, but still users will have to update manually their existing custom app code.

This issue is with high prirority because it will not be backward compatible and the quicker we introduce the changes the "less damage" it will cause.

Please comment with your feedback if you have any different use case or idea how to handle better the current implementation shortcomings (pseudo code and examples are also welcomed).