How do i set default assignee and workflow in next-gen projects?

[Nikki Kim]

In Next-Gen projects, I have NO way of 

1. set default assignee 

- tried adding a rule to set assign when moved to To Do status in Kanban board. It only works when it is "moved to" To Do status. Not when an issue is created and "placed in" To Do status. 

2. assign a workflow to issues 

- previously, when created a project, there was auto-generated workflow for the project. I couldn't find it so I created a workflow and associated to the workflow scheme. Now, I can't find place to associate this workflow scheme to my projects. 

Next-Gen is great, but missing something should be very "default" for the users. 

[Joe Pitt]

An easy way is to use separate projects. Only allow a limited group of folks access to the 'test' project they can use as a sandbox. You can apply workflows, screen schemes, etc. by project so you can test anything in the sandbox without impacting the real projects. Then you can simply delete the test project and all the data if you want to. I always keep a test project in the production instance to test workflows and screen schemes. It is much easier than trying to reproduce the workflow in the production system. Export/import has limitations. We only use the test instance for trying out new versions and plug-ins.

[Svein Seldal]

If I create a test project and later delete it, does this cause cluttering in the db?

Because we are testing Trac and Buzilla imports, and the first run created lots of invalid users and the test-import projects and users were later deleted. My experience with databases is that nothing is really deleted, just deactivated/hidden. Thereof the fear of cluttered db's by doing multiple imports-then-delete cycles.

[AhmadDanial]

Hey there, Svein.

First and foremost, we definitely advice users to not have two instances connected to a single database (https://answers.atlassian.com/questions/15984/can-we-run-jira-on-multiple-application-servers) and yes, you are only eligible for the developer license when you are using the commercial or academic licenses.

In this case, you can do a project import and import it to a instance, not a fresh database. If you were to do this, you will eventually import the whole backup, not project specific. (https://confluence.atlassian.com/display/JIRA/Restoring+a+Project+from+Backup)

Mind you that you have to pay attention to every detail of the steps. It is important to ensure a smooth process. Good luck.

Warm regards,

Danial

[Svein Seldal]

I was not thinking of having multiple jira instances towards one db, so that's ok.

IMHO it's a limitation that we need to combine the experimentation and the production project into the same db. As a part of the experimentation you can (intentionally or unintentionally) change settings which you perhaps don't want to keep in a production db. That's exactly why you have a test sandbox to go wild. To be able to successfully evaluate Jira within the limited time we have, we really need to have both go-wild experimentation and real project activities. But we only want to keep the latter.

So if I understand it correctly, we can do the evaluation this way:

• Run the trial with the combined trial-and-error sandbox and the production project
• When trial is over, we can export the production project only. (What happens to issue types, workflows, etc.?)
• We decide to purchase Jira and install it on a production server on a blank db (to avoid cluttering from the trial experimentation)
• Import the production project

Would this be possible?