Redmine

You can just add a customer_id field to issues via your plugin and then associate issues belongs_to customer via vanilla Rails.

See my Budget Plugins' issue monkey patch to see how I related an Issue to a Deliverable (plugin's model).

Eric Davis wrote:

You can just add a customer_id field to issues via your plugin and then associate issues belongs_to customer via vanilla Rails.

See my Budget Plugins' issue monkey patch to see how I related an Issue to a Deliverable (plugin's model).

I'm sorry, maybe I don't tell it well: Is not my plugin. Is about any plugin. I pretend to use some plugin in a new way, as a user. Your hint is ok for me as developer ( I'm) but in my request I'm thinking more as a final user of redmine: he don't want 'descend' to the code :). By the way, thanks for the hint.

The idea of referencing custom field's from tables bia lookup fieled is nice. How is it implemented at the moment for value lists? Wouldn't you like to have a key-value list, where key is the reference and lookup column and value the displayed value to the user?
This way you could change order, rename items and insert values not only at the list end and will keep the reference and integrity of entities (tickets,..) referencing the display value via the key value.

The table being used for custom fields declaration could look like this:

• Column 1: Custom field name/id like seen in ticket label or another entity (projects, etc.)
• Column 2: Custom field type (number,string,date, regex, etc.)
• Column 3: Field value display name - the name which is shown to use as value name
• Column 4: Field Key name - the value's identity which is referenced as foreign key when selected as value in entities (tickets, projects..etc)

In this table you could insert as many custom fields with key-value lists which can be changed with little refactoring capabilities.

In another step restful xml ws or wiki pages can be used as source for providing and maintaining custom field input via table structure.

+100. This is very important as we are evaluating to extend Redmine for helpdesk.

The Request Tracker ticketing system has something called an External Fileds .

1. Lookup on the external Inventory systems to know the list of machines that can apply for the given context,
2. List of versions of external platforms -e.g. Ruby, or Chrome or even list of stable Linux versions,
3. List external system Bug numbers, Test cases of external systems etc.
4. Most importantly, this can link different configuration option options available in the context.

How should this be implemented?

Terence Mill wrote:

The idea of referencing custom field's from tables bia lookup fieled is nice. How is it implemented at the moment for value lists? Wouldn't you like to have a key-value list, where key is the reference and lookup column and value the displayed value to the user?
This way you could change order, rename items and insert values not only at the list end and will keep the reference and integrity of entities (tickets,..) referencing the display value via the key value.

This is absolutely perfect.

The table being used for custom fields declaration could look like this:

• Column 1: Custom field name/id like seen in ticket label or another entity (projects, etc.)
• Column 2: Custom field type (number,string,date, regex, etc.)
• Column 3: Field value display name - the name which is shown to use as value name
• Column 4: Field Key name - the value's identity which is referenced as foreign key when selected as value in entities (tickets, projects..etc)

In this table you could insert as many custom fields with key-value lists which can be changed with little refactoring capabilities.

In another step restful xml ws or wiki pages can be used as source for providing and maintaining custom field input via table structure.

Again right on!

I think calling upon external DB of the source directly would be very wrong so would be for external application
to touch Redmine DB directly. The best possible way would be to expose this custom-field through the REST API to add, insert and modify the list of possible values.

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!

One of the other hurdle is, that if the old value (once valid) is already referenced in one of the issue, but it is no longer valid for new version, such deprecated values needs to be in the DB but there needs to be a way to mark such values as deprecated ones.

This is really a powerful idea - must pursue.

Add related #9734, #6717

+1