Maybe issue 0001139 should be also covered here.

Proposal:

A number of Config Options could be 'per-user' or 'per-project'. The implementation needs to be backwards compatible in that existing "config_inc.php / config_defaults_inc.php" settings should be preserved.

Setting the options will require a new UI (Manage Configuration) under the Manage section. It will make use of the project selection (current project or All Projects).

Settings should also be cached for performance.

Schema: Add a new table (mantis_config) containing config_id (string), project_id(int) , user_id(int), type(int), value(string). The type field is used to define the coding for the value string. Examples are int, string, and serialized value.

Changes:
config_get()
looks for specified config_id + current user + current project.
if not found, config_id + current user + all_project
if not found, config_id + default user + current project
if not found, config_id + default user + all_project.
if not found, use GLOBAL[config_id]

Open Issues:
1) should this replace the existing user preferences?

By "string", do you mean "varchar"? If so, I think that "blob" (medium perhaps) is more appropriate, since it may pottentially contain many different types of data (possibly serialized).

Fields in database:

email:
$g_default_notify_flags
$g_notify_flags
$g_email_receive_own (extend to per user in future)
$g_default_email_on_new
$g_default_email_on_assigned
$g_default_email_on_feedback
$g_default_email_on_resolved
$g_default_email_on_closed
$g_default_email_on_reopened
$g_default_email_on_bugnote
$g_default_email_on_status
$g_default_email_on_new_minimum_severity
$g_default_email_on_assigned_minimum_severity
$g_default_email_on_feedback_minimum_severity
$g_default_email_on_resolved_minimum_severity
$g_default_email_on_closed_minimum_severity
$g_default_email_on_reopened_minimum_severity
$g_default_email_on_bugnote_minimum_severity
$g_default_email_on_status_minimum_severity
$g_default_email_on_priority_minimum_severity
$g_default_email_bugnote_limit
$g_view_handler_threshold
$g_view_history_threshold

Issue Defaults:
$g_default_bug_view_status
$g_default_bugnote_view_status
$g_default_bug_severity
$g_default_bug_priority

View:
$g_default_advanced_report
$g_default_advanced_view
$g_default_advanced_update
$g_history_default_visible
$g_history_order

Reminder Settings
$g_store_reminders
$g_reminder_recipents_monitor_bug
$g_default_reminder_view_status

Sponsorship Settings
$g_enable_sponsorship
$g_minimum_sponsorship_amount = 5;

File Upload
$g_allow_file_upload
$g_file_upload_method

Status / Workflow Settings
$g_bug_submit_status
$g_bug_assigned_status
$g_bug_reopen_status
$g_bug_reopen_resolution
$g_bug_readonly_status_threshold
$g_bug_resolved_status_threshold
$g_auto_set_status_to_assigned
$g_status_enum_workflow
$g_report_bug_threshold
$g_update_bug_threshold
$g_monitor_bug_threshold
$g_private_bug_threshold
$g_handle_bug_threshold
$g_private_bugnote_threshold
$g_bug_reminder_threshold
$g_delete_bug_threshold
$g_set_view_status_threshold
$g_change_view_status_threshold
$g_update_readonly_bug_threshold
$g_view_changelog_threshold
$g_update_bug_status_threshold
$g_set_status_threshold
$g_limit_reporters
$g_allow_close_immediately
$g_allow_reporter_close
$g_allow_reporter_reopen

Project Settings
$g_upload_project_file_threshold
$g_view_proj_doc_threshold
$g_manage_news_threshold

Bugnote Settings
$g_add_bugnote_threshold
$g_update_bugnote_threshold
$g_delete_bugnote_threshold
$g_bugnote_allow_user_edit_delete

Custom Fields
$g_manage_custom_fields_threshold
$g_custom_field_link_threshold

Yes, "value" should be a BLOB (up to 65k).

How are you going to handle access to change the values in the DB? Example: could a manager change the values in 'Issue Defaults:' but only an admin change all others?

I know it will be easy to restrict any changes to admin, but it may be wise to include access permissions based on roles in the DB as well. What do you think?

One other thing to consider: settings in the database will control who can change settings in the database. This raises the possibility that someone could change settings in such a way that nobody can access the settings thereafter. There will need to be some sort of "rescue" mechanism that allows recovery from such changes, like a config_emergency_inc.php.

The initial implementation was intended to be accessible by Administrators only. Adding an additional field to the table (access (int)) would allow others to change things. Since someone has to be trusted, I would leave that field accessible by administrators only.

For the UI, we could leave viewing accessible to all (most?) and get both the update and view function out of the same set of pages.

OK, I guess the fact that you didn't include "$g_manage_user_threshold" in the list of fields to move to the database means the only way an installation could screw itself is to delete all administrators, which would be a bad thing today as well.

thraxisp: is your list of fields same as the list I added to wiki previously?

"Yes, "value" should be a BLOB (up to 65k). "

We might need to think about this one - adodb datadict only has 'B' (as longblob).
mssql schema uses IMAGE, pgsql BYTEA...

Surely, we want a text format, not a binary format for storing configuration variables?

thraxisp: is your list of fields same as the list I added to wiki previously?

"Yes, "value" should be a BLOB (up to 65k). "

We might need to think about this one - adodb datadict only has 'B' (as longblob).
mssql schema uses IMAGE, pgsql BYTEA...

Surely, we want a text format, not a binary format for storing configuration variables?

Yes, the list is roughly what was posted on the developer's wiki.

Given that I was thinking of serializing arrays / structures, a large text field is what is needed. The XS type you added would work.

This is now partially coded. I've attached a screen shot of the email notification configuration screen.

Quick question, if I add a custom status (per the manual) will the additional statuses be available to configure with these changes?

E.G. I add 'Waiting Approval' after feedback. Will I see a row for this status?

Yes, the page is built dynamically based on the enumerations.

A prototype of the workflow configuration has been attached.

Is there a way of handling multiple values (arrays)?
Will be neccesary if you ever want to move from using thresholds to fixed values.

Blobs aren't beautiful and certainly not readable or editable. Personally I'd prefer storage as strings. Better to understand, restore and for maintenance.

Array (and objects) are currently handled by serialization.

Personally, I think that internal storage is what is easiest for the system to use. A GUI is provided for users to see the result in a friendly fashion. The workflow is stored internally as an array, for example.

I uploaded an Excel spreadsheet to enumerate all of the current settings. It has descriptions for all of the configs, their possible values and most of the defaults. It also has columns to set whether a config should be settable globally, by project, or by user. I've also added columns showing whether the values should be set from an installer or UI (or neither).

I'll start a thread on the forum for discussion. (http://forums.mantisbt.org/viewtopic.php?p=232)

Most of this was done a long time ago. I think that individual bugs should be raised for mssing configuration pages. Asuning people actually use them.