Notifications

[kristofbc]

A new /notification endpoint was added and is coming with:

• A Notification model;
• A NotificationSerializer;
• A set of views (list, retrieve and update only, since the notification are generated by the back end, and not the user);
• And 2 new urls.

For now, notifications only exists when a tasks is created. They're automatically generated via a signal "post_save" at the end of models.py

[RignonNoel]

One commit message is too long, please just rewrite the message.

Very good work! Just some rewrite of the view on the get_object_or_404() in particular, i was perplexe at the begining but the correction seems good to me! The final is just as i love! ;)

[RignonNoel]

I think we need to remove this field in the serializer and just put the actual user in the created_by field when the task is created to not allow edition on this field.

For the moment i can call the API to say the creator is an other guy because the get_initial() function of the view just populate field if is not already given (say me if i'm wrong)

---

PS: I think we can made this population of the field in the serializer with the create function. Or if is not possible with a signal on the model when create.

[kristofbc]

The create function requires the context to have the logged in user. Instead, In my new commit, I enforce the user inside the view class.

[kristofbc]

@RignonNoel I enforced the user to be always set with the perform_create and perform_update from the CreateModelMixin and the UpdateModelMixin

[RignonNoel]

Oh sorry i've miss you're last commits!
I will take a look tomorrow, i promise :)

[RignonNoel]

The fix seems good to me! I'm just not sure with the blank attribute on created_by but it's not a big deal, it's just we can add a bad tasks if we create a new view and forget this steps.

[RignonNoel]

I'm not sure with this line. I think it may be good to have this field required.