Private messages

[ethel-t-frog]

Revive the "notes" feature from Ficly. With notification e-mails, of course.

[stitzelj]

In the process of researching, designing, and implementing this feature.

[ethel-t-frog]

As with #27, this feature must allow users to block other users. We should probably put an "alert admin" button on each message as well, just in case people receive unwelcome messages. We don't seem to have any abuse on the site as yet, but we should not let it catch us unprepared.

[stitzelj]

For now, I'll go ahead and build and implement the PM system and get it out there for use, especially since right now we have a pretty small and polite community. But I'll definitely bump up the blocking module on the list of priorities so that we don't get blindsided by poor behavior at some point down the road.

[ethel-t-frog]

I'm OK with that. As long as we put the safety features in place before the need for them arises, we have succeeded.

[stitzelj]

I was going to try to use the django-messages module for our private messaging system, but it's just a little bit dated and very poorly documented, and I'm not entirely happy with it. Part of the problem with it is that there's not a real easy way to tie it into using our authentication system with the Profiles module without hacking the source code itself after installing it. So it looks like I'm going to try rolling up something from scratch that simple, which, frankly, should suit our needs just fine. I'm thinking that'll make it easier to incorporate future features, locking the privacy/blocking mod, anyway.

[ethel-t-frog]

Sounds good. If you can, can you put it in a separate directory, please? At the moment, everything is under castle/ and pretty-much all the Python code is in castle/views.py. This isn't really a very sustainable approach (it's a symptom of my own time learning how to drive Django).

Code it up as a separate Django app if you can (python manage.py startapp notes), then we can keep the files a bit separate. At some point, I'd like to break up castle/ into more managable chunks, breaking out authors, stories, prompts and challenges into separate files/apps if possible. Pull in the models from castle with

from castle.models import *

and the rest should be fairly straightforward. The url management should be fixed too.

Oh, like so much of life, it's a bit of a mess.

[stitzelj]

Sure, I'll investigate how to implement that and figure out how to make it work.

[HSAR]

Good idea to try the django-messages module - reusing code is good. Shame it didn't work out.

[stitzelj]

Yeah, the way it's built, it doesn't hook easily into our custom User model. It wants to use the hidden usernames from the default User model, rather than the Profile, for the compose form, which is just not a workable solution, since no one ever sees or knows their actual usernames. I can get around it for displaying a user's pen name pretty much everywhere else in the app, but I haven't been able to find a way to hook the compose form in so that it will accept the pen name rather than the username for the recipient field. So, I think at this point it's just going to be easier to roll my own code that uses our existing Profile model and authentication and have the compose view lookup the username behind the scenes when provided the pen name. The only potential complication there is if, for some reason, two users have the same pen name, but that's never been an issue that I'm aware of, so I'm not too concerned about potential conflicts there. I'm also going to build it so that there's a 'Send Note' button on every Author page that will take a user directly to the Compose screen. I'll use django-messages as a reference, especially for the initial model build. It seems to be a solid foundation to start, but then I'll write the views and compose form more or less from scratch from there to be more in line with the way the rest of the system is built.

At this point, it's look like it may be into next week before I have something ready to deploy. My sleep has been garbage for the last week, so I'm pretty exhausted right now. I'm also planning to be out of town this weekend starting tomorrow, so I don't know how much work I'll get done between now and Tuesday.

[ethel-t-frog]

It should not be possible for a user to set their pen name to a name that is already in use, In fact, the name is converted to upper-case, stored in pen_name_uc and should be unique. I should add a trap in the model to enforce uniqueness at the DB-level as well, now that I mention it.

[stitzelj]

Ok, that makes things easier, then. I wasn't sure about that because I didn't see anything in the model that strictly enforced uniqueness at the pen name level, so I assumed it was potentially possible for two people to have the same pen name.

[ethel-t-frog]

Unique constraint added, so now it's enforced at DB-level.

[stitzelj]

Just as a status update, I'm about 95% done with this. I'm hoping to push the commit out tomorrow.

[stitzelj]

The Notes module is complete and has been added to PR #31

[ethel-t-frog]

Thanks. Really really busy just now. I'll see if I can get it in between now and Sunday.