This is an old entry - re-added because of a problem with redirects, sorry.
It’s not possible in JIRA to create an Issue Security Scheme by issue type. For instance, you may want that defects should default to Private, and enhancements should default to public (or none). You might expect that issue type security scheme would be a mapping of issue types to issue security schemes (in the same way as Field Configuration Schemes), but unfortunately not.
There are two ways to get round this, one using Javascript, one with a post-function.
Continue reading ‘Setting issue security level by issue type’
Introducing an utterly unglamourous plugin - the "Properties Manager". This allows you to browse and edit the propertyset on most jira "entities". Depending on the amount of additional work you are willing to put in, this could be a partial solution to JRA-1991 and JRA-2980.
It's probably best to describe this by way of a few examples. Say you wanted to assign a cost centre to each project. Using this plugin you could export the list of projects, then add the cost center column, then import. Why is this useful? You could then display it on a custom field for each issue in this project (when the custom field is available), or query for all projects with this cost centre (when the searcher is available).
Continue reading ‘Using Properties in JIRA’
For a long time I’ve been meaning to rewrite the “groovy runner” plugin so that groovy wasn’t a requirement, and having found myself with some unexpected but welcome time on my hands I have finally done so.
Continue reading ‘Script Runner JIRA Plugin’
I was keen to get my grubby mitts on the JIRA 4.0 beta to see what JQL (jira query language) was all about… this is my first test-drive, I haven't read much of the release notes or the bug reports, so I'm probably way off on some of this.
Continue reading ‘JIRA 4.0 Beta Test Drive’
Over the last few months JIRA performance has tanked, but gradually. Difficult to think of any particular inflexion point, just more users, projects and issues.
I had a number of changes I had in mind to help:
- Application server
- DBMS type and location
- Caching for static content
- Reducing numbers of projects, groups etc.
- Optimising indexes.
- Turn gzip compression on.
- Memory and garbage collector settings.
- Bypassing the apache reverse proxy and going direct to Tomcat
- Use AJP13 connector instead of (as well as?) ProxyPass.
BTW, if you're looking for the instruction on where the "go-faster switch" is and can't be bothered to read the following, I'll tell you simply that you should replace the group jira-users in your roles or permission schemes with Anyone. If you're not using that then hopefully there will be something else of interest here, if only how to set up a simple load test to get some figures.
For the record our numbers at the time of testing are:
Issues 112897 Projects 475 Custom Fields 505 Workflows 239 Users 7613 Groups 698
Continue reading ‘How to make JIRA 6 1/2 times faster’
This plugin allows an administrator to impersonate another user, i.e. to
become that user in jira, without knowing their password - which is often
impractical if authentication is handled by LDAP.
Impersonation is useful for administration of shared filters, shared
dashboards, double-checking a user has permission to do an action etc.
The implementation is surprising simple, so simple in fact that I doubt it
will work in all circumstances. So far I have only tested on Jira 3.12.2
and Jira 3.13, with the DefaultAuthenticator and also an SSO solution that we use.
Installation
Drop the jar file: jira-plugin-switchuser-09.jar in to WEB-INF/lib and restart.
Note: This is compiled with Java 5 so you must be using a Java 5 or above
JVM. If you are still on 1.4 consider upgrading or compile the source yourself.
Usage
In the Administration page, under “User, Groups & Roles” you should see a new
link “Switch User”. Further details are on that page.
It’s not possible in JIRA to create an Issue Security Scheme by issue type. For instance, you may want that defects should default to Private, and enhancements should default to public (or none). You might expect that issue type security scheme would be a mapping of issue types to issue security schemes (in the same way as Field Configuration Schemes), but unfortunately not.
There are two ways to get round this, one using Javascript, one with a post-function.
Continue reading ‘Setting issue security level by issue type’
We have around 250 projects in JIRA, and the list of projects was becoming unmanageable when creating an issue, and in the issue navigator. I modified the templates so it groups them in to “my” projects, versus “other” projects:
Continue reading ‘Categorising Projects in the JIRA Project Picker’
BTW - sign-up to the blog is currently not working, so you cannot comment.
This is an attempt to deal with something I’ve mentioned previously, and is JRA-5705:
The problem I have with conditions, is that when a condition is failed, the transition is not displayed. This can lead to confusion for users - “I’m sure I saw that action the last issue I looked at, and I think I’m supposed to resolve this, but the link isn’t there”… followed by a support call.
Ideally if a condition is failed the link should be present but disabled… when you mouse over it it could you give you some explanatory text, eg “Cannot resolve because this issue depends on issues that are not resolved”. You could provide that message as a parameter in the condition.
I had a bit of a monkey around with the code and came up with this:
Continue reading ‘Showing Unavailable Actions’
BTW - sign-up to the blog is currently not working, so you cannot comment.
I’m trying to make our installation JIRA as self-supporting as possible. This means things like using SSO so there are no separate passwords for users to remember, and of course forget, and automatic creation of users on their first visit to jira. Of course, this is only possible for sites whose users are all internal.
Something else that we need to do is deactivate users who have left the firm. That’s not for security reasons, but to:
- keep the number of users in jira-users below the soft limit for the ajax user picker - 5000.
- help keep drop-down lists like assignee manageable, project managers won’t remember to update the roles for their project when someone leaves.
- keep tabs on which projects are active - eg if there are no projects admins for a project, perhaps it’s time to close that project down or assign someone else.
- and regularatory reasons - we need to confirm on a periodic basis that each user should still be members of their roles - the fewer the active users, the easier that is.
The logic is simple enough - for each user in jira-users, work out if the user should be retired, if so remove them from all groups and roles they are in.
Continue reading ‘Deactiveating Old JIRA Users’
