In jira, there is required fields when creating issues, Reason being one of them. I would like to know if it's possible to eliminate it and replace it with another field that does the same thing. Anyone else ever done this before?
It's possible to make almost any field not required, to set up a project so that that field doesn't appear in the issues' screens, and to create a custom field, but I don't see the "Reason" field in our Jira Cloud field list, so it may be a custom field already.
I'll warn you that proliferating custom fields makes administering the system more complex, so think about whether you can fit your process to the existing field. It's not clear from your question what exactly you want your new field to do differently from "Reason".
Related
I was asked to separate access to a particular Jira project by component. e.g. user "a" can see issues created for component "a", but not component "b". conversely, user "b" can see issues created for component "b", but not component "a".
I know that I can limit access to a particular project to one or more users, but I was unaware of a way to filter access to one or more users by component within a Jira project.
Is there any way to limit access to one or more people to a subset (less than all components) of a project?
I did a search for a Jira plugin that might offer this functionality, but did not find what I was looking for.
N/A
N/A
I don't know if that's possible by using a component (I don't think so), but there is an alternative approach which might be sufficient as well:
You can adjust the Browse Projects permission like this:
You can grant permission to a group custom field value. Then you could choose a custom group field (create one if not available) which will be evaluated on each issue. Then, if you create an issue and add a group to this custom field in that issue, only users from that group have access to view the issue. Take care that you remove the any logged in user setting for "Browse Projects", otherwise the group custom field does not have any effect. There is also a KB article here in Jira's documentation.
The first question is what are you trying to do? Why do you want to restrict who can view issues?
Jira has Issue Security Schemes that can do this based on setting the security level according to the component, or other fields. I'd use a custom create post function
But what happens when the component is changed? Now you have to restrict editing too.
I'm wondering how to assign two users to one task in JIRA. I took over a project that was set up by someone else. The problem is we are doing pair programming and we would like to keep track of time.
I dont think you can not actually assign two users to field assignee as it is built-in field.
You can create new required field e.g. pair-assignee and have pair tracked there. Here is a doc about how to setup a custom field.
By design, this is not possible as such - it's a single value field.
But there are ways around this limitation.
Since a number of people had this question, Atlassian has set up a page for the possible solutions/workarounds.
I'm configuring our JIRA in that I want to make a new field configuration to configure a new project.
I'm currently going through a lot of fields, and would like to know the following:
If I remove a field from a screen in the FieldConfiguration, does that affect only my field configuration, or everyone in JIRA using that screen?
I'm sorry if I cannot describe it clearer, but basically I want to know if I break anything by removing the screen links in my Field Configuration.
Reason: I have fields assigned to 20 screens and dont want to keep scrolling through this the whole time.
I assume you mean hiding a field from FieldConfiguration. Since removing fields is done in the Custom Fields section.
When you hide a field it affects only your specific Field Configuration (note than more than one Issue Type from multiple projects can associate with a Field Configuration, this is probably not your case, since your are testing a new Field Configuration. But just keep that in mind).
The action that "Hide" is doing is like "forcefully" removing that field from all screens associated with tickets which use that Field Configuration.
More data: JIRA Documentation
I'm customizing the Work Item Definition Schema for the 'task' work item in TFS Server 2012. I've created a new field for hold a CustomerReference value. It works as I expected, but I would like add a UNIQUE restriction for security. I'd like add a rule than it makes imposible create two workItems with sme CustomerReference.
I think that none of the rules defined here http://msdn.microsoft.com/en-us/library/cc339553(v=vs.90).aspx achieve my target.
Any idea? Thanks in advance,
As a last resort there is a way to write a custom plug-in that can enforce this server-side. See this link for more info on creating an ISubscriber plug-in: http://nakedalm.com/team-foundation-server-2010-event-handling-with-subscribers/
Unfortunately, the plug-in model doesn't allow you to prevent changes; but it could allow you to detect when somebody has violated the rule and react. For example, it could send an email off to somebody, and possibly clear out the CustomerReference field from the duplicate.
I want to write an application that assigns Fogbugz cases programmatically, how would I accomplish this? Is it possible to achieve this given any of the following scenarios:
The user enters text in my
application's input field and the
Fogbugz report is opened in the
browser where the "note" field is
populated with the text from the user
input
The fogbugz report is assigned to the
specified user in the application
without the browser even being opened
i.e. the report is stored directly in
the DB.
I'm planning to add default values to the other fields as well so I would assume the process would be the same for adding text to the "note" field.
You can do this with the Fogbugz API. See the heading "Editing Cases" for the specifics on how to edit a case (which includes creating a new one). It's a little complicated (or perhaps just oddly designed) but, as I remember, you basically have to call cmd=new if you want to create a new case, supply your text in the 's' parameter and set the ixPersonAssignedTo to the correct person. For an existing case, use cmd=edit.
This is possible both with a regular form posted to your Fogbugz installation and some server side code that calls the API.
You might want to write a plugin for FB and allow others to use it. (share it or sell it)