|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Jed Wesley-Smith - 10/Jul/03 07:14 PM
Custom fields can already be scoped to just a particular Project or Issue Type. This has been available since at least 2.1 and probably before. See Administration -> Add Custom Field -> Field Scope
I do not mean having issue fileds scoped for a particular project but custom fields that you would provide a value when creating (or updating) the project info.
From JIRA's point of view, the Project Lead is the Default Assignee. The field serves no other function in JIRA.
Perhaps what you need are arbitrary fields on the Project object, to store project metadata? For that see JRA-1991 Yes!!! Custom fields on issues work beautifully, but it should also be possible to create a custom field for the project itself. E.g., Customer, Product Manager, etc. That way I could create custom views for business people in my organization based on attributes of the project rather than the issues.
We'd also like this. We'd like to add a field on the project for QA Lead and then have our work flow automatically assign an issue to the QA Lead for a given project when the issue is Resolved.
Objective Corp also supports this requirement.
This might be clarified with a summary of: Metadata for Projects, Versions, and Components using the existing Custom Fields mechanism We would like to be able to include various fields on the 'edit' pages for each of these three key entities. The Project Summary page would be extended to show the project metadata. The ability to determine default Q/A lead, doc lead, default developer lead, default PM for each step of the workflow is something my users seem to expect to be able to do. Adding custom fields per project would go a long way towards this without requiring me to add large chunks of custom code. What is certain is that the ability to specify default users by roles per project is needed if Jira is to gain any additional traction in my company.
Of course, if a project custom field is added which is a "role" type, it would also be expected that the role type would be visible on email notification creation screens, filter creation screens etc. Another ability that custom project fields would provide would be to attach default project codes per project so that cross-charge time reports could eventually be made with billing codes (in our case, billing codes = project code + customer code) Custom fields for Projects are an enabler for a potentially large set of new features. Same for us, we really need this new feature.
This would be handy for us as well so that we could show the budget for an entire project as well as the tasks within.
Our company would also benefit a lot from this feature and I think I have a good chance to convince our company to buy the Enterprise Version of Jira if we could add custom fields to a project. Adding artefacts and other information for a development process to a project would make the work more agile. In my opinion one could put process information to Jira and not to documents. This makes
it more handy and changes will be visible immediately by all people. It would be a significant Project Management feature for Jira. Do you have some scheduling information about this feature? It would be really nice to have a status information about it because for us it's a "go" or "no go". Thanks in advance for any further information. Yes, this is a REQUIRED feature. I tried my hand at it by looking around the JIRA source, I use 3.4.2. I wanted to have "Subprojects" just like "Components". I could progress to some extent and then got stuck. Here is what I did:
1. Since I Subprojects would new entity, I located the entitymodel.xml and entitygroup.xml files and added relevant entries by copying entries for components and modifying. This resulted in my database having a table called "Subprojects" and the fields (table columns) same as those for Components 3. Then added relevant JSPs such as AddSubproject, DeleteSubproject etc. After compiling the created classes I restarted JIRA. Now when I go to "Administer Projects", I can see a table very similar to Components table (I had added some 6 entries to Subprojects table programmatically) My problem then started that Add, Delete, Edit links are not working. I think a few more classes are required Can you tell me what more classes need to be created/modified? Sudhir,
Good effort, but I think you're taking the wrong approach. The 'component' table is already obsolete, and we should replace it with a predefined custom field under the covers. It is not something worth emulating. In any effort to implement this, storing and updating is only 10% of the work - the other 90% is integrating the new feature in with the rest of JIRA (eg. searching, reports). A large step towards satisfying these use-cases has been taken with Roles in JIRA 3.7 (see the release notes
 ).
In 3.7 can create a Role called "QA Lead" (for example), and assign a different user to the "QA Lead" role for each project. Then the role member(s):
Things not yet possible:
If your use-case could be met by implementing something on top of 3.7's Roles, please vote for the relevant issue, or add a new issue. Yes Jeff, I agree that whatever I did was just about 10% of required. this is why I asked for help.
Nevertheless, if Components is obsolete, do you suggest I should upgrade to 3.7 from 3.4.2? Or should I wait for the custom field under the covers that you mentioned? My users are hitting me for this project level fields. Some of them even say that they need to create 100s of subprojects every month. For code review etc they want to enter some information like Customer Name at project level once, so that it can be used in all review reports. In short, this is a very much needed feature. Please help how we can achieve such things, maybe by upgrading or whatever. Hi Jeff,
Wish you a very happy new year! I tried downloading jira 3.7 and I could find Components field is still available. You said its obsolete, but its there. I could see roles as the new addition, which is very much helpful. Regards, Sudhir,
Sorry for the confusion - I meant "obsolete" in the implementation sense, in that components could be better stored as custom fields are, rather than as a separate table. Please can you mail jira-support@atlassian.com, describing your use-case. I don't see how sub-projects relates to the subject of this issue, which is custom fields per project. Cheers, Jeff,
Subproject is a field required at the project level. We need to define subprojects under a project, just like we do components. Then the user should be able to select a subproject while logging an issue. The required functionality is exactly like components, so that the project lead can modify the list. Regards, Sudhir, can I request that you open a new ticket for this subproject stuff?
This is off-topic for this issue; it tracks requests for: Metadata for Projects, Versions, and Components using the existing Custom Fields mechanism Please refer to my post of 18 Nov 06. This is very different from role-restricted fields on a ticket, and unrelated to project hierarchy. Jeff, may I propose that you retitle this ticket accordingly? Hi
The costum fields for Projects are so important for my department that we have sent a order for a change request to the cpteam@atlassian.com. We use Jira together with a external database and has for the moment just added extra columns to the project table (not a durable solution) because we use Jira together with a billing system (the extra fields on project are e.g. Billing price, ref to our billing system, fixed/time material indicator and so on). I hope that while my company are willing to pay for this extra functionality atlassian would made the change public available? best regards Johnny Thomsen > This is off-topic for this issue; it tracks requests for:
> Metadata for Projects, Versions, and Components using the existing Custom Fields mechanism No, that is JRA-2980. This issue is tracking "Custom fields for Projects". From what I can tell, all coherent use-cases expressed have been solved by roles in 3.7, or are covered by JRA-11611 and JRA-11841, and this issue should be closed. If anyone has a clear idea of not just what custom fields a project could have, but how they could be integrated into JIRA, please add your use-case here. For instance, storing a Billing price against a project is of no use to anyone unless it is integrated into reports, or searching, or something. Jeff,
Here are some project level detail we would have liked to store for our projects: The ability to define meta items and be able to search and generate reports would be fantastic. If JRA-2980 were done, then this would be a moot issue since custom fields could be added to most domain objects within Jira. Don > The ability to define meta items and be able to search and generate reports would be fantastic.
What reports searches would you like to be able to do? How would they involve these project fields? Here are some things that I was ask by our PMO office to do for these projects (of course assume the normal variations of these).
Generate a Report of all projects who have issues with a risk factor (we use the risk matrix plugin) greater than some value and be able to filter by one or more of the other project factors (e.g., department, category, owner, etc). Generate a Report of all projects for one of the meta fields (e.g. all projects for a given owner, sponsor, etc) Generate a Report that shows the status of all projects based on unresolved issues or remaining work (given you use the work tracking functionality) and filter by one or more of the meta fields. Generate Reports that show counts of projects based on meta field critiera. Also, they wanted to use some of these fields in the workflow scheme definition associated with the project to do routing or different behavior. From the beginning of Jira I am missing one specific project attribute, which is project status. A project in general terms has the characteristics of a temporary organization that goes through some custom defined phases, and which after some time will be finished, and should be archived. So custom fields could may be help here:
DivX would like project properties with the intent to shortcut certain parts of a workflow depending on the project. This would also require an addition to how Conditions are handled for transitions (and would probably also be useful for Validators, and any other similar palce where nested conditions are used).
For instance, how about a QA-Verified property set on the project, that indicates whether or not the QA portions of the workflow are relevant for the project. Then you could optionally display the transitions "Close bug" (if QA-Verified was not set) or "Submit for QA" (if it IS a QA-Verified project). This allows you to create a robust workflow and optionally turn on or portions of it depending on the needs of that project, without having to manage a bunch of seperate workflows and not having to do a bunch of work when switching a project that's in development to one which now needs to be QA verified. I might try to code this. Can it be done as a plugin? Or should I modify code of jira core?
Can you point me some guidelines? Thanks! I think you need to modify the core. I tried doing that, by copying the classes related to components and modifying them. I ended up at a point where I could see a list of subprojects in the same way like components, but hit the roadblock with a third party class which needed modification to proceed further.
Regards, A great limitation on the customer reports that I create is that I can only use the data that JIRA wants to store. I'd really like to be able to save the following additional information on JIRA so that my JIRA custom reports would really work:
1) I'd like to specify the amount of person hours budgeted for a version/project. I'm sure many other people out there have their own requirements too. The point is, JIRA's extensibility is hobbled by the inability to add custom fields. We don't expect Atlassian to add on the specific fields that each of us would like - that would really pollute the domain model, and make things lose their shape. So the per-installation custom fields solution seems to me to be an elegant solution. If you add up the votes on this and JRA-2980 (and the many duplicates that are out there) you can see this is a highly sought after piece of functionality. (Incidentally - do you guys have a way of aggregating the unique votes for a cluster of duplicate issues? This would really help you see what your customers really want). | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
New Feature
Open
Major
Custom fields for Projects
