Redmine

Hi Sven,

As you said it, it would be a custom field. Custom fields can be created by your redmine administrator. But maybe I hadn't understand your point?

Your are right, this would be a custom field.
But the custom field should be a drop down list
with a all versions of the current project
(like "Fixed version").

At this time I am only able to create a custom field of
type "list" and enter all versions by Hand.

Ok, so the feature request is more a "add project based data sources for custom field", like Version, affected users and so on... Maybe could we enumerate here all datas that should feed a list in a custom field?

In my opinion that would only be two:
- Versions in a project
- Users assigned to a project

Or am I missing some?

Just want to keep this alive...

This one is important for me too, since I know this will be a show-stopper for replacing Bugzilla with Redmine in my organization. I started working on a patch and I could use some input.

I added the following custom field types: users, projects, sub-projects, versions and members. I also added a mechanism to limit types to certain places (e.g. sub-projects, versions and members only work in the context of issues and projects, so they shouldn't be available as a custom field for users).

The problem with projects (and sub-projects) is that projects may be private, and therefore different users will see different lists. Should I drop these two field types, or would be it acceptable to show a list that includes private projects to all users?

Also interested in this feature - would be very useful.

+1

Would be very useful feature to be able to populate custom field from standard project data like versions. It's not a big problem to populate lists by hand but still it feels stupid to do that.

+1
For me it would be enough to have the possibility of a enumerated custom field. I could fill it myself with data, doesn't have to be project data.

+1
it would be also nice to refer to the repository revision on which the issue has been detected (to trace intermediate version). A solution could be to define a type of custom field as "textilizable" so reference to version, revision or anything else could be done. I won't however provide a "hard" link between the object (as the target version vs issue)

gabriel

+1

Today in this version of Redmine, in the "New Issue" form, there is the field "Affected version" which is a drop list of the different past version.
Based on what I understood, this is a custom field with enumerated value. Am I right?

The concern with the custom field is that the new enumerated value can be change only in the administrative form.
This is a issue when the project are not managed by the administrators. So, either the custom field with enumerated value can be updated in "project setting" form or the "Affected version" field is linked with the versions of the project.

I would definitely prefer the second option.

Any news for this feature ? It doesn't seem to be in next release :-(.

What I would like to have is a drop down where you can choose a released version. I like the idea to have a status on version like described in issue #1245. Depending on this status, the version would be displayed on the drop down or not.

This could be the same like #2096

+1

+1

+1 :)

+1 :-)

This is quite useful in many situations. +1 :)
And having it generalized as "feed custom field with project data (somehow)" sounds like a very nice and flexible idea to go about it.

Created a patch issue to follow the progression of the 'found-version.patch' patch file I created. Please relate to #7443.

+1

+1

+1

How is this issue any different from #2096, which is already in the release?

You are right. I have just created a custom field "Found in version" which fulfils the description of this issue.

Hi all,
The custom field is a good start. However (as of RM 2.3.3 at least) full solution should:
a) observe Version status - it should be possible to limit list of versions for which it is possible to log error
b) allow to soft available versions from most recent

as we have a lot of versions and users/testers often take wrong/old versions.

Any ideas / plugins etc. in this version 2.3.3, please ?

remarks:
c) I can not delete versio associated with a ticket;
d) sometimes one can crate version per subproject and if we continue in newer project those old versions will not be on the list...
e) I know RM 3.0.3 allows to filter it by version status, but this status can not be tailored (we use another field for in Plannning, In Dev, Tests, Shipped, Discarded)

Essentially, it is not just about the "Found in Version". If there are custom fields based on version - we need qualifiers whether the fields are open, locked or closed.

I guess it would be too much to ask for that they will be restricted by "custom fields" of the version itself.

Well looks like the demand of this is really there with multiple issues.

But it can be achieved: (As I noted in other issue)

Basically, you can have a 'custom field' "Type" for each version. And then, when you define any other custom field (for issue or otherwise) which is of type version - it should ask for criteria as "field name" and values can be some conditions. If the field type has multiple values it can be selected which ones applies. The versions qualified under that condition will then be appeared in the corresponding version field.

Following issues have almost the same demands: Do add related
#685
#14250
#18560
#17962
#20100

Sven, this would be useful, but can you clarify why you ask this to be a custom field? I understand that being able to create such a custom field would be an improvement, but would a standard field not address your use case?

Hello Philippe,

I opend this ticket 13 Years ago... I think in the meanwhile you can close
it since there a new custom field type "version" which fits my needs :-)

Best Regards,

Sven