Redmine

The General Solution of issue #6716 would enhance even more the flexibility of the issue module to adapt easily to company needs, it also increases the usability and reduce the compilation time of the Issues.

+1

This is really near as what we need, we need a custom field filed by a query that retrieve our customers list from the ERP table, but this ERP is on other database, so, there must be some connection information too. Then this query can access other databases !

Stefano Lenzi wrote:

The General Solution of issue #6716 would enhance even more the flexibility of the issue module to adapt easily to company needs, it also increases the usability and reduce the compilation time of the Issues.

Huh! That would be a nice feature indeed. Instead of SQL Queries to froreign Databases, support for a common standard(?) http WS protocol for data queries would be better. So every dataprovider can offer its data "lists" via a web service where data can ve queried ad search results get returned. Someone has an idea what standards there are?

This is related to Issue #2096

While most usage will be served well with having Versions and Users type fields it would be really nice if the scope of this ticket is made extensible from there:

there are two specific cases where this can be thought of :

1. The custom fields which has many set of 'possible values' list:¶

The dynamic lists exists for many things - e.g. resources being used, configuration properties, OS and platform specific etc. In particular case, we use a config specific field with an almost same named field - in each project. So the purpose and role of that field is same in all projects- but it is actually a different custom field just because the list of "Possible values" is different in each project! And let me tell you, it's easier said than done when we 'create' these fields. All aspects of works flows - where in each state/tracker/role where the particular field become 'must', 'read-only', permissions and a whole set of things now needs to be repeated for each project. And then, when we create another project? do this whole thing all over again.

How this can be implemented: Ideally, it is very important that a given Dynamic List can have multiple set of possible-list-of-values, and either the source list can be selected in project. Alternatively, we can put a complete list of possible values in the main definition - and then specific projects can enable disable the fields that suits them. But even as the possible values differ per project actual workflow and behavior can remain as is for all aspects.

2. Custom fields which derive values dependent from external system:¶

The Request Tracker ticketing system has something called an External Fileds . A potential use case could be to hook to external systems - e.g. I can lookup on the external Inventory systems to know the list of machines that can apply for the given context, or a list of versions of external platforms -e.g. Ruby, or Chrome or even list of stable Linux versions, or for that matter Bug numbers, Test cases of external systems etc. In our case can also be a specific lists related to config parameters without which the bugs are hard to reproduce. The essence is that the system which populates such a list is essentially external to Redmine and hence it would be wrong to keep manually updating the admin to keep adding items such as this inside the table list. Also the relevance could change depending on the project - hence the said list could be unique for each project.

How should this be implemented? : Definitely calling upon external DB directly could be very wrong. And currently i see no webserivce standard's schema exists for such a purpose, and ideally, even if we try to create one, it's not practical to apply everywhere. The way it should be done should be very similar to how email based issue creation works. There should be a REST API that exposes a given custom_field ID and it's possible current values can be updated. Now one can write any script on ones' own that fetches the right set of list from whatever appropriate place and run a cron-type job to keep updating this! Even the current custom_fields can be very easily extended in this manner. One very critical thing to support is that in the history some fields could have been valid - so they could exist in DB, but now they might not be among the possible values - this needs to be supported.

Any feedback or update on this?

+1

+1

one more vote.

+1

+1

+1

Is this coming anytime soon?

Is this coming anytime soon? I din't find it in roadmap. This feature would be very very usefull.

+1

+1

+1

+1

https://www.redmine.org/plugins/custom_field_sql

+1