pkp/pkp-lib#9295 continuous publication implementation update

[touhidurabir]

for pkp/pkp-lib#9295 , second batch of PRs to update the implementation to

1. remove the previously introduced published column in publications table
2. introduce on the status column of publications table by introducing a new status PKPSubmission::STATUS_READY_TO_PUBLISH
3. update the publishing/scheduling workflow by combining multiple modal into one .

[asmecher]

@jardakotesovec, sending to you for review.

[jardakotesovec]

@asmecher I would prefer not to merge this version, and still make the adjustments to use existing form fields, and not creating new field which combines multiple fields.

Example I provided is available on these PRs..
#688
pkp/ojs#5049

[jardakotesovec]

Hi Touhidur,
thanks for the updates, I provided some feedback that should help to clean this up. Feel free to refer to my original example, which was done quite carefully and was done with good intentions to illustrate good patterns to fully take advantage of our composables and composition api.

[jardakotesovec]

In general custom logic for forms has been solved by creating dedicated component for that form.. But we can handle that once we would maybe migrate the whole form to client side.. Until than applying the custom logic here I think is fine.

Just to follow composable conventions which we use, is that the composable returns what might be useful - refs, computed properties and methods.

In this case you can return the initialise and call it when necessary.

const {initialize} = useWorkflowPublicationFormIssue(newForm)
initialize();

That improves the convention but also gives you flexibility when you want to do initial fetching.

I see that you decided to keep also the same logic server side, which is fine its bit of duplication but it help avoiding cascading request (fetching form first, and than trigering additional fetches) so thats good.

[touhidurabir]

decided to keep also the same logic server side, which is fine its bit of duplication

if we want to remove it, that would be very easy as well . just remove the server side code that build the fields and in the composable useWorkflowPublicationFormIssue remove the check of field existence as other parts are just same . Only one thing we need to figure out in that case is how to position the fields before/after certain field using the useForm .

[jardakotesovec]

I would be supportive of this.

To resolve the positioning - solution that we want to add to the useForm at some point anyway, is to introduce the same options as we have in FormComponent.php for $position.

It would go as new option, which is 3rd parameter to the addField* functions. We can address that separately as out of scope of this. Or add that option as part of the PR - both options are fine with me.

example would be

addFieldText('fieldName', {inputType: 'text',...}, {positionAfter: 'anotherFieldName'}

addFieldText('fieldName', {inputType: 'text',...}, {positionBefore: 'anotherFieldName'}

[jardakotesovec]

Hi Touhidur,
Its lot of changes, I tried to get through everything in detail.. let me know if something is unclear.

[jardakotesovec]

Any thoughts on this? I don't see FieldSelectIssue used anywhere.. so I am supportive to remove it.. and just make sure that the tests are passing.

[jardakotesovec]

Just small clean up - this does not need to be async function, right?

[jardakotesovec]

Just two clean up suggestions. I think its ready for merging.

Thanks!