I am new to JIRA.
Can somebody explain to me the meaning of the different schemes in JIRA; like issue security scheme, notification scheme and so on?
Helpful online resources are also highly appreciated.
A notification scheme maps email notifications to various events. For example: "When a defect is assigned, send an email to the assignee."
A Field Configuration Scheme maps Field Configurations to issue types.
A Screen Scheme allows you to choose which Screen will be shown to a JIRA user when they perform a particular issue operation.
An Issue Type Screen Scheme associates a Screen Scheme with issue types,
An Issue Security Scheme determines who can and cannot see issues.
A Field Layout Scheme allows you to configure which fields are visible and/or required fields for a given issue type on a per project basis.
For more details, check the Jira documentation.
I really appreciate the detailed explanations available at "The Grey Blog":
http://thegreyblog.blogspot.com/2010/11/atlassian-jira-configuration-tutorial.html
Most parts of JIRA configuration can be set up differently for different projects. Some things, like custom fields, can be also set up differently for any pair of (project, issue type).
The schemes are the means to configure these per-project/per-type configuration pieces, with probably reuse of one configuration among different projects.
For example, issue security feature allows you to set up options for Security Level field and limit issue visibility to certain users based on the value of that field. Issue Security Scheme contains definitions of those options and how they limit issue visibility.
So you first configure Issue Security Scheme (may be more than one) to define that piece of configuration, and then you can assign each project one of the available Issue Security Schemes (or neither one), thus applying those pieces of config to the issues in that projects.
Jira enables flexibility to customize issue types, fields, workflows, screens, permissions, security and notifications through schemes. You can create, assign and reuse these schemes to your projects based on your needs. These schemes are assigned to project's related schemes like plug and play.
Notification scheme -- You can configure notifications like email for the issues you create or issues assigned to you and any change in status
Field Configuration scheme -- Scheme used to configure fields.. You can set based on project. You can add more fields and add to particular scheme. You can even set restrictions (lets say if it is mandatory field or not)
Permissions scheme -- Used to set permissions for the project. You can name like Admin or general user and give what they can do
Screen scheme -- Used to add fields for a particular screen.
While others answered most of the points, I would like to throw some light on Issue Security Scheme.
This is the most versatile scheme where you can restrict accessing certain issues by the security level user has.
With combination of the permission groups and issue security features, you can do almost anything in Jira from a workflow point of view.
Well schemes are sort of mapping entities.
They contain the units, like workflows,screens,issue types.
Schemes will define how a project decides which unit to use for which issue/operation.
This is of course a high level explanation.
Best bet is to start experimenting with 1 scheme, let's say screen scheme. Once you get the hang of the scheme entity, every other scheme will become understandable.
Related
I want to make it so certain users can view and/or comment on specific issues, but not all issues. I was reading that I can use Issue Security for this but I'm not understanding one thing.
My understanding:
Enable Issue Security to a project
Issue security scheme defined with who can view/comment on issues by specifying Jira groups in the Issue Security settings:
group ABC can view
group DEF can view + comment
People get added to those groups
But, what controls the issue they can access?
If Joe is added to group ABC, what says they can view issue 123 BUT NOT issue 456?
Every issue has a security level, which can be chosen among those that are available in the Issue Security Scheme associated to that project. I suppose you haven't created them yet: then you need to edit the Issue Security Scheme and add all the security levels that you need. More info on security levels here.
In your case, if you want a simple model you could call the security levels something like "Public" and "Restricted". Issue 123 is set to Public, issue 456 to Restricted, and to view restricted issues you must belong to group DEF, so those that are only in group ABC cannot see them.
If you want to manage multiple customers/suppliers and keep things separated, you can create a group for each company, and a security level for each: visible_by_company_A, visible_by_company_B, and so on. Then each security level is configured so that they are visible only be the right groups/roles, and then users must be assigned to the right groups or roles. A user could belong to both groups, or to just one (or to none).
The catch is that each issue can have only one security level, so if you need an issue to be visible by both company A and company B you must create a specific security level for that, like "visible_by_A_and_B", and this doesn't scale well. But in general this rarely happens (at least in my experience), and I've never needed to create too many levels.
One last thing: users who want to set the security level must have the "Set issue security" permission, make sure they have it.
I'm using Settings.bundle for few configuration settings for my app.
Now I'm searching for a solution to hide all, or even better, some configuration parts for the casual users. Only a 'admin' should see and edit these fields.
Is it possible to check for a password before showing the settings-properties?
If not, what could be a suitable solution? (new view controller with secret gesture or button?)
Thx in advance!
You won't be able to do anything special in the settings bundle. It's static, whatever you compile is what all users will see. If you want special behavior, there are two ways to do it:
Put it in the app itself and only allow the user access if they have the right credentials. A secret gesture could work too, but is a little dangerous because users may accidentally find out about it.
Use a different target/scheme or compile-time conditionals (using #if) to build two different versions of the app, one that does include the special configuration and one that doesn't. Personally, I would go for this option, but it may be a little harder initially.
I would like to customize a Work Item Type in TFS to automatically set the Assignee to a particular role. For example (to compare to another Issue Tracker), in JIRA the default Assignee is the Project Lead (so that any ticket not otherwise assigned, gets automatically assigned to whatever person is designated in the role of Project Lead). Can I do something similar in TFS?
So, I realize that one difference between JIRA and TFS is that TFS doesn't (to my knowledge) have the concept of "Roles". The closest thing to that is "Groups", but unlike Roles, Groups can have multiple people (which may be the restricting factor in this problem). I know how to configure a TFS Work Item so that only a certain Group gets listed in the "Assign To" field, but I would like to go a step farther, if possible, and create a custom Group with just one member (e.g., "Issue Guru") and then set up the work item to get automatically assigned to that person.
I'm trying to replicate the Jira functionality here, and maybe there is just no good way to do it in the TFS framework. Any suggestions?
There's a Step by Step Guide on Ivan Fioravanti's Blog for enabling it.
If you are unfamiliar with customising Work Item Types, have a look at the following links (stolen from Grant Holliday's blog).
I never tried this in production but here is something I tried quickly and it seems like it could work.
You can set the default value to a Group by editing work item template in template editor.
Just select Assigned to field and add a DEFAULT rule like shown in the image below.
This will also require you to create one or more groups (one global or maybe one per project). Once you set this up you won’t have to make any updates in the future but only manage people who are in the groups.
For example playhaven allows to create a concrete set of applications to display. Even if they don't belong to me.
Is it possible to do the same with Flurry? It is hard to understand anything with their awful design. As I understand I must create "a new campaign" but it doesn't allow to advert with a zero budget/price
Are you looking to serve direct sold ads using Flurry? If yes, you can create an 'Advertisers' campaign under the Publishers tab, and set the value in the price field as $0.01. There is a bug in the system which doesn't allow the value to be $0.00. However, since this value is only for your self-reporting purpose, it wouldn't affect ad serving.
For any further queries, please write to support#flurry.com.
(Full disclosure: I work in the Support team at Flurry)
I have got a passcode all up and running (4 digit login) and i need to get the option working so that the end user can assign their passcode in the settings.bundle.
At the moment, which I know is not ideal, I have a simple PSTextFieldSpecifier where the user can type in 4 numbers and login with those.
For reasons of security and having no control of what is typed into that field it will not do.
Where do I need to look to set up the screen for the passcode to be set up?
Cheers jeff
The settings bundle should be used only in a limited set of use-cases (as users often don't change individual app settings for months at a time, or not at all), and as such, limited control is given to developers as to the settings bundle and it's default controls. You'll need to use some kind of in-app settings, which are very easy to implement, and allow easier and faster access to something as variable as a username-password association. CocoaControls hosts a wide variety of simple frameworks and templates for in-app settings. I recommend you start your search there.