Remove the auth and user management flows

[sebastian-code]

Is your feature request related to a problem? Please describe.
No, it's an improvement in the usability of the application, to ease the implementation on a project.

Describe the solution you'd like
Remove the developed auth workflow actually in use, and make it dependent on the native Django auth workflow.

Describe alternatives you've considered
An alternative would be to implement a workaround the app own auth workflow, allowing for an easy implementation of other solutions. Also, there are a lot of packages currently in active development, widely in use, highly specialized into solving the same issue, sitting on top of the native Django auth library:

• Django Packages search on the auth term
• Django Packages auth category grid
• Django Allauth is one of the most widely implemented packages, with even MFA protocol.

Additional context
Django Ledger is a real treasure, and a highly complex piece of software by itself, and trying to work around the auth workflow in place, makes it really difficult to adopt in an existing project, or for a new project with special needs for handling users. Removing it, or implementing an easier workaround (perhaps environment variables) would remove some of the initial barriers.

[elarroba]

@sebastian-code Could you please elaborate more? Maybe provide some examples of what you mean?

Most default Querysets do take a user model to make sure the user requesting company data is an admin or a manager of the entity. This is intentional and by design since django ledger is a multi-tenant app.

The way users are authenticated is up to the developer. You can use all auth, oauth2 or any other authentication method that identifies the request.user.

[sebastian-code]

The best reference I can point would be both files auth.py in the folders urls and views, respectively. Those are exposed as valid functions of the package, for what I assume would be presentation for an example project. The issue is that those affect the urls structure, and add unnecessary functionality; if you go the url package-path/auth/login, you'll end up in a valid login page, even when your project would have its own auth workflow.

The best approach would be to have a demonstration project, that installs the package locally, and in there you could implement the auth workflow. And for compatibility purposes, you could declare that the package is dependent on Django's auth scheme.