Also operate without a "username" column.

[nandoflorestan]

Most sites these days will identify users by their email addresses, without a "username" field. For this most important use case, even having a "username" column in the database is an unnecessary burden.

With my alterations, horus can now provide 2 modes of operation:

• email + username: The user chooses a username when registering and later she can log in by providing either the username or the email address. Therefore, usernames may NOT contain the @ character. This mode is the default. It is expressed by the configuration setting horus.handle = usermail
• email only: In this NEW mode, there is no username field and users only provide their email address. The documentation, added to the README, explains:

You enable this mode by:
- Making your User model subclass NoUsernameMixin instead of UsernameMixin;
- Adding this configuration setting: horus.handle = email, which will make horus default to schemas that contain email fields instead of username fields.

If you make this change and want to keep your data you must deal with the existing (or missing) 'username' column yourself.

[nandoflorestan]

Can any of you guys take a look at this PR? 3 weeks have passed. :)

[tilgovi]

Sorry, I think it's probably fine, but I also am not paying much attention to horus now. I am more interested to develop Pylons/horus if I have time.

[tilgovi]

Some comments on style, though:

• I think the NoUsernameMixin is a strange name. Maybe BaseUserMixin and UserMixin? Or just UserMixin and UsernameMixin and people can upgrade their code to add the UsernameMixin.
• Importing the strategies in the views is also odd. Maybe we should have horus.strategies and default it to the username strategy. Then import that model. That way you don't have to rename all the schemas, just put them into a new package with two modules, one for each strategy.

But overall, 👍. Whatever @sontek wants to do is fine with me.

[nandoflorestan]

I am sorry, I was not aware of the existence of pylons/horus as a new project. I like its design decisions very much! Good software is decoupled software and the presence of a service layer is what was missing from old horus, in which models' classmethods take a request parameter ― this is so wrong!

When you say "Importing the strategies in the views is also odd", I don't follow, because the strategies are not imported in the views. They are only used in initial application configuration.

[nandoflorestan]

Hey guys. If this PR isn't approved, I am going to need to fork the project. I am going to upgrade the bootstrap version next.

[tilgovi]

I am likely to move away from horus, since I find some of the deform-specific bits and the overall architecture not particularly extensible. If I put work into horus it will likely go to pylons/horus.

So, I'll duck out. I can't be relied upon to maintain this anymore. If you have interest, I would suggest to @sontek that he give you the power to maintain this yourself, but I can't speak to his plans or needs for stability here.