DokuWiki Installer

:

This page assists in the first time installation and configuration of Dokuwiki. More info on this installer is available on it's own documentation page.

DokuWiki uses ordinary files for the storage of wiki pages and other information associated with those pages (e.g. images, search indexes, old revisions, etc). In order to operate successfully DokuWiki must have write access to the directories that hold those files. This installer is not capable of setting up directory permissions. That normally needs to be done directly on a command shell or if you are using hosting, through FTP or your hosting control panel (e.g. cPanel).

This installer will setup your DokuWiki configuration for ACL, which in turn allows administrator login and access to DokuWiki's admin menu for installing plugins, managing users, managing access to wiki pages and alteration of configuration settings. It isn't required for DokuWiki to operate, however it will make Dokuwiki easier to administer.

Experienced users or users with special setup requirements should use these links for details concerning installation instructions and configuration settings.

For security reasons this script will only work with a new and unmodified Dokuwiki installation. You should either re-extract the files from the downloaded package or consult the complete Dokuwiki installation instructions

driven by DokuWiki powered by PHP
Custom Field Display Requirements [Mantis Bug Tracker Wiki]

User Tools

Site Tools


mantisbt:custom_field_display_requirements

Custom Field Display Requirements

Author: Ryan O'Leary

Introduction

This feature is documented here: http://bugs.mantisbt.org/view.php?id=5744

Mantis allows for creation of custom field definitions for bugs. Currently, Mantis implements code allowing configuration of when the each custom field is displayed and when each custom field is a required field. The current configuration allows the user to specify the display/require option on 4 conditions; report, update, resolved, closed. The report, resolved, and closed conditions each map to one Status. The update conditions maps to all other statuses.

This feature will allow the individual mapping of custom field display/require properties with every individual Status.

Database Changes

  • Add a field to the custom_field table to store the serialized array of display options for every status (varchar(255)). This data is stored as a serialized 1-dimensional array in the format a[status_id]=[display_value] where display_value = {0=none;1=display;2=require}. – NOTE: This will limit the amount of statuses to around 27. If we want to support more than 27 Statuses, we should make this a TEXT field instead.
  • Delete the existing fields that are used for display/require properties in the custom_field table. (display_report, display_update, display_resolved, display_closed, require_report, require_update, require_resolved, require_closed).

Configuration Changes

  • Add string $s_edit_custom_field_status_title for the Custom Field Configuration page sub-title.
  • Add strings $s_custom_field_require, $s_custom_field_display, $s_custom_field_none for the Custom Field Configuration column titles.
  • Remove strings $s_custom_field_display_report, $s_custom_field_display_update, $s_custom_field_display_resolved, $s_custom_field_display_closed, $s_custom_field_require_report, $s_custom_field_require_update, $s_custom_field_require_resolved, $s_custom_field_require_closed as they are no longer required.

General Changes

The most visible change to the users is in the configuration of custom fields. Each field now has a table at the bottom showing the mapping of display value to Status. An example is here: :mantisbt:mantisbt_5744.jpg

The setting applies to viewing bugs, updating bugs, and changing status.

Reminders

As part of the patch attached to bug 5744, I've added a function called migrateCustomFieldDisplay(). This function will take the current custom fields settings using the display_ and require_ fields and transition them to the new display setting array. In the patch, the function is never called. During an upgrade, the function needs to be called AFTER the php patches have been applied, AFTER the new field has been added to the custom_field table, and BEFORE the old display_ and require_ fields are removed from the custom_field table.

The strings specified above that were removed, were only removed from the strings_english.txt file, not any of the other languages. Same with the strings added.

Integration Features

Not sure if this is correct, but in the MantisConnect API code, the new field that stores the display value as a serialized array returns it as such. So you'd get something like: “a:10:{i:10;i:2;i:20;i:1;i:30;i:2;i:40;i:2;i:50;i:1;i:60;i:1;i:70;i:2;i:71;i:2;i:72;i:0;i:73;i:0;}”

Feedback

thraxisp - What happened to the 'Advanced' setting? This controlled fields that were displayed on the Advanced pages.

  • roleary - The Advanced setting is still available (it's above the screenshot that I attached). However, I believe that “paulr” has taken my patch and is modifying it, and that the Advanced setting is something he's changing. Part of this is because it obviously doesn't make sense to have a field 'Required' and 'Display only on Advanced'. When he finishes his update, I'll change this page.

—-

thraxisp - I assume that the visibility by access level is retained. That is, viewer can't see fields with the read parameter set to a higher level.

  • roleary - The visibility of fields is retained. Again, this could lead to a business rule issue where a field is not visible, but has been marked as 'Required'. In that case, it actually wouldn't get checked because it wouldn't have been displayed… I think. This issue will probably also be resolved by paulr's changes.

—-

Please add your comments and feedback in this section.

mantisbt/custom_field_display_requirements.txt · Last modified: 2008/10/29 04:25 (external edit)