View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003317 | mantisbt | custom fields | public | 2003-08-26 23:32 | 2019-04-07 13:31 |
Reporter | joakimwg | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | acknowledged | Resolution | open | ||
Summary | 0003317: Add custom field to all projects | ||||
Description | In our installation we have several projects, when adding custom files I wanted them to apply to all our projects. Currently there are no way to assign a filed to all projects, this have to be done in project by project. The attached file adds a new button in "manage_custom_field_edit_page.php" that lets you to assign a filed to all projects. The file is a diff against v.0.18.0rc1, can someone have a look at it and apply it if it look ok. | ||||
Tags | patch | ||||
Attached Files | custom_field_all_projects.patch (2,872 bytes)
diff --git a/core/print_api.php b/core/print_api.php index 6a36002..5eb6562 100644 --- a/core/print_api.php +++ b/core/print_api.php @@ -493,10 +493,11 @@ function print_note_option_list( $p_user_id = '', $p_project_id = null, $p_thres * @param bool $p_include_all_projects true: include "All Projects", otherwise false. * @param mixed $p_filter_project_id The id of a project to exclude or null. * @param string $p_trace The current project trace, identifies the sub-project via a path from top to bottom. + * @param bool $p_show_disabled Defaults to false; set to true to include disabled projects in the list. * @return void */ -function print_project_option_list( $p_project_id = null, $p_include_all_projects = true, $p_filter_project_id = null, $p_trace = false ) { - $t_project_ids = current_user_get_accessible_projects(); +function print_project_option_list( $p_project_id = null, $p_include_all_projects = true, $p_filter_project_id = null, $p_trace = false, $p_show_disabled = false ) { + $t_project_ids = current_user_get_accessible_projects($p_show_disabled); project_cache_array_rows( $t_project_ids ); if( $p_include_all_projects ) { @@ -512,16 +513,16 @@ function print_project_option_list( $p_project_id = null, $p_include_all_project echo '<option value="' . $t_id . '"'; check_selected( $p_project_id, $t_id ); echo '>' . string_attribute( project_get_field( $t_id, 'name' ) ) . '</option>' . "\n"; - print_subproject_option_list( $t_id, $p_project_id, $p_filter_project_id, $p_trace, Array() ); + print_subproject_option_list( $t_id, $p_project_id, $p_filter_project_id, $p_trace, Array(), $p_show_disabled ); } } } # -------------------- # List projects that the current user has access to -function print_subproject_option_list( $p_parent_id, $p_project_id = null, $p_filter_project_id = null, $p_trace = false, $p_parents = Array() ) { +function print_subproject_option_list( $p_parent_id, $p_project_id = null, $p_filter_project_id = null, $p_trace = false, $p_parents = Array(), $p_show_disabled = false ) { array_push( $p_parents, $p_parent_id ); - $t_project_ids = current_user_get_accessible_subprojects( $p_parent_id ); + $t_project_ids = current_user_get_accessible_subprojects( $p_parent_id, $p_show_disabled ); $t_project_count = count( $t_project_ids ); for( $i = 0;$i < $t_project_count;$i++ ) { $t_full_id = $t_id = $t_project_ids[$i]; diff --git a/manage_custom_field_edit_page.php b/manage_custom_field_edit_page.php index dea1168..f3cc1a4 100644 --- a/manage_custom_field_edit_page.php +++ b/manage_custom_field_edit_page.php @@ -260,7 +260,7 @@ </td> <td> <select name="project_id[]" multiple="multiple" size="5"> - <?php print_project_option_list( null, false ); ?> + <?php print_project_option_list( null, false, null, false, true ); ?> </select> </td> </tr> | ||||
This patch is huge! It seems that you have used a text editor that changed the formatting or something. Unfortunately, we won't be able to process it. As for the feature, it sounds good. Following are some issues that would be good to clarify:
|
|
I agree with the feature request to have global custom fields the same way we have global categories. I haven't reviewed the patch and it is likely to be out dated. |
|
any progress? |
|
Just to confirm (10 years later): it would still be great to have this feature. |
|
Adjutant, patches are welcome. It all depends on priority and a developer or community member deciding to spend their time on a specific issue. Submitting a patch is always a good idea, as it increases the chances of improvement eventually making it into MantisBT core. All contributions are welcome and greatly appreciated. Patch submissions can be made in several ways. In the order of preference:
Kindly avoid to upload entire modified PHP files. Please make sure that your submissions adhere to our Coding Guidelines [2], if they don't your patch might be rejected. [1] https://github.com/mantisbt/mantisbt |
|
atrol, I understand - thanks for the pro-active advice and pointers. This case seems like an expected feature that someone who is familiar with Mantis development, could easily add with minimal effort, but an uninformed user would have to spend a whole day with. Also, this is from the perspective of a layman (in terms of mantis). |
|
Must be a joke. Maybe you are not aware that this is just 1 of about 2100 open issues. |
|
Thanks, you're correct. I am completely ignorant in this regard. (I must admit, I see no problems with any sort of (self-explanatory) assumptions that would be required, especially those already mentioned in 0003317:0005016). I would love to research and analyse every last one of the 2100+ open issues you refer to (I really would) - but I believe my practical contribution to others (altruistically) in an area in which I am skilled will be exponentially more efficient. Indeed, I am aware of the selfless contributions of others to the mantis project, and am baffled by your implication that I didn't think about it. I am further distressed that you don't realize that I'm trying to make mantis better by (1) providing input in the first place and (2) suggesting the most efficient method. I realize that you have to deal with many selfish free-loaders, but would also like to inform you that mantis is not the only free community initiative in the world. I contribute in a way which is most effective because of my knowledge and skills - if I cannot also help others to do the same in their area of expertise (mantis) then I will retract my comments. |
|
Please keep in mind that I am no native English speaker and my English skills are quite limited to technical stuff. What I wrote is nothing more than pure facts. Again: ANY contribution is welcome. I hope you understand what I would like to say and you don't understand it as something that is unfriendly or attacking. Let's finish the discussion at this place, as it doesn't help to resolve the issue. I recommend to write to our mailings lists and/or forums. If you get the feeling that MantisBT is not the right issue tracker for you, use another one. |
|
Maybe there is also a misunderstanding about the feature request itself. The original reporter wrote: "Currently there are no way to assign a filed to all projects, this have to be done in project by project." vboctor wants "to have global custom fields the same way we have global categories" which is quite another story. Furthermore joakimwg wrote "... adds a new button in "manage_custom_field_edit_page.php" that lets you to assign a filed to all projects." The big difference might be: One approach is nothing more than a button that assign a custom field to all existing projects (which is no longer needed as the multiselect is more powerful). |
|
I appreciate your time to clarify the issue and for providing this support. The issue summary and first line of the issue description accurately describe the desired feature. To further clarify: |
|
I am still not complete sure that we are talking about the same thing. Do you want an additional button "Link Custom Field to all Projects" right beside the existing button "Link Custom Field"? |
|
If I could select all projects and push "Link Custom Field" that would work fine. However, the list does not display enabled sub-projects whose parent projects are disabled (more specifically, it does not display disabled parent projects, even though one or more sub-projects are enabled). An alternative would be to enable all relevant parent projects, link the custom field, then disable them again. But then one might as well just go to each sub-project and add the custom field manually (as I have already done). Agreed, if all projects can be displayed in the list, then there is no need for an additional button. |
|
While it may make sense to include disabled projects in this list (and in fact would technically not be overly complicated to implement), your setup
strikes me as odd. I'm not sure why one might want to do that, since effectively the subproject becomes hidden and can't be selected from anywhere else in Mantis (e.g. filters, reporting issues). Maybe you can explain the rationale / business process behind this ? |
|
Disabled sub-projects are visible (selectable) in the main project selection combo box, even if parent projects are disabled. We have several parent projects, each with multiple child projects. Mostly it does not make sense to raise ITR's on parent projects, but on the sub-projects themselves, therefore we specifically disable the parent projects and enable only those sub-projects that are currently active. |
|
Really? Not for me (see screenshot_20140206.png). What version are you using, and was it customized ?
In that case, may I suggest as an alternative approach, to either
|
|
For what it's worth, I attached a patch which should display all projects in the custom fields page. I have not done much testing though, so use at your own risk. |
|
Yes (see admin_vs_user_projects.jpg), but after investigating I see although the project is not listed for the administrator, it is listed for the user (since the project hierarchy depends on the user's rights). I'm using 1.2.14, with four plugins jpgraph, MantisCoreFormatting, MantisGraph and XmlImportExport.
That is an excellent suggestion and resolves my issue. Thank you. |
|
Thank you also for the patch - I will have a look. |
|
I think I get it now - you seem to be using the so-called "extended project browser" ($g_show_extended_project_browser = ON; in your config_inc.php). FYI this option will be removed in future version of MantisBT (1.3) Anyway, glad the private project trick fits your requirement. |
|
Appreciate the warning. Either way, the original requirement is resolved both by patch and by alternative settings. Thanks. |
|
Just putting in a vote for this feature. It could be implemented in the same way as global categories as suggested above or if you ever look into setting defaults for project configuration it would work that way too. |
|