Allow to specify state for duplicated content

[alansemenov]

@Sneiwert commented on Tue Sep 17 2019

When copying an event it shows "ready to publish", but nothing has been edited or approved.

---

@Sneiwert commented on Tue Sep 17 2019

---

@alansemenov commented on Fri Sep 20 2019

@Sneiwert It's not obvious to me that this is wrong behaviour. When you duplicate a content that is "ready", the duplicate is also "ready". When you start changing the duplicate - which is what you most likely duplicated it for - then it will change to "In progress". Makes total sense to me.

Let's discuss this.

---

@Sneiwert commented on Fri Sep 20 2019

I see what you mean. But when the duplicate has an old event date from the past, it should automatically detect that this content has to be modified before being published. The copied content should be validated before it is showing "Ready".

---

@Sneiwert commented on Fri Sep 20 2019

I talked to @sigdestad about this, he knows the issue.

---

@alansemenov commented on Thu May 13 2021

Should most likely be fixed in admin API.

---

@ashklianko commented on Sat May 15 2021

@alansemenov we only send ids to duplicate, result is fully created on backend, so I believe it is a backend task

[sigdestad]

I'm thinking abou this. It makes sense from a user perspective - but we must discuss this more closely before we start any implementation on this task.

[rymsha]

We tried to forcibly change Workflow State in XP, but it causes issues. #9520 #9663
Bets solution would be to allow specifying State in DuplicateContentParams

[rymsha]

There are two issues:

1. workflow state is copied in duplicate (so ready state is copied, too)
2. to be able to specify workflow state DuplicateContentParams should have State param

we cannot "just" remove workflow state because default value is "ready"

[rymsha]

New implementation allows to specify WorkflowInfo just like content.create does
It is up to CS to set IN_PROGRESS.
By default nothing is changed