User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:diff_emails_requirements

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
mantisbt:diff_emails_requirements [2007/10/29 20:26] giallumantisbt:diff_emails_requirements [2008/10/29 04:25] (current) – external edit 127.0.0.1
Line 1: Line 1:
-====== Template for Requirements ======+====== Diff email Requirements ======
  
    * **Author**: Gianluca Sforna (giallu)    * **Author**: Gianluca Sforna (giallu)
Line 118: Line 118:
 ==== Implementation Log ==== ==== Implementation Log ====
   * Nothing yet   * Nothing yet
 +
  
  
 ===== Feedback ===== ===== Feedback =====
   * Please provide 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.1193703975.txt.gz · Last modified: 2008/10/29 04:31 (external edit)

Driven by DokuWiki