Bug Report

So similar to the bug that was discovered and already fixed in #95, I just found the same bug for collections.

[nodemon] starting `node server.js`
[09:40:42] INFO (payload): Starting Payload...
[09:40:43] ERROR (payload): There were 1 errors validating your Payload config
[09:40:43] ERROR (payload): 1: "collections[2].admin.views" is not allowed
[nodemon] app crashed - waiting for file changes before starting...

Expected Behavior

As referenced here: https://payloadcms.com/docs/admin/components#collections

Steps to Reproduce

My example code

const Users = {
  slug: "users",
  auth: true,
  admin: {
    useAsTitle: "email",
    views: {
      List: () => <div>My List</div>,
    },
  },
  access: {
    read: () => true,
    create: () => true,
  },
  hooks: {
    beforeRead: [onlyNameIfPublic],
  },
  fields: [
    // Email added by default
    {
      name: "name",
      label: "Name",
      type: "text",
    },
  ],
};

export default Users;

Additional Bug in globals?

Also I found that the views.edit customization for globals does not seem to work either. (Docs)

// file Navigation.js
...
  admin: {
    views: {
      Edit: () => <div>My Edit</div>,
    },
  },
...

Bug Report

Clicking 'save' prevents me from adding content because it's missing localisation information. Can't switch locale in bottom left until content is saved.

page validation failed: meta.en: Path meta.en is required.

Expected Behavior

Clicking save should save the data and/or we should be able to switch locales without saving the new content.

Current Behavior

Prevented from saving data or switching locale

Steps to Reproduce

1. Add the schema below
2. Try to create a new page and click save
3. See the error in the attached screenshot

Detailed Description

Stack trace

[01:12:37] ERROR (payload): ValidationError: page validation failed: meta.en: Path meta.en is required.
at model.Document.invalidate (/Users/richard/Code/Brightvision/Experiments/payload/brightvision/node_modules/mongoose/lib/document.js:2693:32)
at /Users/richard/Code/Brightvision/Experiments/payload/brightvision/node_modules/mongoose/lib/document.js:2513:17
at /Users/richard/Code/Brightvision/Experiments/payload/brightvision/node_modules/mongoose/lib/schema/SingleNestedPath.js:248:14
at /Users/richard/Code/Brightvision/Experiments/payload/brightvision/node_modules/mongoose/lib/schematype.js:1240:9
at processTicksAndRejections (internal/process/task_queues.js:76:11)

Schema

import { CollectionConfig } from 'payload/types'

const Page: CollectionConfig = {
  slug: 'page',
  labels: {
    singular: 'Page',
    plural: 'Pages',
  },
  access: {
    create: () => true,
    read: () => true,
    update: () => true,
    delete: () => true,
  },
  fields: [
    {
      name: 'meta',
      type: 'group',
      localized: true,
      label: 'Page Meta',
      fields: [
        {
          name: 'title',
          type: 'text',
          required: true,
          minLength: 20,
          maxLength: 100,
        },
        {
          name: 'metaDescription',
          type: 'textarea',
          required: true,
          minLength: 40,
          maxLength: 160,
        }
      ],
    }
  ]
}

export default Page;

Screenshot

I wish there was a date format in the collections-timestamps option and the date field option.

Perhaps the following codes are involved.
https://github.com/payloadcms/payload/blob/master/src/admin/components/views/Account/Default.tsx#L141
https://github.com/payloadcms/payload/blob/master/src/admin/components/views/collections/Edit/Default.tsx#L185
https://github.com/payloadcms/payload/blob/master/src/admin/components/views/collections/List/Cell/field-types/Date/index.tsx#L6

Bug Report

I'm trying to get file information for an upload field so I can check for its filetype but typescript is complaining about not being able to return a promise.

Expected Behavior

I can create validate functions using async as described here: https://payloadcms.com/docs/fields/overview#validation

Current Behavior

I get typescript errors because the return type is string | boolean rather than Promise<string | boolean>.

Detailed Description

Payload version: 0.2.4

Bug Report

So I tried out the block builder and did get an error when not using the labels key on the block itself.
The documentation does not state, that labels is required. After setting the labels it's okay.
I'm not using Typescript.

C:\Development\portfolio-21\cms\node_modules\payload\dist\graphql\schema\buildBlockType.js:8
const { slug, labels: { singular, }, } = block;
                            ^

TypeError: Cannot read property 'singular' of undefined
    at InitializeGraphQL.buildBlockType (C:\Development\portfolio-21\cms\node_modules\payload\dist\graphql\schema\buildBlockType.js:8:29)
    at C:\Development\portfolio-21\cms\node_modules\payload\dist\graphql\schema\buildObjectType.js:323:22
    at Array.map (<anonymous>)
    at blocks (C:\Development\portfolio-21\cms\node_modules\payload\dist\graphql\schema\buildObjectType.js:322:45)
    at C:\Development\portfolio-21\cms\node_modules\payload\dist\graphql\schema\buildObjectType.js:353:65
    at Array.reduce (<anonymous>)
    at fields (C:\Development\portfolio-21\cms\node_modules\payload\dist\graphql\schema\buildObjectType.js:346:30)
    at resolveThunk (C:\Development\portfolio-21\cms\node_modules\graphql\type\definition.js:480:40)
    at defineFieldMap (C:\Development\portfolio-21\cms\node_modules\graphql\type\definition.js:692:18)
    at GraphQLObjectType.getFields (C:\Development\portfolio-21\cms\node_modules\graphql\type\definition.js:633:27)
    at collectReferencedTypes (C:\Development\portfolio-21\cms\node_modules\graphql\type\schema.js:366:81)
    at collectReferencedTypes (C:\Development\portfolio-21\cms\node_modules\graphql\type\schema.js:368:9)
    at new GraphQLSchema (C:\Development\portfolio-21\cms\node_modules\graphql\type\schema.js:153:7)
    at new InitializeGraphQL (C:\Development\portfolio-21\cms\node_modules\payload\dist\graphql\index.js:99:23)
    at Payload.init (C:\Development\portfolio-21\cms\node_modules\payload\dist\index.js:177:36)
    at Object.<anonymous> (C:\Development\portfolio-21\cms\server.js:8:9)
[nodemon] app crashed - waiting for file changes before starting...

Possible Solution

Update the documentation here https://payloadcms.com/docs/fields/blocks#block-configs, that labels is required

Steps to Reproduce

// ./blocks/Quote.js

const QuoteBlock = {
  slug: "Quote", // required
  imageURL:
    "https://images.unsplash.com/photo-1612831198181-fe18661c31b6?ixid=MXwxMjA3fDF8MHxwaG90by1wYWdlfHx8fGVufDB8fHw%3D&ixlib=rb-1.2.1&auto=format&fit=crop&w=1950&q=80",
  imageAltText: "A nice thumbnail image to show what this block looks like",
  // labels: {  // <- this here
  //   singular: "Quote",
  //   plural: "Qoutes",  
  // },
  fields: [
    // required
    {
      name: "text",
      label: "Quote Text",
      type: "text",
      required: true,
      localized: true,
    },
    {
      name: "quotee",
      label: "Quotee",
      type: "text",
      localized: true,
    },
  ],
};

export default QuoteBlock;

Detailed Description

OS: Windows 10
Payload Version: 0.4.3
Node: v14.15.1

Bug Report

Not sure if this is a supported use case but the API seems to indicate it so maybe this is a case of giving warnings/documenting but... given the following collection schema:

import { CollectionConfig, Block } from 'payload/types'

const RichTextBlock: Block = {
  slug: 'richText',
  labels: {
    singular: 'Rich Text',
    plural: 'Rich Text Blocks',
  },
  fields: [
    {
      name: 'content',
      type: 'richText',
    }
  ]
}

const LocalizedRichText: CollectionConfig = {
  slug: 'localizedRichText',
  labels: {
    singular: 'LocalizedRichText',
    plural: 'LocalizedRichTexts'
  },
  fields: [
    {
      label: `Test Rich Text`,
      name: `richText`,
      type: `richText`,
      localized: true,
      required: true
    },
    {
      label: `Test Rich Text in Blocks`,
      name: 'richTextBlocks',
      type: 'blocks',
      blocks: [
        RichTextBlock
      ]
    },
  ]
}

export default LocalizedRichText

Calls the retrieve content from the API return null on the block form of rich text. The data does get added to the database on save.

Expected Behavior

Returns localised content on the field.

Current Behavior

Returns null from the API:

{"richTextBlocks":[{"blockType":"richText","blockName":"Hello","content":null}],"createdAt":"2021-02-01T02:45:45.199Z","updatedAt":"2021-02-01T02:45:45.199Z","id":"60176b59fd0c38d550038571"}

Data is correctly stored in the document:

> db['localized-rich-texts'].find()
{ "_id" : ObjectId("60176b59fd0c38d550038571"), "richTextBlocks" : [ { "blockType" : "richText", "blockName" : "Hello", "content" : [ { "children" : [ { "text" : "Hello" } ] } ] } ], "createdAt" : ISODate("2021-02-01T02:45:45.199Z"), "updatedAt" : ISODate("2021-02-01T02:45:45.199Z"), "__v" : 0 }

Possible Solution

Either disable/warn/ignore about the ability to localize individual fields within a block or make it return as expected.

Steps to Reproduce

1. Use the collection schema above
2. Create a new block in collection
3. Check the API response

Detailed Description

Payload version: 0.2.9

Bug Report

#93 (comment)
Payload Config admin.components.views is not passing validaiton even though it is valid:

components: {
      views: {
        Dashboard: () => <div>Hello</div>,
      },
    },

Expected Behavior

Payload should start and not throw a validation error.

Current Behavior

There is a validation error thrown on startup.

Possible Solution

change the payload config validation for admin.components.views.dashboard to have a custom component

Steps to Reproduce

1. Create a project with a payload config that has admin.components.views.Dashboard set to a custom component
2. start the app

Detailed Description

Payload v0.4.4

Bug Report

Hello guys,

When you click on the "bullet list" option in slate and then deselect it, the editor and the whole admin panel crashes. Throwing the following exception. This also happens for numbered lists.

Uncaught (in promise) Error: Cannot find a descendant at path [1,0,0] in node: {"children":[{"children":[{"text ...
... at Object.get (935.c22ba3f17ddb7dd20c2c.js:2)
at Object.leaf (935.c22ba3f17ddb7dd20c2c.js:2)
at Object.leaf (935.c22ba3f17ddb7dd20c2c.js:2)
at Object.marks (935.c22ba3f17ddb7dd20c2c.js:2)
at Ur (935.c22ba3f17ddb7dd20c2c.js:2)
at Yr (935.c22ba3f17ddb7dd20c2c.js:2)
at ao (main.7048b17d2b9c077fcdc9.js:2)
at Fo (main.7048b17d2b9c077fcdc9.js:2)
at Ws (main.7048b17d2b9c077fcdc9.js:2)
at Ru (main.7048b17d2b9c077fcdc9.js:2)

Expected Behavior

Bullet point formatting is removed.

Current Behavior

Throws

Possible Solution

Steps to Reproduce

1. Create a rich text field
2. Click on bullet point list
3. Click again
4. Crash

Detailed Description

Payload 0.7.2

Bug Report

This project look amazing! I can't wait to check it out. However, I just ran into an issue getting it setup. Here's the skinny:

1. I ran npx create-payload-app as instructed in the Installation docs.
2. I configured the project. The only thing you might want to know about this part is that I've tried selecting both javascript and typescript project templates, only to have the save erroneous result.
3. I cded into the directory and ran yarn dev. At this point, nodemon starts but the app immediately crashes due to syntax errors.

Expected Behavior

I expect to be able to run yarn dev in a brand new project and have the app run.

Current Behavior

Here's the output that I see after running yarn dev:

➜  my-project yarn dev
yarn run v1.22.10
$ nodemon
[nodemon] 2.0.7
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,json
[nodemon] starting `node server.js`
/path/to/my-project/node_modules/payload/dist/fields/traverseFields.js:32
        const hasLocalizedValue = (typeof data?.[field.name] === 'object' && data?.[field.name] !== null)
                                               ^

SyntaxError: Unexpected token '.'
    at Module._compile (internal/modules/cjs/loader.js:892:18)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:973:10)
    at Module.load (internal/modules/cjs/loader.js:812:32)
    at Function.Module._load (internal/modules/cjs/loader.js:724:14)
    at Module.require (internal/modules/cjs/loader.js:849:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/path/to/my-project/dist/fields/performFieldOperations.js:8:42)
    at Module._compile (internal/modules/cjs/loader.js:956:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:973:10)
    at Module.load (internal/modules/cjs/loader.js:812:32)
    at Function.Module._load (internal/modules/cjs/loader.js:724:14)
    at Module.require (internal/modules/cjs/loader.js:849:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/path/to/my-project/node_modules/payload/dist/index.js:27:50)
    at Module._compile (internal/modules/cjs/loader.js:956:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:973:10)
[nodemon] app crashed - waiting for file changes before starting...

It seems clear that the @babel/plugin-proposal-optional-chaining plugin isn't being loaded, but I can't figure out why.

Possible Solution

I'm not sure, but I'll do my best to provide you with whatever further info you need. I appreciate your help!

Steps to Reproduce

1. Run npx create-payload-app.
2. Complete project setup, choosing javascript or typescript as the project template.
3. cd into the project directory and run yarn dev.
4. See error message appear as nodemon starts and the app immediately crashes.

Detailed Description

OS: MacOS Big Sur 11.2
Node: 12.13.0
Payload: 0.1.146

Not sure if this is a bug, but feels like at least something NextJS offers in a way that is very convenient and that it's understable you guys may have missed this is as being a thing, like me, if you work locally on a full Payload repo, but not for others that just run the npm version of Payload breaking.

Bug Report

When setting up a babel.config.js that can work with both NextJs and Payload I was trying to import babel.config.js from both. That all seemed to work, since I was using my local fork of Payload, that contains the /src folder. When I however had other devs run it all hell broke loose. After some digging I found that Payload is exporting babel.config.js, but that it's a redirect to /src/babel.config.js, which is of course not available in the release version on npm

./babel.config.js

const config = require('./src/babel.config');
module.exports = config;

Expected Behavior

Return like NextJS the babel.config.js used so you can import it and extend it in your project

Current Behavior

No fun with the misleading babel.config.js sitting there as though I could use it, but just breaking things

Possible Solution

In the yarn run copyfiles step maybe add copying src/babel.config.js and change the require to match in ./babel.config.js

For now I fixed it with a good old copy past from the src folder into my project folder, so other devs could quickly continue, but something to hopefully not be necessary. Would be nice to just like with NextJS feel that I can customise babel.config.js without every release checking if I need to update my copy-pasted babel.config.js 😅

Bug Report

I'm not able to create objects with REST API + API Keys. Somehow, Payload checks for email field, and wants it to be unique. Because my Collection model doesn't have email field, I can't create more than one document.

Expected Behavior

I should be able to create multiple documents with REST API

Current Behavior

The POST request is successful for the first document (if there are no other documents of given type in database), the subsequent API requests fail with the following error:

{
    "errors": [
        {
            "name": "ValidationError",
            "message": "The following field is invalid: email",
            "data": [
                {
                    "message": "Value must be unique",
                    "field": "email"
                }
            ]
        }
    ]
}

Stacktrace:

[14:10:08] ERROR (payload): ValidationError: The following field is invalid: email
    at new ExtendableError (/Users/mateusz/Projects/Bestool/bestool/node_modules/payload/dist/errors/APIError.js:22:15)
    at new APIError (/Users/mateusz/Projects/Bestool/bestool/node_modules/payload/dist/errors/APIError.js:38:9)
    at new ValidationError (/Users/mateusz/Projects/Bestool/bestool/node_modules/payload/dist/errors/ValidationError.js:10:9)
    at Payload.create (/Users/mateusz/Projects/Bestool/bestool/node_modules/payload/dist/collections/operations/create.js:151:19)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async Payload.create (/Users/mateusz/Projects/Bestool/bestool/node_modules/payload/dist/collections/requestHandlers/create.js:10:21)

Possible Solution

Steps to Reproduce

1. Add the following collections:

const Admin: CollectionConfig = {
  slug: "admins",
  labels: {
    singular: "Admin",
    plural: "Admins",
  },
  auth: {
    tokenExpiration: 7200, // 2 hours
    verify: false,
    maxLoginAttempts: 5,
    lockTime: 600 * 1000, // lock time in ms
    useAPIKey: true,
    depth: 0,
    cookies: {
      secure: false,
      sameSite: "lax",
      domain: undefined,
    },
  },
  fields: [],
  timestamps: true,
  admin: {
    useAsTitle: "email",
  },
};

const Producer: PayloadCollectionConfig = {
  slug: "producers",
  fields: [
    {
      name: "name",
      type: "text",
      unique: true,
      required: true,
    }
  ],
};

2. Create an admin user, and enable API Key access

3. Issue a POST request to http://localhost:3000/api/producers, with the following header:

Authorization: Admin API-Key <my-key>

with the following data:

{
    "name": "some name"
}

4. Issue another POST request, with different data

Detailed Description

Payload version: 0.7.4

Feature Request

It is standard to have a confirm password field to eliminate typos when creating accounts. We don't currently have that in the CreateFirstUser component.

Use-Case

Could save somebody some trouble if they mistype a password.

Additional Detail

low priority / may not be needed, a developer could always delete the new user record and start over if they can't login.

Missing search functionality

Documentation is pretty robust and there is no way to browse quickly through it.

Additional Details

cmd + K shortcut should display dialog with search bar and results that link to the destination with discovered information (e.g. TailwindCSS).

Bug Report

When a DateTime field has position: 'sidebar' the time dropdown is cut off

Possible Solution

.collection-edit__sidebar-sticky {
  overflow: initial;

  .date-time-picker .react-datepicker-popper {
    right: 0 !important;
    left: initial !important;
  }
}

Possibly better to just set overflow-x

Is how I now fix it in the scss override, probably best to move something like this to the core though (the sidebar never fits the calendar atm). Making sure you guys agree with this direction and I can clean up my hacks and turn it into a proper PR.

Bug Report

Bit of a long and complicated explanation but should have a simple solution. Adding a block of rich text, saving, switching locale and then saving without adding any content causes a problem in JSON.parse because it tries to evaluate undefined.

Expected Behavior

When added new content to a block localised at a field level, the document should save even when no content has been added.

Current Behavior

Data passed to the API is undefined and JSON.parse tries to evaluate it.

Possible Solution

If the request data from a rich text field would fail to evaluate as JSON then that field should be skipped as if it were not there?

Steps to Reproduce

1. Setup payload with more than 1 locale.
2. Create a collection with 1 block field
3. Create a block that just contains 1 localized richText field
4. Add a new entry to that collection under a locale containing 1 block and a bit of richText content
5. Switch locale
6. Hit save without interacting

Detailed Description

Payload version: 0.6.2

[13:18:00] ERROR (payload): SyntaxError: Unexpected end of JSON input
at JSON.parse ()
at /Users/richard/Code/Brightvision/bv-web-v2/node_modules/payload/src/fields/traverseFields.ts:97:37
at Array.forEach ()
at traverseFields (/Users/richard/Code/Brightvision/bv-web-v2/node_modules/payload/src/fields/traverseFields.ts:69:10)
at /Users/richard/Code/Brightvision/bv-web-v2/node_modules/payload/src/fields/traverseFields.ts:225:13
at Array.forEach ()
at /Users/richard/Code/Brightvision/bv-web-v2/node_modules/payload/src/fields/traverseFields.ts:221:57
at Array.forEach ()
at Object.traverseFields [as default] (/Users/richard/Code/Brightvision/bv-web-v2/node_modules/payload/src/fields/traverseFields.ts:69:10)
at Payload.performFieldOperations (/Users/richard/Code/Brightvision/bv-web-v2/node_modules/payload/src/fields/performFieldOperations.ts:75:17)
at Payload.update (/Users/richard/Code/Brightvision/bv-web-v2/node_modules/payload/src/collections/operations/update.ts:177:16)
at runMicrotasks ()
at processTicksAndRejections (node:internal/process/task_queues:94:5)
at Payload.update (/Users/richard/Code/Brightvision/bv-web-v2/node_modules/payload/src/collections/requestHandlers/update.ts:13:17)

Bug Report

I've had a little colour picker component that I've been using for a while and with the update to 0.5.2 it's now causing my admin panel to crash.

I've had a little look into it and it seems to be that getField is comes back with no value as FormContext is not initialised.

Steps to Reproduce

1. Update to payload 0.5.2
2. Create a text field and set admin.components.Field to the code below.
3. View your new field in admin.
4. Crashes.

Additional Context

Stack trace log: debug-1.log

import React from 'react'
import { useFieldType } from 'payload/components/forms';
import { BlockPicker, ColorResult } from 'react-color';

export interface ColorPickerTextField {
  path: string;
  label: string;
  admin?: {
    width?: string;
  }
}

const ColorPickerTextField: React.FC<ColorPickerTextField> = (props) => {
  const {
    path,
    label,
    admin: {
      width
    } = {}
  } = props

  const { value, setValue } = useFieldType({ path });

  const handleColorPicker = (color: ColorResult): void => {
    setValue(color.hex)
  }

  const style = width
    ? {
      style: {
        width
      }
    }
    : null


  return (
    <div {...style}>
      {label
        ? <label className="field-label">{label}</label>
        : null
      }

      <BlockPicker
        triangle="hide"
        colors={[
          `#212121`,
          `#313131`,
          `#F3F0E1`,
          `#FF423B`,
          `#007569`,
          `#FFB997`,
          `#ffffff`,
          `#000000`,
        ]}
        onChangeComplete={handleColorPicker} color={value} />
    </div>
  )
}

export default ColorPickerTextField

Bug Report

Currently the admin panel is crashing for us when we try to edit most collections and it's due to the rich text editor getting saved with an empty string as it's value.

I'm not sure how this data got set this way, so I'm not really able to give reproduction steps. It was reported to me by a content editor so I have no first hand account.

I'm fairly sure it's something to switching between locales on localized fields within blocks.

The error itself should be quite an easy fix, the underlying cause I'm not so sure about.

Expected Behaviour

When a rich text area has it's value set as an empty string, it should render the text area as if had no content passed to it.

Current Behaviour

It tries to run JSON.parse on an empty string and crashes the entire page.

Detailed Description

Payload version: 0.6.5

VM141:1 Uncaught SyntaxError: Unexpected end of JSON input
at JSON.parse ()
at RichText (RichText.js:89)
at renderWithHooks (react-dom.development.js:14985)
at updateFunctionComponent (react-dom.development.js:17356)
at beginWork (react-dom.development.js:19063)
at HTMLUnknownElement.callCallback (react-dom.development.js:3945)
at Object.invokeGuardedCallbackDev (react-dom.development.js:3994)
at invokeGuardedCallback (react-dom.development.js:4056)
at beginWork$1 (react-dom.development.js:23964)
at performUnitOfWork (react-dom.development.js:22779)

I wish there was a function button on the top right of the table that can excel export or print the contents of 1 page where the current filter, ordering, and pagination are applied. This is a useful function in actual cms work.

Bug Report

When running "npx create-payload-app" throws an error after the initial prompt.

Expected Behavior

It should prompt next steps and boilerplate the payload starter app.

Current Behavior

When running the command "npx create-payload-app" it prompts:

Need to install the following packages:
  create-payload-app
Ok to proceed? (y) y

Then pressing enter gives the following error:

C:\Users\username\AppData\Local\npm-cache\_npx\2238e51406dcebe9\node_modules\create-payload-app\bin\cli.js:49
    error(`An error has occurred: ${e?.message}`);
                                      ^

SyntaxError: Unexpected token '.'
    at wrapSafe (internal/modules/cjs/loader.js:1053:16)
    at Module._compile (internal/modules/cjs/loader.js:1101:27)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1157:10)
    at Module.load (internal/modules/cjs/loader.js:985:32)
    at Function.Module._load (internal/modules/cjs/loader.js:878:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
    at internal/main/run_main_module.js:17:47

Possible Solution

I'm not sure if that error comes from my own computer, maybe deprecated packages? I have npm version 7.15.1 and node version v12.18.3 and I don't have any other issue with any other package.

Bug Report

Just tried out the changes in #98 regarding admin thumbnail.

When using the collection.upload.adminThumbnail function, the view will always prepend the custom path provided with serverUrl. Resulting in paths like this:

http://localhost:3000https://brightvision.fra1.cdn.digitaloceanspaces.com/bv-logo-1.svg

Expected Behavior

When a custom path is provided, don't prepend it with the Server URL.

Current Behavior

Adds http://localhost:3000 to the beginning of my paths.

Possible Solution

Problem is in the Thumbnail component here: https://github.com/payloadcms/payload/blob/master/src/admin/components/elements/Thumbnail/index.tsx#L34

Steps to Reproduce

1. Add new upload collection
2. Upload a file
3. Return a string from adminThumbnail
4. Check the path of the resulting admin thumbnails in both the listing and the view

Bug Report: Cannot install on M1 Apple Silicon due to Sharp version

Hey all. Was really looking forward to trying this CMS out, but instantly hit a snag. It doesn't seem like a big problem, but with the rise in Apple Silicon releases and popularity now, I thought it best to mention it.

Expected Behavior

When trying to install payload via yarn or npm, I expect it to install successfully

Current Behavior

When trying to install payload via yarn or npm, it fails as it is unable to compile the sharp package.

Possible Solution

To get it to work currently on M1, you must ensure you have libvips installed first via brew: brew install libvips. However the latest version of sharp supports M1. Upgrade sharp to the latest version (0.28.1) which includes Apple Silicon support. More about this can be found here.

Documentation Issue

The default upload behaviour is to load everything to memory. This is not really feasible when dealing with large files.

Further, the docs are confusing. It is implied that all valid express-fileupload options (like useTempFiles) are supported, however adding anything but upload.limits.fileSize throws an error due to validation failure.

If this limited behaviour is intended, then the docs should probably reflect that.

Additional Details

none

I hope it's OK to just open issues like this but I think this is a bug so you should hopefully find it useful. 😊

Update (Original below)

Problem is actually down to minLength and maxLength properties on textarea. They don't appear to be expected by whatever code is checking the payload config on startup.

Reproduction steps

1. New project created with yarn create payload-app
2. Create textarea with minLength or maxLength properties.
3. Make sure server isn't running.
4. Start the server and see error.

Expected Behavior

Adding the following config (mostly copied from the documentation) should show a collection with a 'title' and 'description' field.

const Page: CollectionConfig = {
  slug: 'page',
  labels: {
    singular: 'Page',
    plural: 'Pages',
  },
  access: {
    create: () => true,
    read: () => true,
    update: () => true,
    delete: () => true,
  },
  fields: [
    {
      name: 'meta', // required
      type: 'group', // required
      label: 'Page Meta',
      fields: [ // required
        {
          name: 'title',
          type: 'text',
          required: true,
          minLength: 20,
          maxLength: 100,
        },
        {
          name: 'description',
          type: 'textarea',
          required: true,
          minLength: 40,
          maxLength: 160,
        }
      ],
    }
  ]
}

Current Behavior

Payload fails to start at payload configuration step due to schema validation failing.

BUT! (and this is why I think it's a bug)

If you comment out the fields, start the server and then uncomment again then it displays as expected.

Reproduction steps

1. New project created with yarn create payload-app
2. Add pages schema as described above.
3. Make sure server isn't running.
4. Start the server and see error.

Bug Report

Hi, i followed the given examples in the demo for relationship A and relationship B. I currently have 2 collections having one relationship field each. If i got this right it should be possible to set a mutual relation this way. Now, when i save one entry of collection A ("Profile") with a relation to an entry of collection B ("Meta") it would save and display the relation after reopening the entry int the editor. Doing the same with entry B would save the relation as well (at least according to the record in the db) but it won't get displayed in the relationship field and the API's json response.

Expected Behavior

The relationship fields should keep the values when re-opening an entry in the editor and return the relation in the API's repsonse.

Current Behavior

see above.

Steps to Reproduce

see above.

Detailed Description

Relationship field in collection A (Profile)

name: 'relatedMeta', 
type: 'relationship',
label: 'Select related meta entry',
relationTo: ['meta'],
hasMany: false,
access: {
    create: () => true,
    read: () => true,
    update: () => true,
},

Relationship field in collection B (Meta)

name: 'relatedEntry',
label: 'Related entry',
type: 'relationship',
relationTo: ['profiles'],
localized: true,
hasMany: false,
access: {
    create: () => true,
    read: () => true,
    update: () => true,
},

Bug Report

The "Force Unlock" button is visible on create for auth collections.

Expected Behavior

The button should be disabled so you can see where it is for later use.

Current Behavior

The button is not disabled and when clicked it and it makes a non-sense request to unlock a user without sending the needed email address, returning a 500 status.

Possible Solution

Instead of disabling, we could hide it. I prefer to disable it for UX.

Steps to Reproduce

1. Have a collection that includes auth
2. From the admin panel, go to create a new item in the collection
3. Click the "Force Unlock" button

Detailed Description

payload v0.2.9

https://github.com/payloadcms/payload/blob/master/src/admin/scss/vars.scss

I think !default should be added to all of the above variables. Like this,

$baseline-px         : 25px !default;

Bug Report

When moving (dragging or using the index arrows) a block inside of a blocks field type, nested array fields will lose their data when index changes.

Expected Behavior

Data to remain when index changes

Current Behavior

Data resets to an array of empty rows

Possible Solution

Steps to Reproduce

Use this config for a block inside of a blocks field type fields.blocks

export const ContentRepeater: Block = {
  slug: 'contentRepeater',
  labels: {
    singular: 'Content Repeater',
    plural: 'Content Repeater',
  },
  fields: [
    {
      name: 'fixedBackgroundImage',
      type: 'upload',
      label: 'Fixed Background Image',
      relationTo: 'media',
      required: true,
    },
    {
      name: 'sections',
      type: 'array',
      minRows: 1,
      label: 'Sections',
      fields: [
        {
          label: 'Section Type',
          name: 'sectionType',
          type: 'select',
          required: true,
          defaultValue: 'contentContent',
          options: [
            {
              label: 'Content Content',
              value: 'contentContent',
            },
            {
              label: 'Content Image',
              value: 'contentImage',
            },
          ],
        },
        {
          name: 'imageAlignment',
          type: 'select',
          label: 'Image Alignment',
          required: true,
          options: [
            {
              label: 'Right',
              value: 'right',
            },
            {
              label: 'Left',
              value: 'left',
            },
          ],
          admin: {
            condition: (_, siblingData) => siblingData?.sectionType === 'contentImage',
          },
        },
        {
          type: 'upload',
          name: 'image',
          label: 'Image',
          relationTo: 'media',
          admin: {
            condition: (_, siblingData) => siblingData?.sectionType === 'contentImage',
          },
        },
        {
          type: 'richText',
          name: 'contentOne',
          label: 'Content',
        },
        {
          type: 'richText',
          name: 'contentTwo',
          label: 'Content',
          admin: {
            condition: (_, siblingData) => siblingData?.sectionType === 'contentContent',
          },
        },
      ],
    },
  ],
};

Detailed Description

Browser: Brave/Chromium
Payload Version: 0.4.7

Feature Request

I would like the ability to either:

• Collapse/Expand groups similar to Sanity's collapsible attribute on fieldsets
• Organise groups into tabs on a given block
• Provide a separate "block settings" UI for certain properties

What the best approach to take I'm not sure but ideally it shouldn't change the shape of the data coming back from the API, it'd just be a way of visually organising repeated properties, similar to the admin: { sidebar: true } property.

Use-Case

A really nice feature is being able to visually stash of fields in the sidebar, which means that editors can focus on content in the main area. Now, some of my blocks have some shared optional groups, things like background properties. If I type and test things properly this means I can make the block editing experience super flexible without increasing the complexity of the code via ✨composition✨.

The main problem though is that it clutters up the editing experience a lot as seen in the screenshot attached. 🙏

Additional Detail

Thanks for a lovely framework and a nice job on the first video. Really hope you guys will get more traction soon 🤞 At least I'm recommending it to any client that will hear it.

Feature Request

I've found old commit messages (https://github.com/payloadcms/payload/search?q=%22slate-plugin%22&type=commits) where apparently slate-plugins (https://github.com/udecode/slate-plugins) was working with PayloadCMS. They've been working hard over there and are now at their first 1.0.~ (although still alpha) release. I was wondering if we can bring back support for integrating them or opening up more ways to connect with the SlateJS editor instance, also f.e. to hook into event listeners.

Use-Case

See the examples at https://slate-plugins-next.netlify.app/?path=/story/docs-intro--page

Additional Detail

Wondering why the integration was removed? Adding a separate parameter for the plugins on the richText field (not on the element- or leaf-level) could really open up a lot of extra possibilities.

I believe the integration should be made into src/admin/components/forms/field-types/RichText/RichText.tsx. If there are no objections I might be able to send in a pull request.

Bug Report

There's a regression in 0.5.0. I just tried it out in the demo app to confirm. When uploading an asset the user is not able to submit the form, instead getting a prompt to "Please correct errors.".

Expected Behavior

Form validation passes and upload continues.

Current Behavior

Toast popup: "Please correct errors."

Possible Solution

It's happening somewhere around here: https://github.com/payloadcms/payload/blob/master/src/admin/components/forms/Form/index.tsx#L71

It seems to be happening because it's expecting a filename to be present and have a value but at that time the file has not been uploaded so we only have access to a raw value property.

Steps to Reproduce

1. Update to 0.5.0
2. Spin up demo
3. Try to upload something under Media

Detailed Description

Payload: 0.5.0

Update

It's actually the API not being aware of newly created blocks until the server restarts.

Just restarted the development server. Seems that blocks in the API don't get restarted the same way the API UI does. After closing down the server and starting up again entirely it now works as expected.

Don't know if you still want to consider this a bug but it was confusing from a developer experience perspective because everything else restarts smoothly. 😎

Bug Report

Certain blocks are failing to update their content via the admin. Initially, I thought it was down to a definition I created but after copying the QuoteBlock example from here I find they are also not updating.

I will try to experiment later and find some more information but I'm hoping you might have some insight in the mean time.

Expected Behavior

My blocks should save the content I added to them.

Current Behavior

Data returned from the API does not include new values added via the block. Also attached is the request/response that's made to the API.

const ClientListBlock: Block = {
  slug: 'clientList',
  labels: {
    singular: 'Client Listing',
    plural: 'Client Listings'
  },
  fields: [
    {
      type: 'text',
      name: 'test',
      label: 'Test'
    }
  ]
}

export default ClientListBlock

const QuoteBlock: Block = {
  slug: 'Quote', // required
  imageURL: 'https://google.com/path/to/image.jpg',
  imageAltText: 'A nice thumbnail image to show what this block looks like',
  labels: {
    singular: 'Test',
    plural: 'Tests'
  },
  fields: [ // required
    {
      name: 'text',
      label: 'Quote Text',
      type: 'text',
      localized: true,
      required: true,
    },
    {
      name: 'text',
      label: 'Quotee',
      type: 'text',
      localized: true,
    },
  ]
};

Steps to Reproduce

1. Create page builder schema with the definition bellow
2. (possibly related but maybe not) add localisation as defined below
3. Add either of the attached block schemas
4. Try to create a new block

Detailed Description

Request Screenshots:

Request stack trace:

put @ http://localhost:3000/admin/main.js:25097
(anonymous) @ http://localhost:3000/adminvendors-node_modules_payload_dist_admin_components_forms_Error_index_js-node_modules_payload_-6c3d35.js:834
(anonymous) @ http://localhost:3000/adminvendors-node_modules_payload_dist_admin_components_forms_Error_index_js-node_modules_payload_-6c3d35.js:819
callCallback @ http://localhost:3000/admin/main.js:43269
invokeGuardedCallbackDev @ http://localhost:3000/admin/main.js:43318
invokeGuardedCallback @ http://localhost:3000/admin/main.js:43380
invokeGuardedCallbackAndCatchFirstError @ http://localhost:3000/admin/main.js:43394
executeDispatch @ http://localhost:3000/admin/main.js:47567
processDispatchQueueItemsInOrder @ http://localhost:3000/admin/main.js:47599
processDispatchQueue @ http://localhost:3000/admin/main.js:47612
dispatchEventsForPlugins @ http://localhost:3000/admin/main.js:47623
(anonymous) @ http://localhost:3000/admin/main.js:47832
batchedEventUpdates$1 @ http://localhost:3000/admin/main.js:61715
batchedEventUpdates @ http://localhost:3000/admin/main.js:43069
dispatchEventForPluginEventSystem @ http://localhost:3000/admin/main.js:47831
attemptToDispatchEvent @ http://localhost:3000/admin/main.js:45329
dispatchEvent @ http://localhost:3000/admin/main.js:45248
unstable_runWithPriority @ http://localhost:3000/admin/main.js:80927
runWithPriority$1 @ http://localhost:3000/admin/main.js:50600
discreteUpdates$1 @ http://localhost:3000/admin/main.js:61732
discreteUpdates @ http://localhost:3000/admin/main.js:43080
dispatchDiscreteEvent @ http://localhost:3000/admin/main.js:45213

Prop pickerAppearance is missing in documentation

Expected Behavior

pickerAppearance?: 'dayAndTime' | 'timeOnly' | 'dayOnly' should be documented, pulled from here

Current Behavior

Missing from Fields/Date here

Possible Solution

Add pickerAppearance in the props table

Steps to Reproduce

N/A

Detailed Description

N/A

Bug Report

React crashes with Uncaught TypeError: data.join is not a function while rendering the role SelectCell in a users collection page.

here 👉 https://github.com/payloadcms/payload/blob/master/src/admin/components/views/collections/List/Cell/field-types/Select/index.tsx#L15

in this case, data is "admin" and '.join' is undefined on String.

Uncaught TypeError: data.join is not a function
    SelectCell index.js:16
    React 12
    unstable_runWithPriority scheduler.development.js:468
    React 5
    fetchData usePayloadAPI.js:26
    usePayloadAPI usePayloadAPI.js:35
    React 5
    unstable_runWithPriority scheduler.development.js:468
    React 3
    workLoop scheduler.development.js:417
    flushWork scheduler.development.js:390
    performWorkUntilDeadline scheduler.development.js:157
    js scheduler.development.js:180
    js scheduler.development.js:645
    Webpack 20
index.js:16
    SelectCell index.js:16
    React 11
    performSyncWorkOnRoot self-hosted:1220
    flushSyncCallbackQueueImpl React
    unstable_runWithPriority scheduler.development.js:468
    React 5
    dispatchAction self-hosted:1277
    fetchData usePayloadAPI.js:26
    InterpretGeneratorResume self-hosted:1480
    AsyncFunctionNext self-hosted:690
    (Async: async)
    usePayloadAPI usePayloadAPI.js:35
    React 5
    unstable_runWithPriority scheduler.development.js:468
    React 3
    workLoop scheduler.development.js:417
    flushWork scheduler.development.js:390
    performWorkUntilDeadline scheduler.development.js:157
    (Async: EventHandlerNonNull)
    js scheduler.development.js:180
    js scheduler.development.js:645
    Webpack 20

With a user collection config like:

import { CollectionConfig } from 'payload/types';

export const Users: CollectionConfig = {
  slug: 'users',
  auth: true,
  admin: {
    useAsTitle: 'email',
  },
  access: {
    read: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    {
      name: 'role',
      type: 'select',
      required: true,
      options: ['user', 'admin'],
    },
    {
      name: 'primaryAddress',
      type: 'relationship',
      relationTo: 'addresses',
      hasMany: false,
      // required: true,
      label: 'Primary Address',
    },
  ],
};

Expected Behavior

Should render the data directly and not crash.

Current Behavior

Crashes

Detailed Description

payload ^0.6.10

Bug Report

As discussed in #98 I created a virtual field like so:

{
  label: 'S3 URL',
  name: 's3Url',
  type: 'text',
  admin: {
    readOnly: true,
  },
  hooks: {
    beforeChange: [
      (): undefined => undefined,
    ],
    afterRead: [
      ({ data }): string => {
        return getUrl(String(data.filename))
      }
    ]
  }
}

When editing an existing document, we get a disabled text input with the correct text.

However when creating a new document, we get an empty text area that the user can edit.

Expected Behavior

Ideally, unless there's a reason no to we should not see the read-only field at all until the document is created.

Current Behavior

Shows editable text input.

Steps to Reproduce

1. Create a field on a collection with {admin: {readOnly: true}}.
2. Try to create a new document.

Detailed Description

Payload version: 0.4.4

Bug Report

I tried to add a condition to the blocks field type because I don't want it to be visible unless it's being used. Clicking the sibling "hasSubmenu" checkbox causes the admin UI to freeze and task has to be forcefully killed.

{
  type: 'checkbox',
  name: 'hasSubmenu',
  label: 'Has Submenu?',
},
{
  type: 'blocks',
  label: 'Sub Menu Columns',
  name: 'subMenuColumns',
  blocks: [
    SubmenuLink
  ],
  admin: {
    condition: (data: MainMenu, siblingData: MenuItem): boolean => {
      return siblingData?.hasSubmenu || false
    }
  }
}

Expected Behavior

Doesn't hang admin interface. 🥺

Current Behavior

Hangs admin interface. 😤

Possible Solution

Definately an infinite loop of some kind.

Detailed Description

No errors in console.

Payload version: 0.2.12

Expected Behavior

Don't throw errors 😉

Current Behavior

When creating a new page the value in the validation for minLength can throw an error when trying to access value.length.

Possible Solution

same fix needs to be applied as for text in this commit 5e60b86

Steps to Reproduce

1. Create field with textarea type and min/max length validation
2. Create new document
3. See error

I am using i18n library to translate label. In this case, there is a problem in creating the gql schema. Perhaps the code below is relevant.
https://github.com/payloadcms/payload/blob/master/src/graphql/utilities/formatName.ts#L3

In my opinion, the label is the right thing to use for the part that is usually displayed. It would be nice to change it to create the gql schema internally using slug or name.

Bug Report

Setting the server URL to something with a path such as

http://localhost:3000/cms

Does not appear to work, despite printing:

[02:31:35] INFO (payload): Payload Admin URL: http://localhost:3000/cms/admin

Expected Behavior

You should be able to access the admin panel at the URL that is printed

Current Behavior

The route binding does not appear to factor in sub paths

Possible Solution

Use the provided serverURL when configuring express bindings in index.js

Steps to Reproduce

1. Set the serverURL to http://localhost:3000/foo
2. Observe that the log prints the admin URL as http://localhost:3000/foo/admin
3. Observe that opening your browser to that page shows a broken looking "loading" message indefinitely

Detailed Description

I am trying to do this because I have multiple containerized applications running in my environment - e.g.

https://staging.mysite.com
 - port 3000 -> payload
 - port 7017 -> mongodb
 - port 3001 -> my-website-using-payload

Ideally, the front-end site will exist at the / root and the CMS will exist at /cms (akin to Wordpress)

Bug Report

Updates are not saving correctly to rich text fields. Originally reported in discussion: #70 @yudyananda

Expected Behavior

Saving after making changes to a richText input should persist to the database.

Current Behavior

On save from the admin panel, the reqeust shows the changes to the content as an array that appears to include the added text and the response is a 200. The collection item doesn't contain the additional text in the array.

Possible Solution

Investiigating if the richText input is providing incorrect format or if it is an issue on the API side.

Steps to Reproduce

1. npx create-payload-app rich-text-bug chose typescript, blog
2. cd rich-text-bug & yarn dev
3. localhost:3000/admin, sign in. Create a Post. See Save successful snackbar.
4. Enter some more text in the Content and save again.
5. Navigate back to Posts, click the post that was updated.
6. See the original, not updated content in the editor. Also verified in mongoDB collection that the original was not modified.

Detailed Description

payload v0.212
create-payload-app v0.1.16

Expected Behavior

Able to login successfully when auth: true on admin user collection.

Current Behavior

A login attempt will throw error "expiresIn" should be a number of seconds or string representation of timespan

Possible Solution

Collection config sanitization is not being handled properly when set as auth: true. This works properly if auth is set to any object.

Steps to Reproduce

1. Create a Users collection with auth: true
2. Attempt to log in

Feature Request

Export Collection Hook types from payload/hooks.

Use-Case

This would let JavaScript config authors benefit from Intellisense in IDEs like VSCode, and would allow TypeScript devs to reuse existing types, therefore not having to re-write them manually.

Additional Details

Requested in discussion #98

Bug Report

When I create a collection that has a relationship field, I'm not able to select one option.

Expected Behavior

When I set a new field relationship, the dropdown let me select the option and save my object.

Current Behavior

When I create a field with relationShip, but with hasMany set to False, I'm not able to select the object from the list dropdown

Possible Solution

Fiz the react component. Looks like a little bug.

Steps to Reproduce

1.Create a new relationship field like this one:
{
name: 'cuisineRelated',
label: 'Culinária',
type: 'relationship',
relationTo: ['cuisine', 'users'],
hasMany: false,
required: false
},

2. Go to admin and try to pick one option from the Cuisine collection
3. The dropdown list don't allow me to select the option.

Detailed Description

I'm using the latest available Payload version from npm and my Browser is Google Chrome.

Bug Report

When you are working in a bullet or unordered list most rich text editors will allow you to add a new bullet point by pressing enter. Pressing backspace on an empty bullet point would end or split the list formatting.

Expected Behavior

Pressing enter would create a new bullet point.

Pressing backspace when no text in bullet will end list.

Current Behavior

Pressing enter creates an indented line just bellow the bullet point.

Pressing CTRL + Z will restore the bullet point... for some reason

Pressing backspace removes the item entirely but puts the cursor back on the line above.

Reproduction steps

1. Go to any slate editor in payload
2. Create a bullet list
3. Press enter
4. Try to backspace

Detailed Description

Payload 0.7.2

Bug Report

I'm trying to inline an SVG uploaded to the admin using react-svg so that I can manipulate its properties. Unfortunately, this means making an async request to the resource and although the media has public read access, Chrome is blocking because the CORS headers in payload.config.js are not being added to the file response.

Expected Behavior

Given the following payload.config.js

export default buildConfig({
  serverURL: 'http://localhost:3000',
  cors: ['http://localhost:3001'],
  ...
})

Script requests made to media such as http://localhost:3000/media/images/bv-logo.svg should respect the CORS setting. Like so:

Access-Control-Allow-Origin: http://localhost:3001

Current Behavior

No access control headers are set:

Steps to Reproduce

1. Create a collection with upload: true
2. Allow public read access
3. Upload an asset
4. Configure CORS to accept from all
5. Make an async request to the asset from another client
6. Error

Bug Report

There's a couple of wonky behaviours around rich text relationships. I think they're related so I'm putting them as one issue.

It seems to be that if you add a relationship, select somewhere else, and add another relationship:

1. The form is still populated with the previous values.
2. The events that fetch the relationships are no longer bound to the select box.
3. The "Add relationship" button submits the main form rather than inserting a new relationship inline.

It's hard to explain so I've included a screen recording.

Steps to Reproduce

1. enableRichTextRelationship on a couple of different modules.
2. Try to insert a relationship, should be OK
3. Try to insert another.
4. See issues described above.

Bug Report

Hi there,

I’ve just started with Payload. I’ve hosted a simple Todo starter on a Plesk server using Docker and it is up and running here,
http://my-domain:8081/admin/
However, while creating a new user it is looking for resources from localhost and gets this error.
POST https://localhost:8081/api/users/first-register net::ERR_CONNECTION_REFUSED

Expected Behavior

Should call http://my-domain:8081/api/users/first-register
and load the dashboard.

Current Behavior

Get this error
POST https://localhost:8081/api/users/first-register net::ERR_CONNECTION_REFUSED

Detailed Description

My server config is like this.
`const PORT = process.env.PORT || 8081
const HOST_NAME = process.env.HOST_NAME || 'localhost'

export default buildConfig({
serverURL: https://${HOST_NAME}:${PORT},
admin: {
user: Users.slug,
},
collections: [
TodoLists,
Users,
CustomTodo
],
});`

And my console log:

[11:32:19] INFO (payload): Starting Payload... [11:32:20] INFO (payload): Payload Api URL: http://my-domain:8081 [11:32:20] INFO (payload): Payload Admin URL:http://my-domain:8081 App is running on port 8081 [11:32:20] INFO (payload): Connected to Mongo server successfully! [11:32:20] INFO (payload): E-mail configured with mock configuration [11:32:20] INFO (payload): Log into mock email provider at https://ethereal.email [11:32:20] INFO (payload): Mock email account username: [email protected] [11:32:20] INFO (payload): Mock email account password: dXPrKuUHGQccrMPcdh [11:42:04] ERROR (payload): NotFound: The requested resource was not found. at new ExtendableError (/app/node_modules/payload/src/errors/APIError.ts:26:11) at new APIError (/app/node_modules/payload/src/errors/APIError.ts:43:5) at new NotFound (/app/node_modules/payload/src/errors/NotFound.ts:6:5) at Payload.findByID (/app/node_modules/payload/src/collections/operations/findByID.ts:88:33) at processTicksAndRejections (internal/process/task_queues.js:93:5) at Payload.findByID (/app/node_modules/payload/src/collections/requestHandlers/findByID.ts:19:17)

Payload version: 0.6.6

Expected Behavior

Should be able to set the relationTo property of a relationship field equal to the default user collection.

Current Behavior

The field will fail validation because users is not added to the validRelationships properly during collection and global sanitization.

Possible Solution

If Payload is relying on the default user collection, users should be added to the list of valid relationships.

Steps to Reproduce

1. Create an empty config that will automatically add the default User collection.
2. Create a Posts collection or similar with one relationship field pointing to users
3. Attempt to start the server (RIP)

Feature Request

Auto-generate field labels based on the field's name. Allow for labels to be disabled by passing false to the label field property.

Use-Case

It gets a bit tedious to specify field labels over and over, when the name of the field could probably be used and formatted properly to generate a field label automatically.

By generating field labels automatically during field sanitization, there will be less configuration necessary by the developer.

Additional Detail

We need to make sure to adjust the field schema validation and field type(s) to support either strings or booleans to be passed to the label property of all fields that support labels.

We also need to make sure to update Field documentation with the corresponding API changes.

Bug Report

hasMany does not seem to be assignable to to the field type "upload".

Expected Behavior

According to the docs (https://payloadcms.com/docs/fields/upload) hasMany should be available for the uploads field.

Current Behavior

Error: Object literal may only specify known properties, and 'hasMany' does not exist in type 'UploadField'.

Detailed Description

{
    label: 'Gallery',
    name: 'gallery',
    type: 'group',
    fields: [
        {
            label: 'Add images',
            name: 'galleryImage',
            type: 'upload',
            relationTo: 'gallery-images',
            hasMany: true,
        } 
    ]
}, 

Bug Report

This confused me at first because I would start typing, looking for one of my client entries and the name wasn't showing. It quickly became clear that it wasn't fetching the results as I type like I was expecting but rather on scroll this leads to some very strange behaviour like:

1. Results not being able to be found unless you scroll down the list.
2. When there's only item and you scroll it continuously loads from the API, resulting in duplicated entries in the dropdown.

Expected Behavior

As I type, after a de-bounced length of time and maybe a certain number of characters. The API performs a search for the title of the related record and populates the dropdown based on that.

Current Behavior

Results are paginated and only available when the user scrolls down the list, which they might not do.

Steps to Reproduce

1. Create collection A
2. Create collection B with hasMany relationship field to collection A
3. Create ~20 collection A entries with different names
4. Try to add relationships by searching for it in the combo box. Half of them will be missing until you scroll down in the dropdown.

Also:

1. Create collection C
2. Create collection D with hasMany relationship field to collection C
3. Add 1 entry to collection C
4. Scroll down the dropdown in the relationship on collection D