Unique field ignored when creating User via REST

[notchris]

Hello! Thanks again for maintaining payloadcms @jmikrut

When creating a new user via a REST API call, I tested creating a user with a duplicate 'username'. I've marked this field as unique in the field setup, but it allowed me to create the additional user. Am I setting the field unique property incorrectly?

Thank you!

Chris

const Users: CollectionConfig = {
  slug: 'users',
  auth: true,
  admin: {
    useAsTitle: 'username',
  },
  hooks: {
    afterLogin: [userLoginHook],
  },
  access: {
    read: adminOrSelf,
    update: adminOnly,
    create: () => true,
  },
  fields: [
    {
      name: 'username',
      label: 'Username',
      type: 'text',
      unique: true,
      required: true,
      minLength: 5,
      maxLength: 16
    },
    {
      name: 'banned',
      label: 'Ban User',
      type: 'checkbox',
      admin: {
        position: 'sidebar',
      },
    },
  ],
}

Example of fetch request:

				const res = await fetch('http://localhost:3000/api/users/', {
					method: 'POST',
					headers: {
						'Content-Type': 'application/x-www-form-urlencoded'
					},
					credentials: 'include',
					body: new URLSearchParams({
						username: v.username,
						email: v.email,
						password: v.password
					})
				})
				```


 

[DanRibbens]

This is be fixed as of v1.0.12 via #867

[hunghvu]

Not sure if it is an isolated issue, but I'm still facing the same problem. I regenerated the whole DB and nothing changed. Also, it seems like an index was not created.

Payload: v1.0.19
MongoDB: 5.0.9 Community

          name: 'metaUrlSlug',
          label: 'URL Slug',
          type: 'text',
          required: true, // Show red * in the field, but its validation is overridden by "validate"
          unique: true,
          index: true,
          validate: async (value, { operation }) => {
            if (operation === 'create' || operation === 'update') {
              // Value is undefined during admin UI navigation
              // This crashes the validation process and causes unexpected behavior
              // Turn value into an empty string instead as a workaround
              value = value ?? ''; 
              const re = /^[a-z0-9-]+$/;
              return value.match(re)
                ? true
                : 'URL slug must contain only lower case characters from a to z, 0 to 9, or hyphen.';
            }
          },

[stnokott]

Having the same issue here.
Affects the Users collection (which is also the auth-collection) in my case.

Collection config:

const Users: CollectionConfig = {
	slug: "users",
	auth: true,
	fields: [
		{
			name: "name",
			type: "text",
			unique: true,
			required: true
		},
		// ...
	],
	// ...
};

Performing the following requests in my Jest test:

const resFirst = await request(app).post(`/api/${Users.slug}/`).set("Authorization", `JWT ${loginToken}`).send({ ...regularUser, email: "[email protected]" });
expect(resFirst.statusCode).toBe(201);
console.log(resFirst.body);

const resSecond = await request(app).post(`/api/${Users.slug}/`).set("Authorization", `JWT ${loginToken}`).send({ ...regularUser, email: "[email protected]" });
console.log(resSecond.body);
expect(resSecond.statusCode).toBe(400);  // fails here because status code is 201

Results of the console.log()s:

    {
      message: 'User successfully created.',
      doc: {
        id: '62f3ad53ac71deac99c1641d',
        name: 'Peasant',
        role: 'user',
        email: '[email protected]',
        createdAt: '2022-08-10T13:06:27.627Z',
        updatedAt: '2022-08-10T13:06:27.627Z'
      }
    }

    {
      message: 'User successfully created.',
      doc: {
        id: '62f3ad53ac71deac99c16421',
        name: 'Peasant',
        role: 'user',
        email: '[email protected]',
        createdAt: '2022-08-10T13:06:27.895Z',
        updatedAt: '2022-08-10T13:06:27.895Z'
      }
    }

As you can see, two users with the exact same name are created, even though, there is a unique: true in the name field config.
(Also, the HTTP status code of the second creation request is 201 when it should be 400)

Running on latest 1.0.19.

[stnokott]

A different test that validates uniqueness of the automatically added email field with pretty much the exact same test logic goes through fine btw.

[DanRibbens]

I've tested this locally using mongoDB 4.x, 5.0.10, and 6.0.0. All the versions I've ran are creating indexes exactly as you'd expect.

index: true - index,
unique: true - index, unique
localized: true, unique: true - index, unique, sparse

I've done this on text fields and other field types, at the top of a collection and in groups.

I'm not sure what else to test at this point.

For anyone still having trouble it has to be that the collection indexes, once created are not overwritten. If you can go in and delete the indexes or drop the collection completely and start Payload again, they should be created for you as described.

Let me know if that helps @stnokott and @hunghvu.

[stnokott]

Thanks for the answer, I've switched from mongo-unit to mongo-memory-server for unit tests. It works now, though I am still confused as to why indexes don't work with the former.

On a different, but maybe related note: is it intended that the builtin unique index on the email field in auth-collections returns HTTP code 400 when violated (raising a ViolationError) while a manual unique index on a different field results in a HTTP 500 and a MongoServerError?
(Maybe this is again related to the in-memory MongoDB server..?)

[hunghvu]

@DanRibbens After further testing, it seems like Fields cannot be unique or indexed when residing in a collapsible type. I should have included that part in my initial snippet. That said, I suppose this is not an intentional behavior?

import { CollectionConfig } from 'payload/types';

const Test: CollectionConfig = {
  slug: 'test',
  fields: [
    {
      name: 'neitherInCollapsibleNorGroup',
      label: 'Neither in Collapsible nor Group',
      type: 'text',
      unique: true
    },
    {
      label: 'Collapsible - visual only',
      type: 'collapsible',
      fields: [
        {
          name: 'inCollapsible',
          label: 'In Collapsible',
          type: 'text',
          unique: true,
        },
      ],
    },
    {
      name: 'group',
      label: 'Group - both visual and in DB structure',
      type: 'group',
      fields: [
        {
          name: 'inGroup',
          label: 'In Group',
          type: 'text',
          unique: true,
        },
      ],
    },
  ],
  timestamps: true,
  versions: {
    drafts: true,
  },
};

export default Test;

---

Result:

[DanRibbens]

@hunghvu This is a very helpful detail! I found the error in our logic, will work on a fix.

[hunghvu]

Thanks for the confirmation, I created a formal bug report on this: #922.