Interesting idea about doing a separate collection for the authors. I have done that with other similar collections in the past but hadn't thought about it for this. Thanks!
Ah, good point. For this particular case, the initial item is new, so the draft is always the first revision and it's equivalent to unpublished. But that could lead to even more confusion down the road.
I ended up going with the separate field as hus_hmd had suggested. Manipulating the db tables directly ended up being sub-optimal, as expected.
Thanks everyone for the input!
Basically exactly what's in this thread:
Our use case is listing authors for scientific research papers - would like to use a repeater field with author first name and last name. I can't use a repeater because most of the content is getting imported from a public database search, and we are using the Import Collection feature of the API to add it to Perch.
Thanks for the responses!
Clive Walker That's a clever idea, but too much overhead for end users to need to switch back and forth between staging and prod, and give them a workflow for migrating content from staging to prod after they've imported and edited it on staging.
hus_hmd This is the way I was leaning, though I'm hesitant to do it because it could create confusion for end users. They can have a collection item that is in (Perch) draft mode, but has the status field set to active, and vice versa. It's also an extra step for end users - they need to remember to change the Status field from inactive to active on each item they process. I was really hoping to take advantage of the native Perch draft setup.
In looking at the DB tables, from what I can tell the only difference between a collection item in draft & published states is that in the [PERCH_DB_PREFIX]_collection_items table, a draft item has the values for itemJSON and itemSearch blank, while a published item has them filled in. Doesn't look like I can do much with this without editing something like the PerchCollectionImporter class in Perch core.
I suppose one option is to import the item normally, then immediately delete the itemJSON and itemSearch values from the database. That feels pretty hacky, and like it might lead to unintended consequences, but if that's really the only difference between a draft and published item it might do the trick. I will do some testing.
Any thoughts from anyone?
We are trying to import content (from a research database) to a collection in a Runway site, then redirect to the edit page for that item so a few fields can be manually filled in / edited by an Editor.
This works great following these steps: https://docs.grabaperch.com/api/import/collections/
The only problem is that when the content is imported into the collection, it is immediately published to the site, before the editor has had a chance to fill in / edit fields. Is there a way to set the item to be a draft, and then allow the editor to publish it when they are finished?