Redmine

I need this too. Specially when opening a bug, we can specify wich version it will be corrected, but not wich version it appeared.

This is the same as #2081

Hans Yoon wrote:

I want to add custom field, which is named as "Tester".
When a bug has fixed(solved), we passes the issue to specified tester or QA.
The QA or tester verified problem is solved with its own methods.
But there is not any filed to log "who tested it?".
So I want to add field as "Tester".

But it is very inconvenient to maintain user names.
And these fields are not able to be searched using key.

So I suggest "custom fields referencing redmine system tables",
which might be users, issues, projects, and so on.

Hi Hans,

I had the same requirement when my company started to use redmine. So I did some modifications to add a custom field called "User List". It's working fine nows for issues. I'm doing some adjustments and soon I will provide a patch ; )

Best Regards,
Adriano Crestani Campos

Adriano Crestani Campos wrote:

Hans Yoon wrote:

I want to add custom field, which is named as "Tester".
When a bug has fixed(solved), we passes the issue to specified tester or QA.
The QA or tester verified problem is solved with its own methods.
But there is not any filed to log "who tested it?".
So I want to add field as "Tester".

But it is very inconvenient to maintain user names.
And these fields are not able to be searched using key.

So I suggest "custom fields referencing redmine system tables",
which might be users, issues, projects, and so on.

Hi Hans,

I had the same requirement when my company started to use redmine. So I did some modifications to add a custom field called "User List". It's working fine nows for issues. I'm doing some adjustments and soon I will provide a patch ; )

Best Regards,
Adriano Crestani Campos

Thanks a lot.
I hope you have a nice result.

Didn't try your patch, but someone told me about this feature yesterday ; I'm wondering if it would be difficult to adapt your work to other fields (tracker? categories? priority?) ?

Jean-Baptiste Barth wrote:

Didn't try your patch, but someone told me about this feature yesterday ; I'm wondering if it would be difficult to adapt your work to other fields (tracker? categories? priority?) ?

Hi Jean,

I don't think it would be that difficult. But we need to decide some behaviors before. For example, the "User List", if you add it now to a issue it will show all the assignable users of the project that it belongs to. Otherwise, if it's added as an user or project custom field, it will show all the users registered on the server.

For trackers, what should be shown in a tracker list? All the trackers contained in the actual project? All the trackers contained in the subproject and project? If the tracker is deleted, what happens to the field? Should it be unset if it's referencing a tracker that is deleted? I think this last question I raised, if the answer is yes, would be the difficult part to implement : (

Can you commit the "User List" for now (if everything is ok for you in the patch) and then we can open another issues, one for each new custom field, so we could start working on adding them one by one and we can discuss each one's behavior separately. What do you think?

Best Regards

This feature would be amazing. Has there been any progress in the past 50 days?

Douglas Manley wrote:

This feature would be amazing. Has there been any progress in the past 50 days?

Sorry, I'm afraid will not have time to contribute a new patch soon containing new other custom fields. For now the patch I have attached only adds the "User List" custom field and it's working fine. I really would like to see the patch committed, is there any specific reason why it has not been committed yes?

Best Regards

I have attached this patch and it's working fine.

When is this patch committed?

Can we use this for "Reports to" users custom field, which will tag the manager to the user. Will be very useful for writing reports like status report of all the members reporting to particular manager.

Nanda Palaniswamy wrote:

Can we use this for "Reports to" users custom field, which will tag the manager to the user. Will be very useful for writing reports like status report of all the members reporting to particular manager.

Yes, you can add a "Reports to" field to the user profile : )

A bit of a noob here. Trying to apply this patch with patch -p0 < feature_2096_adriano_crestani.patch as stated in the Redmine wiki on applying patches, but I get this error: "patch: ** Only garbage was found in the patch input." Any ideas what I am doing incorrectly? Perhaps because this is a patch and not a diff, the patch command will not do the trick? Thanks for the help and the patch.

Never mind. I grabbed the wrong file with wget. I mistakenly got
http://www.redmine.org/attachments/1202/feature_2096_adriano_crestani.patch instead of
http://www.redmine.org/attachments/download/1202/feature_2096_adriano_crestani.patch. Obviously, patch had no idea what to do with the HTML. Works now as documented.

I noticed that Redmine always sends out e-mail notifications (upon ticket changes and so on) to the users which are selected in this custom field. Can this be turned off for these custom fields?
What we need is that only the "watchers", the "owners" and the "Assigned-To" obtain notifications, but not the persons selected in this custom field.

We tried in our system to apply this patch but code is now really outdated and it did not fit to current redmine's codebase.
Therefore this patch has to be updated by its author before one can apply it.
Pitty...

Hi,
I'm very interested in this feature.
Espacially for the "version" custom field

This could be the same like #685

Has anyone got these patches to work?

I've tried the group-field patches in redmine-0.9.4, but it doesn't seem to work--- the combobox is not populated by the groups.

I'm interested in writing a version_list based on the group_list, i.e.,

when "version_list" 
  versions = @project.versions
  versions.delete_if { |version| version.type != 'Version' }

  custom_field.possible_values.clear()
  versions.each { |version| custom_field.possible_values << version if version.type == 'Version' }

  blank_option = custom_field.is_required? ?
                    (custom_field.default_value.blank? ? "<option value=\"\">--#{l(:actionview_instancetag_blank_option)} ---</option>" : '') :
                    '<option></option>'

  select_tag(field_name, blank_option + options_for_select(versions.collect { |x| x.name }, custom_value.value), :id => field_id)

+1

Stupid question: This issue has been around for years, and there are tons of other issues (most of them closed, and only some of them closed as duplicates of this issue) all asking for the same thing. Clearly there is a significant user demand for it. There have also been what looks like multiple users trying to address this issue ...

• just hate the idea of this issue?
• have nothing against the issue, but just don't think it's important? (despite all the requests for it)
• think that someone in the community is going to fix it?
• have some other reason for not addressing this issue?

I guess what I'm trying to ask is, what's the hold up here? I've got a box of fresh-baked cookies and unmarked bills waiting to be sent if someone will just tell me who to bribe ... ;-)

Jeremy Walker wrote:

I guess what I'm trying to ask is, what's the hold up here? I've got a box of fresh-baked cookies and unmarked bills waiting to be sent if someone will just tell me who to bribe ... ;-)

Oh, and regarding the bribing, I think everyone would love some 48-hour-days without the need to sleep more and stuff like that ;-)

+1

We were looking to add a custom field for "Code Reviewed By"/"Reviewer" and then populate it with the members of the project.

For me the lack of this feature prevents me from using RedMine. Specifically the users portion.

For any issue I want to track there will always be multiple people involved in different roles. The developer is only one in that chain. To be able to have actual users in fields like "tester", "writer", etc. is very valuable. I had it in at my previous job in the home grown system we used and found it essential.

If there really are that many requests for this couldn't it be looked at? I would think that the given pieces needed to make this feature all exist already and it shouldn't be too hard.

Please reconsider if for 1.1.

Thanks

Oh, and regarding the bribing, I think everyone would love some 48-hour-days without the need to sleep more and stuff like that ;-)

Soooo ... y'all want me to send you speed? ;-)

Seriously though, I would pay money for this feature. I'm willing to bet from the comments on it and the ones in related issues, I'm not the only one. But if the dev team has ZERO interest in "votes", bribes, or any other external motivation whatsoever (as seems to be the case) ... well that's really frustrating.

I understand that the dev team wants to work on what they want to work on, not what the users want. It's their project, and by all means they should be able to do what they want! But it would be really nice if there was some way for users like us to somehow influence development, in some way. Votes, bribes, whatever just SOME way to effect the changes that we'd like to see in Redmine. But I guess such a request is beyond the scope of this issue ... :-(

P.S. I know that, as with any open source project, one could always submit a patch, but what's the point if no one with commit power is going to take the time to bring it in to the codebase?

A feature to "Add voting to tickets" (#1011) has been developed as a plugin, but Redmine itself doesn't use it.

Of course, there are major development guidelines decided by the Redmine's team but I totally agree with you that, somehow, users should influence the development of Redmine.

For instance, I moved my company from Trac to Redmine because Trac's team totally ignore the fact that multiproject management capability would benefit a lot of users (there is a huge unsolved ticket there with lots of requests until nowadays).

I don't want to be unfair with Redmine's team because I think they are doing very well so far.

First off, thanks for taking the time to respond. I know you have better things to do than answer random bug requests, but I really want to explain where I'm coming from here.

Any help is welcome.

Hire a serious rails developer and submit a patch

We don't want to introduce untested code, it's far too difficult to maintain

When I line them up like that, can you see how those statements might appear to be at odds? And more importantly, do you see how those statements are at odds with the fact that there have been two patch sets submitted on just this issue alone? One was two (TWO!) years ago and one was half a year ago, and they both got no response.

When I even asked (four months ago), "hey what's the deal?", no one said "these patches are untested", or "the proper process wasn't followed" or anything like that. Instead, Felix basically just said "the developers have better things to do". So, it's easy to say "submit a patch", but when people have been trying for two years and those patches have gone nowhere because the developers have better things to do ... it kind of discourages submitting a third patch. And this is why I offered money: it seemed very clear that the Redmine team didn't want patches.

So, maybe this is all a big misunderstanding, but it still looks to me like no one outside the "barely ... a dozen of contributors" can effect any change to Redmine. They can "+1" an issue all day long, they can submit patches for it, and they can even offer to bribe the developers, but at the end of the day it seems like the developers are just going to let any contributions that they aren't interested in rot. To anyone outside that circle, even someone who loves Redmine, appreciates all the hard work of its developers, and just wants to improve it a little ... that's really, really frustrating.

Jeremy Walker wrote:

Instead, Felix basically just said "the developers have better things to do".

I'm sorry for being so concise that it may seem rude, but I stand by what I've written. To make a bad car analogy: Redmine is a nice car, and every which one wants to add a spoiler, some stickers or flames on the side, but it's also rusting inside out. I'd rather we concentrate on the rust for now. (btw, what JB wrote ("Hire a serious rails developer and submit a patch", "We don't want to introduce untested code, it's far too difficult to maintain") is essentially the same thing in a nicer package: "we" (or at least not I) don't have the time at the moment to review and/or improve on (beware, here be a generalization!) at best half-tested moderately big patches).

Regarding frustration: it's also very (very very) frustrating and discouraging to have to leave some stuff on the side of the road, and doubly so to have the same conversation again and again about why that is so and "loosing" time because of it. There's a line to be drawn somewhere, we chose to improve quality and maintainability at the moment while retaining a moderate standard about what code to add, mostly because most of us don't want to see redmine get unstable or have a feature-kreep. If you're unhappy (and believe me, I'm mostly unhappy about redmine's current situation too) with that, feel free to fork redmine, pay someone to patch up your redmine install with what you need, or use a commercial product.

Felix, Jean would it be acceptable for you to inlcude patches with included tests, which will fullfill specified cirteria like defined folder structure, documentation and test coverage? Futhermore features votes can be ranked, if for example you would implement / install a vote plugin for tickets on feature tracker. This ranked list would show to everyone where his demand is ranked overall. You won't have to implement that of course, cause you spend your spare time and mostly unpaid, but if community contributers offer patches including tests with requested coverage and this tickets are voted at the first for example 30 positions of this ranking, you should make a official "promise" or deal to the community you will include it to next release. Otherwise i understand that for noone there is a clear communicated process, and this way its difficult to let the community join your efforts. Make your requirements clear and offer a deal how it will work. Just an idea - for both sides.

I'm sorry for being so concise that it may seem rude, but I stand by what I've written

No apology needed! My point wasn't that what you said was rude or anything, it was that Jean-Baptiste's comment contradicted it.

I'd rather we concentrate on the rust for now.

That's totally cool; I'm all for the core developers of any project spending their time on the core parts of that project.

"We don't want to introduce untested code, it's far too difficult to maintain") is essentially the same thing in a nicer package

I'd argue it's a completely different thing. The key difference is whether someone outside the Redmine circle can contribute. "We're too busy" means, "no, you can't contribute". "We're too busy for untested patches" means "go ahead, please contribute! ... just play by our rules when you do it".

to have the same conversation again and again about why that is so and "loosing" time because of it.

First off, I understand you could just not reply to these bugs and not "lose time", and I do appreciate you "losing" your time on a loser like myself ;-) That being said, this is an open source project, and having a public feature request system then getting upset when people actually expect you to work on features is a little disingenuous. If you don't want to work on features, two minutes of changing some verbiage is all it would take to make it clear this system is for bugs only, and your problem is solved.

feel free to fork redmine, pay someone to patch up your redmine install with what you need, or use a commercial product

I can patch my Redmine installation with whatever I want (again, I didn't offer money because I can't code, I offered money because y'all didn't seem to want coders). But the thing is, I'm not the only one who wants these features, and even if I worked on one of the ones I want I don't have time to implement every one myself. Plus whatever I do implement locally is going to get all messed up when the next update comes (and the update after that and so on), and then if the devs ever decide they want the feature I coded locally, they'll make their version (duplicating effort) and my version won't work with it.

I'd argue that all of the above is precisely why open source projects, and communities of programmers contributing to them (not just borrowing some code and tweaking it for their needs) has become such a phenomena.

So please let me clear: I'm not trying to bitch and complain about the developers' choice of work, and I'm not trying to say that anyone should just be able to submit whatever code they want and have it be included in "trunk". All I'm asking for is just a normal open source project, where anyone who wants to improve the project (provided they are willing to "play by the rules", which can totally include tests or whatever else) has an opportunity to do so. If the developers specifically don't want a certain feature (because it will cause problems for whatever reason) that's one thing, but as I see it right now you've got features everyone wants, and that non-core programmers are willing to work on ... but because of the "rust", there's just no way for anyone except the core devs to do anything about them.

P.S. And if what I just described is what Redmine is already, I apologize for the "drama" ... but all it would have taken to convey as much was a one sentence reply to my comment four months ago: "These patches were submitted without tests, so we won't consider them until the process specified at [insert URL here] is followed".

Terence Mill wrote:

Just an idea - for both sides.

That all seems cool to me :-) But really, I think even if the devs just said:

Look, we're going to work on core stuff but someone on our team will spend some small percentage of time reviewing code submitted from outside the core circle, so long as the process we define for making it easy on ourselves (ie. requiring tests and whatever else) is followed by the submitter

would be a huge improvement over (what I perceive to be) the current situation.

I would like to see this implemeneted since there are different users which need to be mapped in different roles to the same issue. Hope this is done as a feature or as a plugin.

Btw, the .patch file, i am applying
"patch -p0 < feature_2096_adriano_crestani.patch" in the command prompt within the redmine directory.
And it is giving "patch" is not a recognised command.
How do i use the patch? Any help would be appreciated.

shubham chakraborty wrote:

Btw, the .patch file, i am applying
"patch -p0 < feature_2096_adriano_crestani.patch" in the command prompt within the redmine directory.
And it is giving "patch" is not a recognised command.
How do i use the patch? Any help would be appreciated.

Patch is a general use tool, not a Redmine related one, so you need to install it annd put in your path. If you're using a linux box, just run a yum install patch or apt-get install patch and it's easily done.

We would like to see this inlcuded also.

+1

Not giving up! ;)

Would you provide some screenshots and a github url!

Tx for sharing!

Victor Doulepov wrote:

Alright guys, here it goes in a plugin form - probably that will make life a bit easier.
We use it locally under Redmine 1.0.3 - no issues observed till now.

FWIW: I tried this plugin on both Redmine 1.0.5.stable.4574 and Redmine 1.0.5.devel.4574 but when I try to create a new "Issues Custom Field" of the format "User list" I receive a flash-error:

* Format is not included in the list

Has anyone successfully applied patch of plugin to v1.0.4, 11-28-2010 release? If so, can I get instructions?

I'm running bitnami VM. I got errors trying to apply the feature_2096_adriano_crestani patch.

redmine-development:/opt/bitnami/apps/redmine # RAILS_ENV=production ruby script/about
./script/../config/../vendor/rails/railties/lib/rails/gem_dependency.rb:119:Warning: Gem::Dependency#version_requirements is deprecated and will be removed on or after August 2010. Use #requirement
About your application's environment
Ruby version 1.8.7 (i686-linux)
RubyGems version 1.3.7
Rack version 1.0
Rails version 2.3.5
Active Record version 2.3.5
Active Resource version 2.3.5
Action Mailer version 2.3.5
Active Support version 2.3.5
Edge Rails revision unknown
Application root /opt/bitnami/apps/redmine
Environment production
Database adapter mysql
Database schema version 20100819172912

About your Redmine plugins
Redmine Logs plugin 0.0.1
Redmine Qa Contact plugin 0.0.2
Issue Importer 0.7
redmine-development:/opt/bitnami/apps/redmine #

TO Redmine coders,
why cant this be included in the redmine version and not as a plugin???
Is just making a copy of the exsiting "ASSIGNED TO" field suffice??
Even if the mail functionality is not included as of now, but a USER LIST field other than assigned to is a must.
Hope this comes out soon.

shubham,

Dude, you really need to read the comment history (I know it's long, but if you're going to take the time to comment ...)

The "Redmine coders" made it very clear that they are working on improving the internals Redmine right now, and such they couldn't give a rat's ass what anyone else wants feature-wise ... even if someone else does all the coding for them (as has happened what, three times now with this issue?). For the feature to go in to Redmine proper (ie. not as a plug-in), they need to at least review the code, and for now at least that's bandwidth that they would rather devote to improving the Redmine internals.

I've already tried offering to bribe them, and that didn't work. So if neither that nor community desire will motivate them, really your only options are to wait for their priorities to change, or to switch to another program with coders who actually care about their community.

That came out a little harsh; should have said "who actually care about what their community wants". Obviously they care about the community, otherwise they wouldn't work on improving the internals and then share those improvements (as they presumably will) with the rest of us.

Guys, i really need feature "USER LIST" also and even create #5684
But if you need too - you can subscribe to this task and developers can see how many users want this.

Maxim,

You can file as many issues as you want, but the thing is, it doesn't matter "how many users want this", because the devs just don't care. See comment #30 and comment #32: if Redmine was a car, the devs would only want to work on the "engine" right now. It doesn't matter to them if a million people think the engine works fine, and really want a better spoiler. It doesn't even matter if people submit (multiple) designs for new spoilers: until they finish working on the engine, the spoiler isn't changing.

On the plus side, Jean-Baptiste has gone so far as to say that this feature is on his list, so once the "engine work" is completed maybe we can all get this long awaited feature. But until then, we're all just S.O.L.; there are zero developers devoted to handling open source submissions on this project (making it open source in the "anyone can read the source and make their own Redmine" sense, but not in the "anyone can contribute as long as they contribute something useful" sense).

I have been watching this Issue for a while, but the latest comments about the developers decision aren't fair at all.

As a developer, I appreciate the bravery of the core developers to stop the development and do a big housekeeping. Every software needs such a thing once in a while and, of course, they knew that lots of complaints would take place.

As I don't participate in its coding, so I can't allow myself to criticize their decision.

As a Redmine's enthusiast, I think that the more nervous ones should re-think and calm down because Redmine is a great tool and I dare anyone to find a tool as good as Redmine (and for free).

I am a Redmine user that has asked for this feature, and others, and have followed the ‘spirited’ discussion. I have found enough value in Redmine as it is now, despite my comment of 5 months ago, that I have introduced to my dev organization and we are adopting it.

I really do want this feature. For me it is users as field values. OK I really want to have customized inline URL template values like the # sign too. We had both of these in my previous in house defect tracking system. I have worked around the user fields by creating simple list fields and using watchers to have the people listed in those fields be notified on updates to those issues. For the URLs I just drop them as text into a custom field and it looks ugly but can work via cut and paste. I would much rather have automatic inline recognition of ‘cr#’ for expansion of my code review URL.

I have not participated in any of the discussions about planning and prioritization of Redmine work. There is some obvious turmoil now and frustration on behalf of both the users and the developers.

As a development manager I have worked in the software development field for the last 20+ years and know a thing or two about teams and planning. A focus on the core is imperative if the software is to have longevity. Not being able to refactor will cripple you in the long term. I have also seen projects and products fail because they never came back such a reworking of core infrastructure. However, not having a release with user requested features is not a good thing(tm) either. It is a delicate balance.

Thanks for creating the unplanned list and putting this issue on it. Having a mechanism to bubble up what the users, not just contributors, would like to see, e.g. a top ten list, would be very valuable addition to Redmine. There may be things on it that don’t really take that much time, but generate huge positive feedback. Making it an automated process would save you the hours and hours of trolling through all of the issues. Which no ones wants to or should have to do. And I think you have passed the tipping point on that already. Let the Redmine and the Redmine community do that work for you.

I agree... these comments are not fair to the developers. I think they made their reasoning very clear. To criticize it suggests you question their decision making. But the success of redmine and the quality validates the decisions they have made. They're obviously doing something right. I applaud the decision to hold back on this code because it has to be qualified by someone that is qualified to do it, even if that means it may not get done due to lack of resources. They need more people and people would rather complain than step up and do what's needed to help.

But anyhow.... in the meantime.... has ANYONE got past the latest flash error with the plugin? I cannot get the plug in to work.

Luiz Carlos Junior wrote:

I have been watching this Issue for a while, but the latest comments about the developers decision aren't fair at all.

Sorry you feel that way, but there was nothing "unfair" about my comment at all. Read those comments I mentioned (#30 and #32); those are the developers' words, not mine. I'm just re-stating what Jean-Baptiste and Felix already said, and I think I did a pretty fair (if slightly bitter) job.

As an aside, according to Felix I'm actually doing them a favor by re-stating their comments:

and doubly so to have the same conversation again and again about why that is so and "loosing" time because of it.

Really, I'm just preventing Felix from "loosing" more time answering people with essentially the same comments that I had ;-)

As a developer, I appreciate the bravery of the core developers to stop the development and do a big housekeeping.
Every software needs such a thing once in a while and, of course, they knew that lots of complaints would take place.

While I disagree that "every software" needs such retooling once in awhile, I'm a developer too, and I hear what you're saying. But (as I stressed in an earlier comment), I'm not asking the devs to drop everything and fix "my" pet issue (that lots of other people want). All I'm asking for is ONE dev to take ONE hour a week (or some similarly small amount of time) away from all that retooling to simply review code that some other developer took the time and effort to contribute. Or in this case, to review any one of the three different submissions different contributors have submitted.

As I don't participate in its coding

And you couldn't even if you wanted to, which is sort of the point here.

As a Redmine's enthusiast, I think that the more nervous ones should re-think and calm down

Again, I didn't say anything outrageous that requires "calming down"; I just re-stated what the devs have already said. But it's easy to lecture others to "just sit tight"; it's a lot harder to wait for an issue 2 years (yes, 2 years! That's how old this ticket is), and see several hard-working people contribute solutions, only to have them go nowhere, all because the devs refuse to even look at them.

Tom DeMay wrote:

But the success of redmine and the quality validates the decisions they have made. They're obviously doing something right.

So you don't think there's anything at all to criticize about a 2 year old issue, which clearly has a large number of users who desire it, and which has had not 1, not 2, but 3 (3!) different solution patches submitted for it ... still sitting here unresolved?

I <3 Redmine too (wouldn't be here if I didn't). The devs have clearly done a great job with it, and the vast majority of the core functionality works extremely well. Kudos to them. But I still think something's wrong with your project when you've got a major issue many users want, tons of devs volunteering their time to solve it, and no progress whatsoever for two years.

You're free to disagree shrug.

What I think is irrelevant. Besides, none of those patches work. I have been unable to get any of them to work in 1.0.4. So maybe the right call was made after all?

What I do know is that if someone does pull this ticket up to work on it they will have a very difficult time reading through this history and getting up to speed with this. A developer looking for something to work on, is very likely to move on to something else when they see the length of this and all the negative comments.

TIP: I found a work around to the plugin error on 1.0.4

You cannot use the UI to create custom field. But if you create it in the database, it appears to be perfectly usable. (e-mails aren't going out though. don't know if they are supposed to, it would be nice)

I'm using MSSQL to connect to my redmine DB, but this code should work in mysql. just replace the @variables with the appropriate values. This adds two custom user lists and joins them to all trackers.

insert into custom_fields (type, name, field_format, possible_values, min_length, max_length, is_required, is_for_all, is_filter, position, searchable, default_value, editable)
values ('IssueCustomField', @myfieldname01, 'user_list', '--- [] ', 0, 0, @isrequired, @is_for_all, @is_filter, 孝梁 刘, @searchable, @default_value, 1)

insert into custom_fields (type, name, field_format, possible_values, min_length, max_length, is_required, is_for_all, is_filter, position, searchable, default_value, editable)
values ('IssueCustomField', @myfieldname02, 'user_list', '--- [] ', 0, 0, @isrequired, @is_for_all, @is_filter, 孝梁 刘, @searchable, @default_value, 1)

select custom_fields.id as custom_field_id, trackers.id as tracker_id
from trackers
inner join custom_fields on ( custom_fields.name in (@myfieldname01, @myfieldname02))

I'm answering Tom here as this seems to have bubbled up again lastly.

Tom wrote (in a mail to me):

I am very interested in this. I am willing to learn what is necessary to get this done and committed to the product.

Would it be possible for me to do that? If so, can you tell me what you would need from me to get this in? And perhaps give me some pointers to get me going?

My best short answer to this is: ask Jean-Philippe Lang.

To be brutally honest: I don't know. My involvement in Redmine has somewhat dwindled in the past few weeks, partly because I had (and still have) to take care of my studies, but also because I had somewhat lost my motivation. This last point is probably the most important though, and I will probably write a more lengthy forum post in the next few days with more detail, but my motivation hasn't only not gotten better, but I'd say it's even gotten and still getting worse. The gist of my demotivation is the utter lack of communication between JPLang and the community or even the contributors.

Back to your original question: I don't know, because no one has ever told me or been able to pry any sort of guidelines or best practices out of JPLang that I know of.

I i try to create new custom field with name "Tester" for Tracker "Test" and choose userliste as Format i get following user message on html site header when trying so save this field definition.

"Format ist kein gültiger Wert" (german) mean "Format is no valid value/type"

Using redmine 1.1.1

Victor Doulepov wrote:

Mischa The Evil wrote:

Victor Doulepov wrote:

Alright guys, here it goes in a plugin form - probably that will make life a bit easier.
We use it locally under Redmine 1.0.3 - no issues observed till now.

FWIW: I tried this plugin on both Redmine 1.0.5.stable.4574 and Redmine 1.0.5.devel.4574 but when I try to create a new "Issues Custom Field" of the format "User list" I receive a flash-error: [...]

This is fixed. Updated plugin attached.

I'm still having this issue with 1.0.5... Any tips?

I can tell the plugin does not work with 1.0.x, but it works in our environment under 1.1.0 and 1.1.2.

Terence, can you give me the part of your Redmine log related to adding the custom field for review?

Jean-Baptiste, 5 months ago (back when 1.1 was the next milestone) you wrote:

Actually, this feature is on my personal todo list, but we decided to focus on other things for 1.1.0, see roadmap.

Any chance this has moved up higher on your todo list? As exciting as the plug-in (that doesn't work for us with our 1.0 installation) is, an actual built-in feature is really the right way to go with something like this I think.

This is a very useful feature, one more thanks a lot.

I applied those changes to my 1.1.2 installation, and it seems to work fine.

1. In custom queries it is not possible to assign value "<< me >>" like with assignee and watchers.
2. It is not possible to choose that such users receive notification mails like assignee and watchers.

Since I "backported" the changes it may due to my installation. Can someone with a installation from trunk confirm it?
Anyway nr 2 can easily be fixed by adding that persons as watchers. But I'd appreciate it very much if nr 1 may be added/fixed.

Why it is impossible to add custom field "user" to the user table ?
I think this could be very useful e.g. when you have "client" user and you want to assign "account manager" user.

#8405

Updated RedmineCustomFields