An "internal" option for custom fields
When developing plugins, I often need persistent data attached to a user, a project, an issue, etc. Except for users, where I could technically exploit
user_preferences from our plugins, I can't do anything but create my own migrations with custom tables or columns.
This way of doing it kind of does not feel right. Plugins should not create their own tables and columns in my opinion, unless they're really creating new entities that deserve their own model classes, too.
I've started using
CustomFields for this which comes with a drawback: The values of these fields are publicly visible by everyone. In some cases it might only cause confusion or "not look so good" to have stuff displayed on a user or project page (done this in the PluginHoptoadServer plugin). In other cases it could be a security issue, when these fields simply cannot be displayed throughout Redmine.
I have 2 solution alternatives to this in mind:
- create two new options for custom fields: being invisible (not displayed in views) and being "not editable" (not included in forms). This way enables three (four minus one existing) new usage scenarios:
- invisible & not editable: the field can be used internally by a plugin without interference by users
- invisible & editable: the field can be used by a plugin, but the plugin does not need to provide its own forms for updating the values
- visible & not editable: not sure about the added value of this. A plugin could provide its own way of manipulating custom field values, but data still gets displayed in views in the regular way.
- visible & editable: this is the default case which we have right now
- simply create
issue_preferences, etc. similar to
I would be happy to take on this. I could easily make it a plugin, but it would monkey-patch the core and could break in future versions. I would rather see this go into the core, but I'd like to discuss it first rather than just submit a patch.
From an implementation perspective, I think this could be easily achievable using named (or even default) scopes on custom fields.
Let me know what you think.
Updated by Jan from Planio www.plan.io over 13 years ago
just bumping this up to get some feedback :) if nobody thinks this is useful, just let me know...
Updated by Oren Laadan over 13 years ago
Yes, such functionality will be very useful !
I'm using the Tab plugin (http://www.redmine.org/wiki/1/PluginTab) and it is annoying that the iframe information appears on the project overview. It looks so out of place that at first I thought it was a bug :(
Are you aware of these two: feature #1738, and related patch #1746 ?
Updated by Oleg Aksenov almost 12 years ago
I, too, would benefit from this feature.
I hope this will work for all custom fields including "IssueCustomField".
Updated by Toshi MARUYAMA over 9 years ago
- Related to Feature #6631: Provide security (e.g. display only) for custom fields added
Updated by Jan from Planio www.plan.io over 8 years ago
- Status changed from New to Closed
- Resolution set to Invalid
Part of this was implemented in #1746. Furthermore, after almost 5 years of experience working with Redmine professionally, present time Jan disagrees with past time Jan. Migrations with own tables and columns are always better than trying to stuff things in magic custom fields... :-)
I am therefore closing this issue as invalid.