Previously, when diplomats submit translations, the system
would try to figure out whether it should be a 'patch' or a 'change',
and then would either create a patch for an admin or artisan to
review and accept or reject, or would apply the changes immediately
and they would be live. This was done as a compromise between
getting translations live quickly, but also preventing already-translated
text from getting overwritten without oversight.
But having the client handle this added logical complexity. So
this makes all diplomats submit patches, no matter what. The server
is then in charge of deciding if it should auto-accept the patch or not.
Either way, a patch is created.
There was also much refactoring. This commit includes:
* Update jsondiffpatch so changes within array items are handled correctly
* Refactor posting patches to use the new auto-accepting logic, and out of Patch model
* Refactor POST /db/patch/:handle/status so that it doesn't rely on handlers
* Refactor patch stat handling to ensure auto-accepted patches are counted
* Refactor User.incrementStat to use mongodb update commands, to avoid race conditions
* Refactor Patch tests
Address some code review feedback
Correct error code in test
Don't try to send emails to empty addresses
Add tests for subscriptions
Add tests for Next Steps email
Fix specs
Add reason for disabled test
* Refactor several related endpoints and views
* Redesign EnrollmentView, add TeacherContactModal
* Add "Enrollment Status" tab to TeacherClassView
* Delete PurchaseCoursesView and related files
* Style-flatten RemoveStudentModal
* Fix error handling in ActivateLicensesModal
* TeacherCoursesView loads faster by only loading course campaigns, and not load prepaids
This adds the ability to verify email addresses of a user, so we know they have access to the email address on their account.
Until a user has verified their email address, any teacher of a class they're in can reset their password for them via the Teacher Dashboard. When a user's email address is verified, a teacher may trigger a password recovery email to be sent to the student.
Verification links are valid forever, until the user changes the email address they have on file. They are created using a timestamp, with a sha256 of timestamp+salt+userID+email. Currently the hash value is rather long, could be shorter.
Squashed commit messages:
Add server endpoints for verifying email address
Add server endpoints for verifying email address (pt 2)
Add Server+Client endpoint for sending verification email
Add client view for verification links
Add Edit Student Modal for resetting passwords
Add specs for EditStudentModal
Tweak method name in EditStudentModal
Add edit student button to TeacherClassView
Fix up frontend for teacher password resetting
Add middleware for teacher password resetting
Improve button UX in EditStudentModal
Add JoinClassModal
Add welcome emails, use broad name
Use email without domain as fallback instead of full email
Fetch user on edit student modal open
Don't allow password reset if student email is verified
Set role to student on user signup with classCode
Tweak interface for joinClassModal
Add button to request verification email for yourself
Fix verify email template ID
Move text to en.coffee
Minor tweaks
Fix code review comments
Fix some tests, disable a broken one
Fix misc tests
Fix more tests
Refactor recovery email sending to auth
Fix overbroad sass
Add options to refactored recovery email function
Rename getByCode to fetchByCode
Fix error message
Fix up error handling in users middleware
Use .get instead of .toObject
Use findById
Fix more code review comments
Disable still-broken test
* Take `/server/routes/auth` and move most of the logic to `/server/middleware/auth`, refactoring to use generators.
* List all `/auth/*` endpoints in `/server/routes/index.coffee`.
* Fill in testing gaps for `/auth/unsubscribe`.
* Add debug log when `sendwithus` is not operational, so it 'works' in development and testing.
* Use passport properly!
* Track Facebook and G+ logins in user activity as well as passport logins.
- move and rename files
- use associative arrays which store handlers for 'dynamically'
load module from de db route
- store models_path in test/server/common,
a global model variable has the same name that the filename of the model
