190
edits
Webtools:Mozparty: Difference between revisions
no edit summary
m (→Wil's Points) |
No edit summary |
||
| Line 8: | Line 8: | ||
= New Issues = | = New Issues = | ||
* | * Migration plans from [http://firefoxparty.com/ current party tool] need to be worked out | ||
** All users currently stored in flat-files for every country | |||
* README with steps to test (verify that things are working) -- there isn't a solid way to test all of this -- so even after it's set up, what are the criteria to test it by to make sure it works end-to-end? | |||
= Wil's Points = | |||
= Resolved Issues = | |||
== Wil's Points == | |||
* <strike>/config/database.php shouldn't be in the repository. IT prefers a .default or -dist file. (Same goes for config/bootstrap.php if you expect IT to change values in it)</strike> | * <strike>/config/database.php shouldn't be in the repository. IT prefers a .default or -dist file. (Same goes for config/bootstrap.php if you expect IT to change values in it)</strike> | ||
| Line 19: | Line 21: | ||
** any special server requirements | ** any special server requirements | ||
** steps to install</strike> | ** steps to install</strike> | ||
* <strike>Line 288 of controllers/user_controller.php has a hardcoded link in it that isn't going to work.</strike> | * <strike>Line 288 of controllers/user_controller.php has a hardcoded link in it that isn't going to work.</strike> | ||
| Line 35: | Line 36: | ||
* <strike>After updating a profile, the user is logged out</strike> | * <strike>After updating a profile, the user is logged out</strike> | ||
* <strike>When updating a profile, if a password is entered into the first box but not the second (or the second doesn't match), the password overwrites the saved password in the database in plain text. -- | * <strike>When updating a profile, if a password is entered into the first box but not the second (or the second doesn't match), the password overwrites the saved password in the database in plain text. -- This no longer produces an overwrite in plaintext, but it does not show an error of any sort, and takes the user back to their home page. It is a bad UI experience and should be fixed, IMO. This is pretty much the same issue as below.</strike> | ||
* <strike>When updating a profile, if a password is entered into the second box but not the first, the form continues submission, no updates are made, no errors are shown -- | * <strike>When updating a profile, if a password is entered into the second box but not the first, the form continues submission, no updates are made, no errors are shown -- Same problem as above. When passwords to not match you should stop submission and show an error.</strike> | ||
* <strike>going to /party/view/<number> and clicking "Count me in!" will create rows in the database for parties that don't exist</strike> | * <strike>going to /party/view/<number> and clicking "Count me in!" will create rows in the database for parties that don't exist</strike> | ||
* When viewing a party that is invitation only, there is no way for someone to tell that they have to be invited. -- | * <strike>When viewing a party that is invitation only, there is no way for someone to tell that they have to be invited. -- This is still an issue -- a user really has no way of seeing "parties I've been invited to".</strike> | ||
* <strike>After the invite is sent out, user goes to register page, but then has no where to go. The original invite is lost, somehow. Also, if you send an invite out to an existing user, why shouldn't have to re-register, and they should also retain the invite context (be added to the party when they do log in).</strike> | |||
* <strike>Session method should be 'database', not 'php'. If this were deployed on a cluster we'd want to avoid using /tmp for storing session data. See line: 78 | |||
78 define('CAKE_SESSION_SAVE', 'php');</strike> | |||