leap_web.git - [leap

Age	Commit message (Collapse)	Author
2013-01-15	For both users and tickets, if the object is not found and the current user ↵	jessib
	is an admin, they should see an alert that the object wasn't found, and be redirected to the current controller. If the object isn't found and the current user is not an admin, then we will continue to give an error about no access, so as not to leak information about what IDs do and don't exist.
2013-01-14	got users controller test to pass - tickets controller test next.	Azul

2013-01-11	basic dummy data for users	Azul

2013-01-06	views only emit 1 as value now, doc can be included	Azul

2012-12-22	moving the js for view definitions into separate files	Azul
	This way we get syntax highlighting and so on.
2012-12-22	Merge pull request #7 from leapcode/feature/validate-email-domain	azul
	validating email domain and displaying it as the placeholder
2012-12-20	render proper tab on update	Azul

2012-12-20	fixed tests, testing corner cases, fixed these	Azul

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	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	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-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 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	enable users to cancel their account	Azul

2012-12-03	enable admin to edit users	Azul

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.
2012-11-26	removing merge leftovers	Azul