Hey all since we have released the v3.2.0-beta.0 version (Draft and Publish beta). We needed a place to report any bugs (normally this would be done in the news post) but for now we will use this post.
If you have any bugs try and give as much info as you can and thanks 
Hello, does this version includes the 3.1.6 fixes?
Hey, the publishing workflow seems buggy when using the API only.
When creating an item via the API, I expect it to be a draft, then I’ll publish it via a second action (or maybe a parameter could publish it directly). To me it seems like the creation publishes the content directly, which is not the same behavior as the content editor.
I can’t seem to be able to unpublish anything via the API either.
I’d love a “published” boolean parameter to be able to choose the item state, either when POSTing or PUTing.
Referring GitHub issue #8040 (closed), but replying here to collect all the bug in a single place.
@vynarium it does not, for that if you have any bugs, please file a normal GitHub bug report (Thank you!)
Yup this was something I brought up with the internal team as well but I will poke @Jab about it here also.
Hi 
@VMonsch
Publication workflow are content management features whereas the REST API is a resource API. The publication workflow uses connected users informations for example which you can’t use in the REST API.
What you seem to what is to give end users a publication workflow. We consider those two usecases different. If this is the case you can implement it yourself with a flag like shown in the guides for example
I hope this helps you
Hey @alexandrebodin,
Thanks for your explanation, I understand your point of view but I disagree with the reason.
To me everything the content editor does should be doable via the API. Before being a CMS, Strapi is an API builder, and that’s what makes it awesome.
Following what you say, this means that I couldn’t implement scheduled publishing with the native draft & publish feature ? Also, many clients may ask for (or already use) an agnostic custom admin which just plugs into any headless CMS or content API.
If so, using Strapi for these use cases would mean having to redevelop the same features from scratch and adding “duplicate” fields, wouldn’t it ? This would feel hacky IMO.
This is not my product and you definitely know a lot more about the vision than I do, but I love the flexible aspect of Strapi and to me admin features should go alongside their API implementation.
Please let me know if anything evolves on this matter, it’s an important subject for my team
Totally agree with Victor, the API should be consistent with back office features and vice versa
I was planning to start a big project with Strapi and not being able to schedule a publish might be a blocker (I will check next week)
Is there a workaround that could be implemented?
Hi @DMehaffy,
due to the beta status of this feature, I don’t know which is the best place to ask something related to it. Apologies in advance if you consider this reply off-topic. 
Is there any plan to consider bulk updates to optimize the workflow?
Use case:
I’m considering a workaround (customizing admin UI, webhooks, etc) but having this as native would be nice
Probably best to start a separate discussion, we wanted to keep this topic scoped just to issues with the D&P feature itself.
Hey @alexandrebodin @DMehaffy,
Could we have an update on this publishing via API capability ? Was it discussed internally ?
Also, any ideas on when will the next beta version come out ?
Thanks for the insights
A Draft and Publish feature is a great addition and I am excited about it! However, there are some workflows editors and publishers I have worked with expect that I think are missing.
"published_at": null the final expected behavior, or will it return the last published data (what I expect)? This becomes a much bigger concern with Single Types. If I have a type IndexPage and I unpublish my changes, I don’t want my index page to simply not have data any longer.@ibgrav Thanks for the insights. What you are mentionning is going to be a “versionning / history” like feature not included inside the current draft & publish scope.
Right now this will be as you said a basic published_at flag. This is a first step towards better publication workflows in the future but we didn’t want to develop a big feature without getting more feddback on the basic usage first 
@VMonsch We did discuss it yes I will get into more details so you may understand the bigger picture a bit more. there are multiple points I want to touch on.
First of all, strapi is both a framework and a CMS.
The framework actually doesn’t know what publication is (meaning the REST API doesn’t either) It just has a published_at field that is set and that is auto filtered to be different than null.
This means we can enable live/draft status with the REST API by allowing user to set this field (not possible in the beta). This will allow you to do whatever you want using the API and you are free to implement it like you want.
On the CMS side of things, strapi works with a Content Management API (coming from the content-manager-plugin) This API does expose the CMS features and you can totally use them if you want. The plan is to make them more robust and document them in the future to respond to more advanced usecases. But there are already usable. you will need an Admin user token to use it as it requires logged in user to work.
We will certainly continue to differentiate even more both the REST API and the Content Management API to keep strapi usable as a simple API Builder that doesn’t expose features that work in a CMS and require users / permissions and such.
I hope this helps you understand a bit more the strategy
We will be releasing the stable directly as we only got a few bugs to fix and we won’t be changing the feature scope for now.
@alexandrebodin Ooh ok, thanks for the detailed explanation !
Didn’t know about the entirely separate contribution API, the dissociation actually makes a lot of sense then. Would love some doc on this 
Not sure I got your first point about publication though, do you mean that all content delivered via the REST API gets filtered by the published_at field for its timestamp to be earlier than right now ? If so that’d make it very easy to implement scheduled publication, wouldn’t it ?
Thanks again, cheers to the entire Strapi team
@VMonsch The API filter on published_at being not null actually as we don’t want it to be used with dates in the future (would makes not sense in the interface for example) But implementing a scheduling comes down to adding an extra publish_at_date field and adding some automation to set the published_at to now() when the publish_at field is > to now. Or you can implement it however you like
Hello @DMehaffy,
I am using Strapi v3.3.4. In this version, I am using the draft and publish feature. I have observed some bugs due to this feature.
Blank values accepted while creating draft entries including the fields which is required.
1.1 After creating blank draft entries it shows validation error but not any specific error like This field is required. It only shows when I touch the fields by providing any input. It is very confusing if there are any required fields.
In lifecycles function beforeUpdate() function is not getting all data in the params while publishing the entry. It gets only published_at value.
Let me know if you need more explanation.
Thank you.