Confirm
574
edits
Changes
= Use cases =
== Trigger a notification ==
# Notify anytime any Document changes.
# Notify anytime a Document in a certain locale changes.
# Anything Fred does
# Tell what the user is subscribed to
# Notify any new thread in a given discussion forum
# Notify any post (new thread or reply) in a given discussion forum
# Notify any post in a discussion thread
# Notify any new thread in any KB forum in a given locale
# Notify any post in any KB forum in a given locale
# Notify any new thread in a given KB forum
# Notify any post in a given KB forum
# Notify any post in a given KB forum thread
# Notify on new question (confirmed)
# Notify on new answer to a given question
# Notify on answer marked as solution to a given question
# Notify on new flagged item for review
== Deliver notification ==
=== Logged in user ===
(non-exclusive)
* To email
* To private message
* (Future, other options?)
=== Anonymous user ===
* To email
If a user registers, we should look for any anonymous watches with that email address and add them to the user, when the user is confirmed.
= Evolution of table structure =
== Iteration 3: More normalization, yielding better queryability: orthogonality of path elements (not just hierarchy) is possible without ridiculously inefficient substring queries. I don't think the joins would be too bad, but benches would be nice. Maintains referential integrity of object and content type. == watches: id content_type object_id event_type user/email/whatever 1 15 2345 UntranslatedEvent
on UntranslatedEvent for object_id=2345 and content_type=15:
This will bring it up to an (n+1)-table join, n being the max length of a certain event type's path *including* content type and object ID.
: Don't hamper work now because of Postgres. Assume we're on MySQL until Oracle shows up with a bill.
= Features =
