feat: add admin.hidden to collections and globals

[DanRibbens]

Description

Allows configuation of collections and globals to be excluded from the admin UI in navigation and routing using admin.hidden.

• I have read and understand the CONTRIBUTING.md document in this repository

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Checklist:

• I have added tests that prove my fix is effective or that my feature works
• Existing test suite passes locally with my changes
• I have made corresponding changes to the documentation

[DanRibbens]

As I think about this more, admin.hidden should be a function that gets called with the user object so that it can be dynamic.

[DanRibbens]

GitHub shit the bed on this diff. The only line really changed here is the .filter() added at L180 and the rest is spacing.

[TimHal]

Thanks a lot for this! It almost went unnoticed for me, but this pretty much solves #1462

Should I close the discussion and link this PR as solution?

[philipgher]

This feature is exactly what I was in need for just now. Just upgraded and tested it out. I noticed I am not getting the full user object however which makes it unusable for making the collection hidden based on the role. I am getting this data atm:

user: {
  collection: "users"
  email: "[email protected]"
  exp: 1683014438
  iat: 1683007238
  id: "644d5bd68438c28453441aaf"
}

Is this the intended return object or is this a bug @DanRibbens ?

[DanRibbens]

Hi @philipgher!
That user object from the decoded JWT token from the auth provider component in the admin UI.

To add more properties to this object you can add saveToJWT: true to any fields in your user collection.

I do agree it would be nicer to have the full user object passed through useAuth. Changing this would be a breaking change since some of the properties would not be in place anymore. If this is a change you want, I would start a new discussion so it isn't lost in this old PR thread.

[DanRibbens]

Thanks a lot for this! It almost went unnoticed for me, but this pretty much solves #1462

Should I close the discussion and link this PR as solution?

@TimHal That would be great!

[philipgher]

Ahh right that makes sense once you know it. Thanks for explaining this @DanRibbens. By reading through the changes in this PR I did notice the data indirectly came from the useAuth hook so I read the docs on that hook. In there it is not mentioned the user object is actually not the full data but only the things stored in the token.

Maybe a documentation update would suffice here. Maybe getting the full user object would be nice if there's no (acceptable) performance hit or something like that.

https://payloadcms.com/docs/admin/hooks#useauth