I work with several private projects. Recently I downloaded for evaluation the JIRA and JIRA Agile to control these projects. But I have two opensource projects and I would like to control the issues using JIRA. Is it possible have PUBLIC project (with several users) and PRIVATE projects (users limited to the license I have)?
I am interpreting the question request differently. Can Joao have two Jira licenses (opensource and paid) on a single instance of Jira? The answer is no since licenses are not additive and there is no way to associate a license with a particular set of users. He will need two instances of Jira.
The opensource license requirements would not allow the license to be used for commerical (private) projects.
I took that approach for www.vxvista.orgthat is open source environment and then use paid license for internal commercial projects. It is better to have two licenses and two environments. Please keep in mind that plugins are following the license you have installed on the instance in use.
Keeping both environments will facilitate the honoring of the free open source license that you are getting from Atlassian.
You can not mix the license type within a jira server
If you are using a JIRA Unlimited Users: Open Source License you may run into trouble with your paid plugin .
much simpler is to have two server , each one with the corresponding licenses (and security scheme) you can then just create an application link if required.
1 : there is open source licence for Jira Agile , Capture ..
you could create a custom permission scheme for your PUBLIC projects. You could add "Group (Anyone)" to same specific permission like Create Issue/Browse Project and so on at your convenience. After doing that, associate this new permission scheme to you projects.
Now, anonymous user can use these projects even if they are not JIRA user.
Be very very careful with that approach - if you do it, then ANYONE can use your system. Read only access is ok, but if you allow any form of write then
1) You won't have any record of WHO is writing
2) You WILL be spammed if you put your system on the internet
as you know, permission scheme let you define what anonymous users can do withinh JIRA.
In my opinion, for example, anonyous users could create issue and in order to trace who did it, you can add some custom fields such User Email/User Name as mandatory fields.
In order to prevent spam, you could also insert a CAPTCHA on issue creation (provided by third part plugin https://marketplace.atlassian.com/plugins/ELVAC.JIRA.JTools)
Yes, I know, that's what permission schemes are for.
This doesn't add anything to my point that you can't track anonymous users. So what if you provide a field for an email address? You can put rubbish in it. Jira will still show "anonymous did X". If you allow anonymous to make comments, then you'll get a string of comments made by anonymous and no way of knowing if Alice, Bob or Charlie made them.
I'll say it again - if you allow anonymous write, you have no audit/tracking log. There's no way around the fact that you are not going to capture who is doing things.
I'd never recommend using anonymous write without thinking through the full implications of not being able to identify activity in your system.
Captcha might seem like it would help, and it'll stop the casual spammer, but Captcha farming costs pennies nowadays, and there's several programs out there that are nearly as good as humans.
I would never allow anonymous write on a public system. It can, and will be, spammed.
Thanks Fabio. I believe that the best option is create two different instances - one for private projects and another for the open source and public project. That way I can leave the control design for reading, but for creating tickets I require the user to register.
Sorry Joao, we've got into a bit of a security discussion here which isn't quite related to your question.
Fabio's basic approach is the right one.
You basically split your users into two groups (obviously, you can get a lot more complex than this). You then set up permissions so that group A can see open-source projects, and B can see the others.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs