caylan / bulletin Goto Github PK

For each post, the gravatar is loaded, regardless if it has already been loaded.

We should see if we can cache these somehow.

Currently, for the email sending page, the redirection used is another POST once the page is refreshed. This needs to be a GET request (or something).

We can probably migrate the schema successfully on the website, but we'll need to make sure we can do it on a practice database. We're going to lose all the comments since they're associated with static groups, so it might be good to clear those out first to make everything smoother:

 for post in Post.objects.all():
     post.delete()

Don't forget to use south! And make sure to read up on using it with an already-established database (don't run syncdb, whatever you do!)

Either there needs to be a root AbstractEmailManager, or there should be two separate apps for email-based invitations and website-based invitations.

A group's posts shouldn't all be shown at page-load. Instead, there should be an option to show more posts. e.g. show the first x posts, when user scrolls to the bottom (or presses button), load y more posts.

We need to be able to log in and have a persistent session. This will likely depend on other smaller issues like email account activation.

When viewing a group, show a list of current users in the group.
If admin of the group, add option to remove the user.

As a way to speed up load times, the group view should only load a certain amount of posts when a user visits.

When looking at a group page, the user is probably 90% of the time only going to be looking at recent posts.

The current group and post tests are broken due to the nature of dynamic groups. The tests will need to be refactored in order to function properly.

Email confirmations need to be resent if the user is not activated. At the moment, regardless of whether the user is active, the user cannot send an activation email twice.

This isn't necessarily a high priority issue, as people don't tend to go without the use of cookies very often. However, it would be nice to show the user that they need to have their cookies enabled in order to use the site, rather than forcing them to log out.

The method outlined in the django documentation on cookies is (unfortunately) haphazard and does not function. For example, if a user (in out implementation, anyway) uses the login and fails twice, the code block in session.views.login_view wherein the POST is checked will assume the test cookie sent to the user for validation didn't work (because it will have sent a new one).

There's likely a very simple work around for this, one being that if a test cookie is already on the person's computer, we don't try to add in another one (we won't know if the cookie was added until they issue a second request). Either that, or we could do what facebook seems to do, which is to redirect the user after having sent them a cookie in order to force them to send a second GET request, at which point we could see if the cookie was accepted.

Title says it all (at the moment). We need to use django's group implementation (or extend it) so that we don't have to worry too much about user creation. This depends on Issue 7

We currently have static groups. We need users to be able to create their own groups and invite other users to the group.

Different from Dynamic groups, a user (for the first release) should at least be able to post to groups, having their user information displayed properly.

Placeholder texts for inputs (e.g First Name) don't appear in IE

When AJAX gets an error code, right now nothing is handling it

This issue is an issue

I have two groups both named 'Bulletin' (one ours, the other Wayne's). Users should be able to give the groups they're in a custom name in order to distinguish. This ought to involve an addition to the Membership model, i.e. 'group_alias'.

Same problem that was with posts.

When another user posts to a group, no other users will see the post until they refresh the page (this includes projects). There should be a way to periodically check for new posts and update the page when other users post.

We need to have a way for users to reset their forgotten passwords.

It is nice.

Django has some middleware that does this already, but it's a lot of boilerplate to put in.

Essentially, we want to put in a different render_to_response function that takes in a dictionary object and appends a csrf token to it (I'm not 100% sure how this works, but it seems useful). This only needs to be done for sections of code using the "POST" method, not the "GET" method.

Traceback

...that is, posting comments. For now, maybe like Facebook style, where there is a comment box just chillin' at the bottom of each post. This would just require form field with a text field and submit button, and a hidden field that will hold the post id

Expired email confirmations aren't confirmed to have been deleted properly as of the latest revision. We need to make sure deletion can be properly automated, and if so, this code should likely be abstracted (or documented in, say, the resources wiki) so that any other time-sensitive models can use the same interface such that they expire properly.

This is a general security issue. We simply don't want other people logging into the same account from multiple computers.

For now, since we don't really have active sessions for a particular user we'll need those first.

As quoted from the requirements:

"A user cannot explicitly join a group. They have to be invited to a group. And upon accepting the request (through email and/or in their inbox if they are already registered), the user will remain in their login page and the group will be added to the other existing group tabs."

Therefore either there should be some static group that the user joins upon signing into the website for the first time, or they must create their own group when registering.

This depends on Issue 6

So far there is no way to see the current members within a group, even if you're an admin. Adding the members in a group will make it easier for admins and members to see who they're talking to every time they make a post or comment.

Showing the invitations for a group will make it possible for the admin of the group (or the whole group if we so choose) to know who has already been invited to the group and not yet responded to their email confirmation.

It would also be a useful addition to show when a user has joined the website, and, in the case of invites, how long ago an invitation was sent to a particular email address.

Everything is vacuously true.

Thought it might already be in the works, the commenting system is a bit irritating to use once the comments chained to a post has become quite large.

Having the comment button all the way to the right of the post and then having to scroll all the way to the bottom of the chain afterwards isn't entirely intuitive.

Either a) have the comment create an anchor and jump to the bottom when hitting comment, or b) have the comment button at the bottom of the list of comments (and of course, if these are both bad ideas, just implement something else, so long as you use your best judgement).

Though this could easily be a separate issue, it might also be good to include a show/hide comments button.

users should be able to get a tutorial of sorts. not sure what it's going to look like yet. perhaps the site is simple enough that we don't actually need a tutorial.

Anton mentioned this, we need to add it to the reqs and make sure and think about it when we build the authentication module.

Furthermore, this is dependent upon Issue 7 (persistent account creation and user sessions).

As of yet, we don't have email authentication when a user attempts to register themselves.

We don't have any milestones for when we want to finish features/fix bugs!

our passwords are lacking flavor

We need a way to invite other people to groups. This could be done a few different ways: a link, an inbox notification (this, of course, requires that a) a user is a member, and b) we actually have a functioning inbox (which may likely need to be added into the database schema (...perhaps another issue) so we can see it from ages in the past).

This depends on two issues, namely Issue 25, and Issue 12, in order to run properly.

When you create a new group and try to make a first post, nothing happens. The post is saved correctly and appears on refresh.

Might be a javascript or template issue.

As of current, we have no way to send static resources. We're running in debug mode, which serves all static resources locally. When we get to production, we'll need a way to securely send static resources to the web-page independent of our own web app.

This can likely be done with any conventional web server (like Apache, for example).

I just got an invite to join Wayne's world (group). I already have an account using the email [email protected], however, he invited me with a different email, [email protected].

• You should be able to sign into your current account and accept the invite.

Also, say I didn't already have an account, got invited with [email protected], but wanted to use [email protected] instead. The current screen you're brought to for registration doesn't allow you to change it.

• You should be able to change the email address when registering via invite.

'block' tag with name 'nav' appears more than once

In template ~/templates/prototype/group.html, error at line 37

A user, after dynamic groups have been added, should be able to properly post within them. This, of course, depends on Issue 6, and Issue 14.

There's a lot of it.
Would it be possible for someone to draw up a relational diagram for it?
It would be a really cool thing to add the the arch doc too :)

Since we use the email as the username in Django's provided User model, we are limited to 30 characters. It should at the very least have the regular email field's 75 characters.

During the meeting, Yoong put an email and password in the login screen and then he pressed register button hoping to register a new account. We need to change the placement of button

If one hammers the post button, then the post gets made on the server as many times as one manages to hit the post button before the page is refreshed. This could probably be fixed by simply clearing out the text box when the post button is pushed.

We need to be able to see inbox notifications for when things change under the users' noses. These could be for all sorts of things (which should be outlined in the requirements, of course) like posts in groups that haven't yet been seen, messages (if we ever add those), comments, invites, etc, etc (again, most of these will likely spawn as issues somewhere in the tracker).

Upon creating an inbox, we'll also need to be able to deal with clearing it out when the user has seen everything (or manually clears it out on their own).