mantisbt:diff_emails_requirements
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
mantisbt:diff_emails_requirements [2007/10/28 20:12] – created giallu | mantisbt:diff_emails_requirements [2008/10/29 04:25] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
* **Author**: Gianluca Sforna (giallu) | * **Author**: Gianluca Sforna (giallu) | ||
Line 6: | Line 6: | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | A different email style for notifications was requested more than once (with smaller variants). | + | A different email style for notifications was requested more than once (with smaller variants) |
Basically, what we want to obtain is a more compact (and readable) email to be sent to users, | 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. | so that only the relevant modifications that triggered the notifications will be shown. | ||
Line 95: | Line 96: | ||
===== Implementation Notes ===== | ===== Implementation Notes ===== | ||
- | * Some 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 ==== | ==== Database Changes ==== | ||
- | * Required database changes to '' | + | * Required database changes to '' |
+ | * add a " | ||
==== Configuration ==== | ==== Configuration ==== | ||
- | | + | Administrator configuration options: |
+ | | ||
+ | |||
+ | User configuration options: | ||
+ | * '' | ||
==== Implementation Log ==== | ==== Implementation Log ==== | ||
+ | * Nothing yet | ||
- | |||
- | ===== Other Changes ===== | ||
===== Feedback ===== | ===== Feedback ===== | ||
* Please provide feedback | * Please provide feedback | ||
+ | |||
+ | * (jreese) This shouldn' | ||
+ | * (jreese) Is there a simple way to abstract this system in a manner which will allow ' | ||
+ | * (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' | ||
+ | * (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. | ||
+ | * (vboctor) phpBB sends emails that notifies that a thread is modified, but doesn' | ||
+ | * (vboctor) Related features that are not really part of this feature: | ||
+ | * (vboctor) "Why are you receiving this email?" | ||
+ | * (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.1193616722.txt.gz · Last modified: 2008/10/29 04:31 (external edit)