I see the added value of having a separate Clone permission. Currently it can only be prevented by setting a status property for creating a new issue by blocking the create option. See: https://www.j-tricks.com/tutorials/permissions-based-on-workflow-status  ..... but this is an ugly workaround.

The ability to clear fields after cloning is desperately required. 

....which easily can be done by adding post functions for clearing fields on the create transitions of each workflow.
At the same time a "Clone post function" can help in this by selecting the fields that need to be cleared when an issue is cloned. 

• The ability to clear fields after cloning is desperately required. We use JIRA to manage our project, deployments, planning
• When the record has been cloned, it contains information for the old record that is not valid for the new record and thus take away all the validations we have put in place during an issue creation
• It leaves the system in limbo with no way of housekeeping
• The history is also retained and links which arent necessary are kept and data integrity is questionable
• It links the cloned epic automatically which is also not desirable by default

If editing (both on the Edit screen and inline editing on the View screen) was linked to a global action, like Create is, then we could not only have Validators to validate user input, we would also have post-functions like on any other transition. This would be especially useful to, for example, propagate field values to sub-tasks of stories of an Epic. We would even have webhooks to notify external systems of the change.

Note that the current issue notifications are not the same: they are triggered by any issue change, regardless of whether they were done manually, through the REST API, a post-function, etc.

Emre Toptanci, i completely agree with you. If we had at least the Validators, it would already be a huge step forward.

Having the option of using conditions and validations on Edit operation would introduce a hugely powerful and flexible feature. This will save us from defining tens of local transitions.

I would make this request a little bit more general.

At the moment links to not carry any semantics although the link names would imply that there is a logical relation between two issues. In the same way as workflows (and with that conditions, validators, post actions) can be assigned to any project, it should be possible to

• limit the listed links per project
• apply semantics to link types

This could be done using "Link schemes".

The clone action is just one example that implies a logic. We handle the cleaning of field values by using the "New" --> Status "New" transition and adding a few post-actions to clean up some fields.
However there are more default links that should carry semantics, for example duplicate. This could for example automatically follow the states of the duplicate master (if I as a project admin define it that way).

I agree with Kevin. I need to clear custom fields when an issue is cloned.

The ability to clear fields after cloning is desperately required. We use JIRA to manage our deployments - we synchronize information from another system into JIRA to track the status of these requests. When the record has been cloned, it contains information for the old record that is not valid for the new record. We would very mc like to be able to clear these fields on cloning.

Using Minyaa Suite plugin, you are able to perform such control on Edit operation by implement Global Actions.
See documentation and do not hesitate to Try Minyaa,

Vincent

I wrote validators to asure that the values for certain fields are entered in a given format. These validators avoid that the user enters wrong values during the workflow actions. But I have no chance to avoid that the user uses the edit action to enter invalid values afterwards. Therefore I need to do validation for the values entered during the edit operation.