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
Diff email Requirements [Mantis Bug Tracker Wiki]

User Tools

Site Tools


mantisbt:diff_emails_requirements

Diff email Requirements

Introduction

A different email style for notifications was requested more than once (with smaller variants) from ages.

Basically, what we want to obtain is a more compact (and readable) email to be sent to users, so that only the relevant modifications that triggered the notifications will be shown.

An example is always worth 1000 words; a sample email I got from mantis:

The following issue has been UPDATED. 
====================================================================== 
http://www.mantisbt.org/bugs/view.php?id=8508 
====================================================================== 
Reported By:                giallu
Assigned To:                
====================================================================== 
Project:                    mantisbt
Issue ID:                   8508
Category:                   preferences
Reproducibility:            have not tried
Severity:                   trivial
Priority:                   low
Status:                     new
====================================================================== 
Date Submitted:             2007-10-25 07:13 EDT
Last Modified:              2007-10-28 19:58 EDT
====================================================================== 
Summary:                    Avoid using "example.com" in configuration options
Description: 
Both config_inc.php.sample and config_defaults_inc.php set, by default or
after conditional checks, some parameters with example.com domains.

for instance, config_inc.php.sample has:

$g_webmaster_email = 'webmaster@example.com';

While no harm is being done, I think the default should be to point to
localhost (which is, btw, what is done on the Fedora package with a patch)
====================================================================== 

---------------------------------------------------------------------- 
 (0016015) giallu (developer) - 2007-10-28 19:58
 http://www.mantisbt.org/bugs/view.php?id=8508#16015 
---------------------------------------------------------------------- 
ping 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2007-10-25 07:13 giallu         New Issue                                    
2007-10-28 19:58 giallu         Note Added: 0016015                          
2007-10-28 19:58 giallu         Priority                 normal => low       
2007-10-28 19:58 giallu         Severity                 minor => trivial    
======================================================================

And one from Bugzilla, for a similar set of changes:

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Merge Review: openobex


https://bugzilla.redhat.com/show_bug.cgi?id=226215


bugzilla@redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |medium
           Priority|normal                      |medium
            Product|Fedora Extras               |Fedora




------- Additional Comments From xxx.xxx@xxx.xxx  2007-10-13 11:03 EST -------
Ping?

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Implementation Notes

The main problem with this implementation is that a single mail could include multiple operations, performed as a single update.

Since the changes are performed in different part of the code, the best approach looks like exploiting the existing history table, and compose the mail starting from that informations.

A new database field in mantis_bug_table will store the timestamp to start composing the diff from

Database Changes

  • Required database changes to mantis_bug_table
    • add a “lastdiffed” field (timestamp) with the time at which information about this bug changing was last emailed

Configuration

Administrator configuration options:

  • $g_default_email_style - CLASSIC or DIFF

User configuration options:

  • Email style - CLASSIC or DIFF from the preferences panel

Implementation Log

  • Nothing yet

Feedback

  • Please provide feedback
  • (jreese) This shouldn't need a special entry in the database. Can we not just assume that an email being sent will only need the changes being made at this specific point? Why do we need to keep more information in the database that (IMO) is redundant. We should be able to generate a diff the same way we generate history entries.
  • (jreese) Is there a simple way to abstract this system in a manner which will allow 'pluggable' or 'themeable' formats to be used in place of the existing two? Alternatively, is this something that could benefit from usage of templates of some sort? I ask because I'm sure the moment we implement diff style emails, we will get twice as many requests for new and different email styles, and it would be nice to abstract this into an easy system to create new styles.
  • (jreese) Thought experiment: Rather than simply modifying the existing system, perhaps we could adapt the event-based system that I created for plugins to also do work for the core API's. Then the bug create / update pages could bundle a set of changes and send it to an event, and both the email and history systems could hook into this for gathering information about what's changed, and then the email system could decide from there how to deal with it based on user's preferences. </idea>
  • (vboctor) As jreese said, this feature should take into consideration that we will need to support html emails and template based emails in the future.
  • (vboctor) Currently if a user does multiple changes right each other, this will result into multiple emails. In the case where email queuing is enabled, it would be nice if we can consolidate these changes (if possible without adding too much complexity).
  • (vboctor) phpBB sends emails that notifies that a thread is modified, but doesn't provide further details. This simplifies the design but is not as useful as the current ones sent by Mantis or the proposal diff email.
  • (vboctor) Related features that are not really part of this feature:
    • (vboctor) “Why are you receiving this email?” seems to be a nice feature to add.
    • (vboctor) Would be nice to support a way where a user can disable future notifications relating a specific issue, even if the user is the reporter, developer, or an issue note author.
    • (vboctor) If two users are updating an issue in parallel, then the first one that submits the changes wins and the second will get an error since the last_update time stamp will be different than the one retrieved when the data was retrieved from the database.
mantisbt/diff_emails_requirements.txt · Last modified: 2008/10/29 04:25 (external edit)