Feature #5358
openShare Issues Categories for sub-projects
0%
Description
I think that should be possible to set each category to be use to all the sub-projects.
I use a top-level projects as a help desk, and the sub-projects as departaments. And I have categories related to many areas like
- Hardware - Printer
- Hardware - CPU
- System - Intranet
- System - Redmine
.... A LOT MORE
If I could only say that these TOP-LEVEL categories can be used in sub-projects, wold solve my problem.
Files
Related issues
Updated by Enderson Maia over 14 years ago
I was making the search for sharing categories, but when searching for inheritance and other terms I found the ticket #1278, #2521
They talk about a way to make categories global or default, what is different form my suggestion.
I can see 3 different ways to solve the problem that is common in my and the other requests:
- Enable copy of Categories between projects (http://www.redmine.org/boards/2/topics/4992), a little manual, but less than typing.
- Enable sharing of categories for sub-projects. On the parent project, I should select what category to share with sub-projects.
- Enable inheritance of categories. On the sub-project I could activate the inheritance of all/some parent-project categories.
- Use the same behavior of Version sharing from release 0.9.3.
Updated by Enderson Maia over 14 years ago
Enderson Maia wrote:
...
I can see 3 different ways to solve the problem that is common in my and the other requests:
...
I mean, 4 (four) :)
Updated by Marton Danoczy about 14 years ago
Updated by HU an almost 14 years ago
+1
even a global issue category feature is also pretty useful, just like the target version can be shared to all the projects
Updated by Daniel Neis Araujo over 13 years ago
As noted by Aurélien LAJOIE, in #4195 , i think this should be implemented as version sharing (#465).
Updated by Daniel Neis Araujo over 13 years ago
Hello, i am attaching a first version of a patch to adapt the code from version sharing to issue category change.
Still needs review and tests and would be good to implement some tests also...
Hope you like.
Updated by Daniel Neis Araujo over 13 years ago
- File redmine-5358.diff redmine-5358.diff added
the patch
;)
Updated by Daniel Neis Araujo over 13 years ago
Hello, this versions of patch applies to master and seems to work. I've made some navigations tests and things seems to work.
Any help in test/refactor the code is appreciated =)
Updated by Chris Darts over 13 years ago
I just tried to run this patch on Redmine v1.1.1 and received the following error message:
patching file b/app/controllers/issue_categories_controller.rb Hunk #1 FAILED at 25. 1 out of 1 hunk FAILED -- saving rejects to file b/app/controllers/issue_categories_controller.rb.rej patching file b/app/helpers/projects_helper.rb Hunk #1 FAILED at 105. 1 out of 1 hunk FAILED -- saving rejects to file b/app/helpers/projects_helper.rb.rej patching file b/app/models/issue.rb Hunk #1 FAILED at 143. Hunk #2 FAILED at 313. Hunk #3 FAILED at 414. Hunk #4 FAILED at 573. Hunk #5 FAILED at 776. 5 out of 5 hunks FAILED -- saving rejects to file b/app/models/issue.rb.rej patching file b/app/models/issue_category.rb Hunk #1 FAILED at 16. Hunk #2 FAILED at 40. 2 out of 2 hunks FAILED -- saving rejects to file b/app/models/issue_category.rb.rej patching file b/app/models/project.rb Hunk #1 FAILED at 384. 1 out of 1 hunk FAILED -- saving rejects to file b/app/models/project.rb.rej patching file b/app/views/issue_categories/_form.rhtml Hunk #1 FAILED at 3. 1 out of 1 hunk FAILED -- saving rejects to file b/app/views/issue_categories/_form.rhtml.rej patching file b/app/views/issues/_attributes.rhtml Hunk #1 FAILED at 9. 1 out of 1 hunk FAILED -- saving rejects to file b/app/views/issues/_attributes.rhtml.rej patching file b/db/migrate/20110216000000_add_issue_category_sharing.rb
Any ideas?
Updated by Daniel Neis Araujo over 13 years ago
Hello,
which version of the patch are you using? I have applied the "5358-first.working.version.diff", to the current redmine master commit (https://github.com/danielneis/redmine/tree/3ab981c04c33ebc1a490063d2d626fa669721209) and it worked well.
I've setup a git repository that you can try. Here is the link for the branch: https://github.com/danielneis/redmine/tree/5358-issue.category.sharing
Thanks for testing the patch!
Kind regards,
Daniel
Updated by Chris Darts over 13 years ago
I also used version '5358-first.working.version.diff' as uploaded 8 days ago.
I was using the redmine version at https://github.com/edavis10/redmine, but I've now set up a working copy from the svn (Redmine 1.1.1.stable.4943 (MySQL)) and I received the same error.
I'm fairly new to this and not a rails developer so excuse my ignorance, but I'm wondering why it's trying to write to a file in 'b/app/controllers' where there isn't a 'b' directory in the root of Redmine?
I would love to get this working so any assistance would be greatly appreciated.
Updated by Daniel Neis Araujo over 13 years ago
Hello,
what command have you used to apply the patch?
The patch was generated by git, so the 'a' is the original file and 'b' is the new version of file.
You must apply the patch with 'patch -p1 < 5358-first.working.version.diff' to ignore the first directory level in the diff file.
HTH,
Daniel
Updated by Chris Darts over 13 years ago
Thanks Daniel. I now tried it with -p1 instead of -p0 and it worked fine.
However, I just tried to test it out with one of my projects and I received the following error when I click on the 'new category' link.
Any help would be greatly appreciated.
NameError in Issue_categories#new Showing app/views/issue_categories/_form.rhtml where line #6 raised: undefined local variable or method `sharing' for #<IssueCategory:0xb5f938e0> Extracted source (around line #6): 3: <div class="box"> 4: <p><%= f.text_field :name, :size => 30, :required => true %></p> 5: <p><%= f.select :assigned_to_id, @project.users.sort.collect{|u| [u.name, u.id]}, :include_blank => true %></p> 6: <p><%= f.select :sharing, @category.allowed_sharings.collect{|c| [format_category_sharing(c), c]} %></p> 7: </div>
Updated by Daniel Neis Araujo over 13 years ago
Hello,
you must execute "rake db:migrate:all" to create the "sharing" column on "issue_categories" table.
More info on redmine upgrages at http://www.redmine.org/projects/redmine/wiki/RedmineUpgrade
Regards,
Daniel
Updated by Chris Darts over 13 years ago
It works perfectly now. This is a great addition to Redmine.
Thanks for your quick response.
Updated by Declan Lynch over 13 years ago
+1
The requirements for inheriting issue categories in subprojects just came up for our RedMine users.
Updated by Chris Darts over 13 years ago
I've just tested the patch file on the new Redmine 1.2.0 release and it seems there are some compatibilty issues.
This is the output after trying to apply the patch:
$ patch -p1 < 5358-first.working.version.diff patching file app/controllers/issue_categories_controller.rb patching file app/helpers/projects_helper.rb patching file app/models/issue.rb Hunk #1 succeeded at 165 (offset 22 lines). Hunk #2 FAILED at 317. Hunk #3 FAILED at 418. Hunk #4 FAILED at 577. Hunk #5 FAILED at 780. 4 out of 5 hunks FAILED -- saving rejects to file app/models/issue.rb.rej patching file app/models/issue_category.rb patching file app/models/project.rb Hunk #1 succeeded at 403 with fuzz 1 (offset 19 lines). patching file app/views/issue_categories/_form.rhtml patching file app/views/issues/_attributes.rhtml patching file db/migrate/20110216000000_add_issue_category_sharing.rb
Updated by Daniel Neis Araujo over 13 years ago
Hello,
i've not had time to update the patch for 1.2.0 but i hope i can do this next week.
Regards,
Daniel
Updated by Chris Darts over 13 years ago
Daniel Neis Araujo wrote:
i've not had time to update the patch for 1.2.0 but i hope i can do this next week.
Thanks Daniel, this is great news. Currently this is the only thing stopping me from upgrading to 1.2.0 and it's such a useful patch that I can't consider upgrading without it.
Chris
Updated by Daniel Neis Araujo over 13 years ago
Hello,
i've rebased my patch to Redmine-1.2-stable, and here is the full patch:
https://github.com/danielneis/redmine/commit/3a959c3c89d6bcec8e26eb13cc22f271f7252209
you can add .diff or .patch to the end to download the desired format or use git to merge directly from my repository.
HTH,
Daniel
Updated by Chris Darts over 13 years ago
I've just tested this on Redmine 1.2.0.stable.6000 and it seems to work fine.
Thanks Daniel.
Updated by Andrew Dahlin about 13 years ago
+1 any chance on this getting merged into a release?
Updated by Anonymous almost 13 years ago
Specifically:
- The sharing column was added to the issue_categories table in the DB, with "none" filled into category's sharing column
- Categories specified in parent projects did not appear in the child projects
- I changed the sharing value to "descendants" in the DB, but that didn't help either.
- There was no change in the user interface to indicate any form of sharing.
What am I doing wrong?
Updated by Daniel Neis Araujo almost 13 years ago
Hello, Kunal
which version of patch did you used? Also, did you applied the patch with git or "patch -p1" ? I've not updated the patch in last 5 months, so something in redmine could broke my patch...
If you send me the commands you used and the outputs, i can try to help you
Kind Regards,
Daniel
Updated by Gurvan Le Dromaguet almost 13 years ago
+1, integrated in my redmine instance
Updated by Tobias Fischer over 12 years ago
Gurvan Le Dromaguet wrote:
+1, integrated in my redmine instance
On which redmine version did you apply the patch?
Is it working with 1.3.0?
Updated by Martin Denizet (redmine.org team member) over 12 years ago
Me too I'd like to see this feature in Redmine. It would save me quite some time updating all my sub-projects's categories.
Updated by Leo Shklovskii over 12 years ago
Daniel's patch didn't work for 1.3 (primarily because of the view renames from .rhtml to .html.erb), so here's a re-written version of it for 1.3 with a few minor improvements.
Keep in mind that this is a pretty messy hack in a lot of ways. It basically clones the functionality of Versions to Categories. Some esoteric project operations may not properly reset categories when that's needed.
Updated by Leo Shklovskii over 12 years ago
And there was a bug in my patch, fixed and re-uploaded. Also, to clarify, this patch is against the 1.3.1 release.
Updated by alan blount over 12 years ago
+1 -- anyone want to make this into a plugin, or can we roll it into the core application -- it seems like an obvious win.
Updated by Leo Shklovskii over 12 years ago
Ugh, the previous version of the patch had a few crashes. This is the final version, we've been running it for two weeks without any problems.
It's really hard to turn this into a plugin since it monkeypatches pieces of core methods. As far as actually integrating it into core, there's probably a ton more work and tests that need to be done. As it is, it's a pretty messy hack.
Updated by Bruno Plantier over 12 years ago
Leo Shklovskii wrote:
Ugh, the previous version of the patch had a few crashes. This is the final version, we've been running it for two weeks without any problems.
It's really hard to turn this into a plugin since it monkeypatches pieces of core methods. As far as actually integrating it into core, there's probably a ton more work and tests that need to be done. As it is, it's a pretty messy hack.
Hi,
I tried to apply your patch, I still have an error in my log:
Processing IssueCategoriesController#new (for ::1 at 2012-03-27 11:54:17) [GET] Parameters: {"project_id"=>"test", "action"=>"new", "controller"=>"issue_categories"} Rendering template within layouts/base Rendering issue_categories/new ActionView::TemplateError (uninitialized constant IssueCategory::SHARINGS) on line #6 of app/views/issue_categories/_form.html.erb: 3: <div class="box"> 4: <p><%= f.text_field :name, :size => 30, :required => true %></p> 5: <p><%= f.select :assigned_to_id, principals_options_for_select(@project.assignable_users, @category.assigned_to), :include_blank => true %></p> 6: <p><%= f.select :sharing, @category.allowed_sharings.collect{|c| [format_category_sharing_simple(c), c]} %></p> 7: </div> app/models/issue_category.rb:49:in `allowed_sharings' app/views/issue_categories/_form.html.erb:6 app/views/issue_categories/new.html.erb:4 app/helpers/application_helper.rb:871:in `labelled_tabular_form_for' app/views/issue_categories/new.html.erb:3 config/initializers/mongrel_cluster_with_rails_211_fix.rb:62:in `dispatch_cgi' Rendering /Applications/redmine-1.3.1-1/apps/redmine/public/500.html (500 Internal Server Error)
What I have done on my bitnami redmine stack (version of redmine is 1.3.1):
cd /Applications/redmine-1.3.1-1/apps/redmine patch -p1 < shared_categories_redmine_1.3.1_v3.diff ../../use_redmine rake db:migrate:all RAILS_ENV=production ../../ctlscript.sh restart
I have checked the issue_categories table, the field sharing have been created, here its description
Type : varchar(255)
Charset : utf8_general_ci
Null : No
Default : none
An idea ?
Regards,
Bruno
PS: I am a total newbie in ruby/redmine so please, give me a chance to learn, thanks a lot ;o)
Updated by Motaz Abuthiab over 12 years ago
I think sharing categories (something like version sharing) will be so helpful
so +1
Updated by Motaz Abuthiab over 12 years ago
Motaz Abuthiab wrote:
I think sharing categories (something like version sharing) will be so helpful, we have a working patch for version 1.2, so I hope it will be added to 2.1.0
so +1
Updated by Franco Mosto over 12 years ago
Hello,
Unfortunately I'm running Redmine v1.3.2, I tried to apply your patch but it gave me the following errors:
patching file app/models/issue_categgory.rb Hunk #1 FAILSED at 16 Hunk #2 succeeded at 49 (offset 1 line)
Now, category sharing attribute appears when I create a new category, but any change of default setting (no sharing) is not taken into account.
Is there anybody using Redmine v1.3.2 who succeeded applying this very useful patch?
Thank you in advance
Leo Shklovskii wrote:
Ugh, the previous version of the patch had a few crashes. This is the final version, we've been running it for two weeks without any problems.
It's really hard to turn this into a plugin since it monkeypatches pieces of core methods. As far as actually integrating it into core, there's probably a ton more work and tests that need to be done. As it is, it's a pretty messy hack.
Updated by Leo Shklovskii over 12 years ago
We had a few more variations on the patch, but we're unfortunately still stuck on 1.3.1. It would be really ideal to get this integrated into trunk. We don't have the expertise/time needed to bring the patch up to production level (with tests and etc).
Updated by Anatol Bollinger over 12 years ago
We're using sub-projects for customer-specific tickets of our products. Not sharing categories across the project hierarchy renders filtering by category useless.
+1
Updated by Serge Ballesta about 12 years ago
I also need that categories of main project can be assigned to issues of subprojects and that filtering in main project show issues of subproject sharing a parent category.
I just tried a minimal patch (joined) :
- add a method in project.rb that returns the categories of the project and its ancestors
- use that method in app/views/issues/_attributes.html.erb in place of issue_categories
It seems to work in 2.0.3, and in 1.4.4 : I can assign categories of parent in issues concerning sub-projects and filtering works fine - I'm not sure if it can cause problems elsewhere but core redmine tests pass without errors.
I tried it in an older revision (1.2.2 - changing _attributes.html.erb by _attributes.rhtml) and it works exactly the same.
If this causes no problems in other parts of redmine, it could be easy to make this feature optional per project so that it could be included without regression for existing projects.
Updated by Serge Ballesta about 12 years ago
I must admit what I wrote above was rather stupid. As soon as project hierarchy changes it will lead to garbage.
I made some more tests and here is what I propose :
- a project may recursively inherit from its parent => there's an inheritance chain stopped at first project that chose not to inherit from its parent - simply a new checkbox in view "project/settings"
- an issue may be assigned a category from its project or from any inherited project
- when destroying an issue category, issues assigned to it may be reassigned to any other inherited category
- when a project changes parent or no longer inherits from its parent, for each previously inherited category that would be lost a new category with same name is created in the project (if it doesn't allready exists) and issues are reassigned to it(*).
- the list of all categories from inherited project is shown (read-only) in the view "project/settings/issue_categories"
Of course, the patch will be much bigger, and there is no hope it applies to a different version of redmine. But it could be easy to make "backports" as plugins for previous versions as few methods are modified. And there will be no regression : nothing is changed for projects that don't use inheritance.
I hope I'll soon have a first version of such a patch.
(*) of course it will lead to numeric issue categories (the id) in journal details - but it is the way redmine currently does when reassigning issue categories
Updated by Serge Ballesta about 12 years ago
Updated by Ruedi Silvestri over 11 years ago
+1, would be extremely valuable to have this added to redmine.
Updated by Gurvan Le Dromaguet about 11 years ago
Any chance to include this for 2.4 ? patch for this looks quite safe and show no problem, Have been using it for almost 2 years now, 100+ users.
Updated by Claudio Moscoso almost 11 years ago
- File shareCategories.sql.txt shareCategories.sql.txt added
Hello,
I made two sql-based script for copy issue-categories from a project to other, and other script for copy from a project to all others projects.
Regards
PD: Sorry by my bad english.
Updated by Mikołaj Milej almost 11 years ago
Copying is only workaround because you will end with categories that have different ids, so they are completely different in database point of view.
it should be dole like that:
categories:id | name |
1 | Foo |
2 | Bar |
id | name |
1 | project 1 |
2 | project 2 |
projecct_id | category_id |
1 | 2 |
2 | 1 |
2 | 2 |
So then you can share categories across all the projects and filtering is able to group/sort correctly by categories.
Additional logic can guard that you can assign only share categories within one project hierarchy (separating projects) - useful when you would like to rename category.
Additional you can create global categories.
Updated by yac yac almost 11 years ago
+1
we need to fragment projects into subprojects in order to not disclose VCS repositories to departments that don't need to see them.
Missing this feature is a blocker on categories for us.
Updated by Daniel Küppers over 10 years ago
+1
database logic have to be definitly be modified the right way.
Edit - Workaround:
In solution to use categories, i choose not to use the build-in ones. Instead, i take a custom field dropdownlist for all projects and all trackers. In this Way, youre able to filter globally for the custom categories you created. Queries are not that fast, but it works.
Updated by Toshi MARUYAMA over 10 years ago
- Has duplicate Feature #12215: Option to inherit Issue Category list from Parent project to Sub-projects added
Updated by Toshi MARUYAMA over 10 years ago
- Related to Feature #16941: Do not clear category on project change if category with same exists added
Updated by Lajish Lakshmanan about 10 years ago
toshio harita MARUYAMA
Category inheritance should also be allowed across projects. Please don't limit its scope to sub projects.
Updated by Ariel Lira about 9 years ago
+1 this functionality would be extremely useful in some scenarios with lot of subprojects and similar configuration.
In my case (a Help Desk), I have a parent project with no trackers enabled and support users (company employees). This project has a lot of subprojects, each for a different website, with its own tickets and additional users (the clients). All subprojects have the exactly same categories (frontend, security, performance, design, etc) and each category has the same group of assignees.
It would be extremely useful to share the same categories among all subprojects and that would permit to generate better queries and reports.
Updated by Luc Luc about 9 years ago
+1
For the moment I duplicate the categories on the sub-projects, but besides having to do the same work twice -- the ugly part is that on all queries and reports the categories are duplicated too (of course).
Updated by Bodo Maass almost 9 years ago
+1 Sharing categories across projects would be very useful when managing large inter-related projects.
Updated by Massimiliano De Ruosi about 8 years ago
+1
as pointed out, an implementation similar to version sharing would be optimal
Updated by Pierre Maigne almost 8 years ago
+1
That would be a great enhancement. In our case, we always have to duplicate manually the categories from the main project to each subproject.
Updated by Phil Valentine almost 8 years ago
+1
This would be really useful, it seems counter-intuitive that sub-projects need to have all their own categories etc setup. Inheriting 'Versions' is great, but it would be really useful for all the other parts of a project too.
This was raised 6 years ago, I can't believe it hasn't made it into the mainline Redmine yet.
Updated by Matthieu Gobillot almost 8 years ago
+1
I agree it would be really useful to inherit categories for subprojects.
The choice could be up to the user if the settings were to be made like the versions inheritance.
Updated by john aylward over 7 years ago
+1 would like to see something similar to version sharing.
Updated by Dmitry Bezrukov about 7 years ago
I'm not a Ruby developer. Can we contribute anyhow to solve this issue? Free beer?
Updated by Tomasz Janicki over 6 years ago
- File Custom-Global.jpg Custom-Global.jpg added
Today's finding.
For those who need to report time (or simply filter) using a global ID (aka. "Global Category"), please use Custom Fields, either on Issues or Project and they have be of List type. As attached.
If used on issues then "Projects -> For all projects" needs to be selected !
List can only be maintained by the Admin though
It is related to this discussion
http://www.redmine.org/boards/1/topics/2040
With Regards
TJ
Updated by Yuuki NARA over 6 years ago
- File select-category-child.png select-category-child.png added
- File setting-category.png setting-category.png added
I implemented the category inheritance function on the current 3.4.
I attach a screen copy below.
It is working on my environment, but I have not done enough operation check yet.
Test code is not prepared yet.
Is there anyone who can help?
This function (category inheritance) is very much requested.
(No.2 in vote count list, ISSUE 11898,5358)
It means,category inheritance function is necessary as well as version inheritance.
I am happy if it is incorporated into the core of 3.4, 4.0.
Because of this problem, I am managing the environment which can not be updated from 2.6.
(Currently it uses the patch for 2.5 of issue 11898)
I want to be able to update the same environment to the current version.
Regards
Updated by Yuuki NARA over 6 years ago
I added a category inheritance function to Redmine 3.4.6 and released it to GitHub repository.
It is working on my environment, but I have not done enough operation check yet.
I did not add test code.
If you need this function, please use it at your own risk.
I am happy if it is incorporated into the Redmine core.
Is there anyone who can help?
test code,testing,,
https://github.com/y503unavailable/redmine/tree/3.4-unofficialcooking
Share Issues Categories for sub-projects(11898,5358) for Redmine 3.4
https://github.com/y503unavailable/redmine/issues/14
I tagged current code to 3.4.6-inherit-category.
How to get the current code 2018/6/16
git clone --depth=1 -b 3.4.6-inherit-category https://github.com/y503unavailable/redmine.git
Updated by Manuel Palachuk about 6 years ago
+1
Yuuki,
We would like to help test this but I do not want to build an entire instance based on your fork/mirror.
How can we pull only the code required to update my fresh Redmine 3.4.6.stable.17445 to allow for Categories sharing with sub projects?
Thank you in advance.
Updated by Kumar Abhinav about 6 years ago
+1
Would love to have this feature implemented.
It would be really easy to work if we have global issue categories which can be shared among projects.
Updated by Yuuki NARA about 6 years ago
Thank you for comments
Manuel Palachuk Wrote:
We would like to help test this but I do not want to build an entire instance based on your fork/mirror.
How can we pull only the code required to update my fresh Redmine 3.4.6.stable.17445 to allow for Categories sharing with sub projects?
Thank you for help me.
Wait a couple of weeks to create a repository with only this fix.
Please PullRequest to GitHub.
Ultimately, I will post patch of source code and test code here.
Kumar Abhinav Wrote:
Would love to have this feature implemented.
It would be really easy to work if we have global issue categories which can be shared among projects.
Yes, as with the Version, it corresponds to global categories.
It can be used with all projects.
Updated by Manuel Palachuk about 6 years ago
Curious where this is at.
Would love to get rolling on testing it.
It also occurred to me; why not simply put the Categories at the top level in the Administration section and make them truly global without being tied to any project?
Thanks
Updated by Jérémy BARBIER almost 6 years ago
Hello,
We are a connected solutions editor company and we use Redmine for our project management.
We use the categories of issues to group our development requests by features.
Some of these features are common between subprojects.
It would be great if we could have this category-parsing feature between a parent project and its subprojects.
Thanks
Updated by Konstantin Ladutenko almost 6 years ago
Yuuki NARA wrote:
I implemented the category inheritance function on the current 3.4.
I attach a screen copy below.
LG2M! Any chance to have it in upstream master? Or as a plugin?
Updated by Elise Eeckman almost 6 years ago
+1
Please, a plugin would be great.
Duplication in all sub project does not allow to filter in root project on categories.
Updated by Yuuki NARA about 5 years ago
I created a patch corresponding to the current Redmine-Trunk.
It corresponds to SVN Revision 18328.
The current source set is below, so I hope you can try it.
If you have been using the inheritance function of the category before,
it is supported so that the error does not occur in the DB Migration process.
https://github.com/y503unavailable/redmine/tree/feature-category-trunk20190629
However, I did not write test code.
Since it is the same function as SubProject inheritance function of Version,
I think that it is better to create test code similar to Version.
This time I created a patch file directly from Github.
As it is the first for me, please point out if there is a work error.
Updated by Mizuki ISHIKAWA about 5 years ago
Yuuki NARA wrote:
I created a patch corresponding to the current Redmine-Trunk.
It corresponds to SVN Revision 18328.
Thank you for sharing the code.
The patch seems to work correctly in my environment(trunk r18328).
Updated by Yuuki NARA about 5 years ago
I think this patch can be merged into Redmine 4.2, how about it?
The test code remains and I don't want to delay the release of Redmine 4.1.
Updated by Jérôme BATAILLE about 5 years ago
Hi, we have developed a patch that is a generalization of Categories sharing.
I think it replies totally to the need expressed here.
The only thing you have to do is to create a new ProjectEnumeration custom field.
You can check it here :
http://www.redmine.org/plugins/redmine_smile_project_enumerations_custom_field_format