About notification system

[mizuv]

You might say notification is not a main feature, But I think this is a core function of our service.

How will we handle this? Will you add this feature after completing all the other features, or design from the beginning? If you add it later, it is more likely that you need to fix the existing one, not simply adding the model.

We need to notify when

1. For host users, when there is a new entry in the meeting : meeting, membership
2. For host users, when there are new comments in the meeting : meeting, comment
3. When the application is accepted or rejected : meeting, membership
4. When a comment is in reply : meeting, comment

If there is any other situation which should be notified, please comment.

[dwmarcuskim]

It might be better if we can notify a new meeting of clients' interest, but not sure if we can do it.....

I was think of how to make notify system, and here's my idea.

1. (on Backend) Make a field "unchecked"
2. (on Backend) Whenever change comes, (by PUT, POST, DELETE), set the field "unchecked" to true.
3. (on Frontend) Whenever request 'GET', check all "unchecked", and add message to a state.notification --furthermore: Since client only get notification when he or she is on-line. Therefore, I'm sure that it will be okay to keep messages in state(i.e. user's internet cache).
4. (on Frontend) If user check the notification, request 'PUT' so that it can change "unchecked" field true to false.

Since it requires a hard-connected between frotnend and backend, I think it should be better implements after we done our most of jobs.

[mizuv]

It might be better if we can notify a new meeting of clients' interest, but not sure if we can do it.....

I was think of how to make notify system, and here's my idea.

1. (on Backend) Make a field "unchecked"
2. (on Backend) Whenever change comes, (by PUT, POST, DELETE), set the field "unchecked" to true.
3. (on Frontend) Whenever request 'GET', check all "unchecked", and add message to a state.notification --furthermore: Since client only get notification when he or she is on-line. Therefore, I'm sure that it will be okay to keep messages in state(i.e. user's internet cache).
4. (on Frontend) If user check the notification, request 'PUT' so that it can change "unchecked" field true to false.

Since it requires a hard-connected between frotnend and backend, I think it should be better implements after we done our most of jobs.

When we have change on our database model, we use Django's 'save()' function, and we can override it. Thus, when a database changes, you can automatically create and modify notifications, and you can further isolate the backend and frontend. Here is my idea.

• Our new model 'Notification' is connected with User by foreign key.
• Our new model 'Notification' has 4 fields; user(User), checked(bool), url(url), notification(string).
• When there is change on our model(new entry or comment, etc..), we automatically create Notification and set every field.

Then what frontend should do is to check if there is new notification(GET) for every page refresh, and when user click the notification request 'PUT' so that it can change 'checked' field false to true. (Finally we should just link with url field.)

I think is not that difficult. If there is any problem that I didn't catch, please comment.

[dwmarcuskim]

Implemented done. Closed.