leap_web.git - [leap

Age	Commit message (Collapse)	Author
2012-12-20	this is what += is there for	Azul

2012-12-20	validating email domain and displaying it as the placeholder	Azul
	This even works client side. :)
2012-12-18	refactor: using tab partials for user editing	Azul

2012-12-18	adopted functional tests to new controller design	Azul

2012-12-18	only destroy user that has been persisted in teardown	Azul

2012-12-18	make sure we have email_aliases at all before testing for an error on the last	Azul

2012-12-18	refactored email_alias creation and validation	Azul
	using CouchRests user.email_aliases.build so the casted_by method is set in the alias Used this to move the validations into the alias itself. This is where they belong and allows us to render the errors inline along the email field they belong to.
2012-12-18	adjusted tests - we now reload the user so invalid records are cleared	Azul
	Actually that might not be the best idea. Issue at hand was that invalid email aliases were getting displayed when rendering the edit form again. We probably want to solve this different.
2012-12-18	display errors on email tab properly	Azul
	still needs a bit of refactoring in the view
2012-12-17	activate email tab after changing email settings	Azul

2012-12-17	enabled destroying email aliases - no ajax yet.	Azul

2012-12-17	Merge branch 'feature/fixing-signup-and-login-issues'	Azul

2012-12-17	fixed inclusion of stub record helper	Azul

2012-12-17	fixed all user functional tests	Azul

2012-12-13	Merge branch 'master' into develop	Azul
	Conflicts: users/test/unit/user_test.rb
2012-12-13	Merge branch 'feature/email-aliases-model'	Azul

2012-12-13	use the same partial for Email and LocalEmail	Azul

2012-12-13	refactor: changed add_email to add_email_alias	Azul
	that's what it does. Changed all tests to use it instead of the attributes method
2012-12-13	refactor: Email constructor now takes string or hash	Azul
	This allows us to reuse add_email from email_aliases_attributes=
2012-12-13	refactor: allow adding email aliases directly	Azul

2012-12-13	ensure users do not have duplicate email aliases	Azul
	nor aliases that are the same as the original email for that matter
2012-12-13	LocalEmail added - will validate uniqueness amongst emails and aliases	Azul

2012-12-12	find users by email and aliases	Azul

2012-12-12	Merge branch 'master' into develop	Azul

2012-12-11	make sure can login twice	Azul

2012-12-10	email format validations	Azul

2012-12-10	make sure client side validations also run after tabs were switched	Azul

2012-12-10	use consistent naming scheme across CA, webapp and couchDB install	Azul

2012-12-10	created generic Email class and use it with EmailAliases	Azul

2012-12-10	actually allow adding email aliases	Azul

2012-12-09	basic form added to user settings, simple model created	Azul

2012-12-09	first steps towards email aliases	Azul
	* unit tests draft * controller draft
2012-12-08	serve api version 1 in /1/	Azul
	Just a very simple start for now. Do we want to use the api for the secure remote password auth from js?
2012-12-07	Merge branch 'master' into help_develop	jessib
	Conflicts: app/views/layouts/application.html.haml help/app/controllers/tickets_controller.rb help/test/functional/tickets_controller_test.rb users/test/support/stub_record_helper.rb
2012-12-07	fixed test to work with edit view that includes email and email forward.	Azul

2012-12-07	fixed signup and removed flash that was not getting displayed	Azul
	I also tried flash.keep(:notice) but that did not help - not sure how to keep the flash until the root url has rendered.
2012-12-07	adding a bunch of translation	Azul

2012-12-07	first stub at displaying success messages	Azul

2012-12-07	refactor: use seperate form for signup	Azul
	creating and editing users differ so much now it's not worth reusing the complex user_form_with for the signup.
2012-12-07	using normal requests for user updates except password	Azul
	password requires ajax for secure remote password to work
2012-12-07	refactored views to ease adding of email form	Azul

2012-12-06	forgot to add new partial	Azul

2012-12-06	seperated login and password changes in settings	Azul

2012-12-03	refactored tests with new find_record helper	Azul
	find_record User will return a stubbed user record and make sure User.find_by_id(user.id) returns the same so it can be used in controllers.
2012-12-03	enable users to cancel their account	Azul

2012-12-03	enable admin to edit users	Azul

2012-12-03	make tests pass on an empty db	Azul

2012-12-01	using login :is_admin => true instead of real records	Azul
	Travis CI does not seem to have the admin user records. Let's not depend on them and just stub the admin user.
2012-12-01	Merge branch 'develop' into help_develop	Azul

2012-11-28	admins can destroy users	Azul
	I changed the permissions a little to be more consistent. Now: * admins can edit users * users can destroy themselves. There's no ui for either of them but theoretically they could. Not sure this is what we want though.