I am working on a mobile app that will let users create a JIRA issue in the cloud. I can see that there is support for building AddOns but they seem to be only for the web.
How do I create an add on so that it will let users of my iOS app OAuth log into their cloud JIRA account and create issues?
Is this only supported for server instances of jira?
New to JIRA so any pointers are much appreciated.
thanks
bipin
From my experience, a Jira project is a unit which has its own release lifecycle, i.e. list of versions.
If things have the same release, it means they are shipped together, and thus probably need to be in the same JIRA project. You can use Issue Types to easily separate Bugs from Requirements, etc. in the same project.
If these things are not released together, they probably deserve to be in separate JIRA project.
For instance, think of publishing the release notes when a new version is released. You don't want to deal with 2 different projects at that point.
Thanks.
vice versa, in my case it would be neccessary to have sepatate projects because i want to release different apps at different points in time with different versions!?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, if you have different apps that are released separately, it is easier to create several projects. When you open the JIRA project of the app, you want to see all its releases, and not the releases of the other apps.
Of course, if you have several parallel branches of development (hot fix branch, service pack branch, main dev branch), do not create several projects for each of them! This would add a lot of management, moving issues from one project to another all the time.
For example, if you have a core product with independant plugins, you may want to create one project per plugin if they are released independantly. Or you may prefer to create a single project, if the plugins are released at the same time and they don't have an independant release number. But this decision is sometimes not as obvious as it looks... Try to think about what you want to appear in the "Fix Version" field on an issue.
Hope this helps!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
hi chrisi.
of course 2 seperated projects can be used..
if you decide to put all in one project it might get confusing to Layer 8.
i'd use components and some customfields to seperate these things in a single project.
but if you need more info have a look at
https://confluence.atlassian.com/display/JIRAKB/Using+JIRA+for+Requirements+Management
https://marketplace.atlassian.com/plugins/com.optimizory.rmsis.plugin.jira-rmsis
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
i forgot to make clear, that we are not talking about 1 requirements-prj and 1 development-project but more like 60 to 80 development-projects used by many dev-teams (ca. 15). in my point of view, the one-project-solution would eliminate the possiblility of a reasonable permission-management for the various dev-teams and it would of course be very confusing for the user.
i don't see any sense in having a custom field to differentiate projects if there is already the term "project" defined by jira. and if i layout my projects and applications in jira in a way that i have to define an additional custom field to to distinguish the individual applications there must be something wrong with my setup...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
true.
i guess setting up permission schemes will be inevitable.
just evaluate the rmsis plugin in a testing environment and see if it fits your needs.
then outline permissions and try to seperate those two kinds of projects as good as possible
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey there, chrisi.
Seems like the question that you have is general. If you were to ask my personal opinion, some of the best plugins that is a must-have include:
For requirements management, you can check the list here: https://marketplace.atlassian.com/plugins/app/jira?label=Requirements+Management
You can even review the list of all the softwares that are offered by Atlassian itself in the following link:
http://www.atlassian.com/software
It depends really on what you use JIRA for mainly since it is very vast and it covers pretty everything that you can think of.
Warm regards,
Danial
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
i would like to use JIRA the way i did't so far, without beeing limited here because i have to share my "namespace" (Versioning, Releases) with all the other applications which would reside in the project. but that would be the case if we go the one-project way. what about permission-management?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey there, chrisi.
Wonderful. As for the permission management, I think that the standard permission scheme should be sufficient for a standard JIRA usage. Unless you want to enhance the current one by developing plugins:
https://confluence.atlassian.com/display/JIRA/Managing+Project+Permissions
Warm regards,
Danial
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
thanks for the quick reply but that doesn't help much. the thing is, i don't think that the second scenario i described above (one-JIRA-project many applications and dev-teams) is standard JIRA usage hence the standard-permission-scheme doesn't apply.
please see also the new comments to the first answer
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.