[debaserab2]

Overriding is simple when it's changing a view. I've found the exact opposite to be true if it's anything regarding the actual workflow. If you're trying to change the workflow, you're probably already in an edge case and you're usually dealing with documentation that isn't terribly comprehensive or updated and rarely relates to the change you are trying to make. You're usually stuck reading the library internals carefully and scouring Stack Overflow for other people who have attempted to make the same change (often only to find unanswered question).

Every time I've ended up in this scenario I've wished that I had just built from scratch in the first place.

[joshmn]

What sort of workflow are you trying to achieve? Devise is effectively `User.create(email: params[:user][:email], password: params[:user][:password])`

[debaserab2]

Here's a good example of something I worked on recently that I highly doubt is simple to implement with an out of the box solution. I could be wrong - I have no idea if Devise can do it or how hard it would be (it wasn't considered because the auth handling was already implemented):

You have a multi-tenant SaaS application that needs to support the following:

* Accounts may have different password, lockout, and expiration policies.

* There's a generic "login" button on the marketing site that 50%+ of our users use. This generic login page must implement all account specific constraints (probably via a 2-step login form)

* Some customers have SSO. For some customers, using SSO is optional. For others, it is required.

* Owners of accounts have a limited impersonation feature that allows them to see only certain parts of information in eyes of one of their account members

[drspacemonkey]

* Accounts may have different password, lockout, and expiration policies.

I've had to do that with Devise. It was easy enough to fork the `devise-security` plugin and modify the configuration settings to handle lambdas. The lambdas were then set to pull the config values from the user's account configuration.

* There's a generic "login" button on the marketing site that 50%+ of our users use. This generic login page must implement all account specific constraints (probably via a 2-step login form)

That's super easy.

* Some customers have SSO. For some customers, using SSO is optional. For others, it is required.

I'm in the process of adding exactly this to my project's Devise configuration right now. It's a little tricky, but only because our previous attempt at SSO was very strangely done (and I now understand why so many users complained about not being able to log in).

* Owners of accounts have a limited impersonation feature that allows them to see only certain parts of information in eyes of one of their account members

User permissions are outside the scope of Devise, since it just handles authentication. But the Pretender plugin makes user impersonation dead simple.