Redmine

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:

1. 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:
   1. invisible & not editable: the field can be used internally by a plugin without interference by users
   2. 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
   3. 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.
   4. visible & editable: this is the default case which we have right now
2. simply create project_preferences, issue_preferences, etc. similar to user_preferences

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.