Replies: 4 comments 1 reply
-
Hi @paulpopus
Does the PCMS access control not cover your use case? |
Beta Was this translation helpful? Give feedback.
-
I fully agree on Schema changes and old data in the database. We experience the same kind of issues. Already had a broken website on production because we overlooked the data migration part. :X |
Beta Was this translation helpful? Give feedback.
-
Having an integrated solution for simple migration, like clearing fields, would be awesome! A common use case we have is we forgot to localize a field. Then, once the user saves the now localized field, all other localizations are set to empty. It would be great to just say "save the old string value to all localizations" |
Beta Was this translation helpful? Give feedback.
-
I opened a new feature request for a CLI tool to generate automatic migrations (#2424) |
Beta Was this translation helpful? Give feedback.
-
Hey all, we've been using Payload professionally now for 2 months and so we have a list of feedback points around pain points and general ideas for improvement. We're fully onboard and overall we've been loving working with it however there are some clear shortfalls that can be addressed.
Internal cron / scheduler
I know you can add your own cron relatively easily as you have the power to extend express yourself. However I still think there should be something more tightly coupled with Payload at the very least to be a useful helper for more easily adding custom functionality.
The main reason I want this though is because I actually want to see scheduled publishing (or unpublishing) flows be a part of core functionality and not something we'd have to roll out ourselves.
Extend the logger for configuration
I've been wanting to integrate Sentry or Glitchtip (sentry api-compatible alternative) in our APIs however it can be rather complicated with Payload because we don't have access to pino to be able to add our own streams to it; at least that's what I see right now. See for an example https://www.npmjs.com/package/pino-sentry#api
I'd be up for making a plugin that simplifies this setup too if the logger could either be abstracted to use your own or for it to be exposed in some way for additional configuration.
Expose more helpers and re-usable types for GraphQL
Functions like
buildPaginatedListType
should be exposed to devs, there may be more I haven't had to use yet but these are the easy wins.The other thing is being able to re-use the existing paginatedListTypes in our own API calls. For example if I want to have a GetOwnOrders query, it returns the exact same content as the Payload-generated query however it might be filtered somewhat by a custom resolver but right now as far as GraphQL schema is concerned it's an entirely different type which isn't right, making it harder to re-use fragments in the end application.
Finer controls for change hooks
The hooks system is great, however in the change hook, I think it would be nice to have an additional operation for publishing to make the dev exp easier.
Permissions plugin out of the box
I love the complete freedom here but there is a clear need for at least a simple role based plugin to cover the minimum workflows of editors/managers/admins.
Also in the
req
object here thecollection
is null?Payload CLI
A CLI would be very useful to cover a few needs:
Plugins
One would be some plugin examples to cover all kinds of usages, existing plugins have been very helpful but we're still stuck on this issue.
Ability to declare custom fields, this would help largely in developer experience. For example I want to make a slug field; a custom one would let me set it's type to "slug" and then the rest of the configuration will be typed accordingly. It would allow plugins to ship their own fields too.
Schema changes and old data in the database
Adding an extra point to not forget. Currently there have been issues with pushing schema changes after data already exists, it seems that content with old schema will keep their data as expected but this can often actually result in bugs in the admin UI. Bugs we've seen is an error when trying to save data and the listing pages being completely broken. A report to file when I have a reproducible example.
However this step of making schema changes when there's existing data might need a bit more attention, even if it involves dev input perhaps. Like a prompt "erase previous data?" or whatever the case may be if a data migration isn't possible.
I've omitted any major themes that have already been talked about lots, such as better Typescript support.
Some of these issues are actually things I've solved for myself and would love to package as a plugin but personal time is an issue of course.
Beta Was this translation helpful? Give feedback.
All reactions