Join as maintainer?

[herbdool]

@docwilmot do you mind if I join as maintainer? I'd like to get the basics working here.

[docwilmot]

No sir, dont mind at all.

FYI I ported this in the impression that it could extend the core forward revisions we put in years ago then really ignored since. But I didnt feel that Workflow really meshes well with the forwrd revisions concepts much. Would be happy to hear your opinion there.

[herbdool]

I guess I'd have to understand "forward revisions" before doing more work on this module. Do the two approaches clash?

[docwilmot]

Do the two approaches clash?

Not really and perhaps I didnt try hard enough.

I guess I'd have to understand "forward revisions" before doing more work on this module

D7 could create multiple revisions of a node, but the current revision, the one seen by any user if the node is published, is always the latest created revision. Revisions are always "behind" or "before" the public facing node. So if anyone created a new revision, thats what the public sees automatically.

Forward revisions allows you to create "revisions" that are "forward" (not behind) the currently publicly visible one. So "forward revisions" allow you to have real drafts: you can have your editors, approvers, writing revisions by the dozen and yet the "story" visible on the site stays the same, until someone approves it to be the public facing version. Then "revise" it a dozen times again until youre happy and only then publish the latest version again.

Workflow, AFAICT, allows you to move a node between various "draft states" until someone publishes it.

It would be nice, if we could integrate the two concepts, so that even after it is published in Workflow, there is a UI to send it back to the draft states and have it sent around for approvals etc, until someone updates the current revision, and all new edits go live.

[stpaultim]

@herbdool To refresh your memory.

We added some cool APIs.
backdrop/backdrop-issues#4354

But, we never finished the UI to expose them.
backdrop/backdrop-issues#4355

[herbdool]

Thanks @docwilmot and @stpaultim for the info. I understand it a bit better now.

[herbdool]

Now I'm not so sure about this module. To be useful it would need to store workflows, states and transitions in CMI. That is possible but complicates things. Plus I can't figure out why someone would need to be able to add fields to a workflow. Maybe someone has an idea. I've got the basics working but I'm not sure if I want to spend too much time on it. After looking more at workbench_moderation it actually seems to be simpler to port (though it depends on drafty).

[docwilmot]

I think WBM seems to also be able to use the new revisions APIs as well.

[yorkshire-pudding]

I can think of use cases for adding fields to a workflow. Where the workflow is being used to handle a business process, then there may be additional information such as dates, people, references, events (perhaps you need a meeting to sign it off?).

I'm interested in this module, so would be happy to test if and when you get to that stage.

[herbdool]

@yorkshire-pudding it's already kinda working, but I don't intend to do anything more to it or maintain it. Not sure if @docwilmot will.

@docwilmot workbench_moderation is looking pretty promising. I've got it working locally mostly. Much simpler and I think it'll be easier to convert to CMI.

[herbdool]

Here we go: https://github.com/backdrop-contrib/content_moderation. It's mostly working. I renamed workbench_moderation to content_moderation because it doesn't rely on workbench, which could be ported separately.