Confusing situation regarding users, employees, admins

[ehuelsmann]

Currently the concepts of "users", "employees", "admins" and "login accounts/authentication entities" are conflated. This results in the following problems:

• Multiple "User" objects:
  • DBObject::User
  • Entity::User
• Multiple "save_roles" methods:
  • DBObject::Admin::save_roles()
  • Entity::User::save_roles()
• Users are keyed off of different sequences
  • DBObject::User uses 'users.id' column
  • Entity::User uses 'entity.id' and/or 'users.entity_id' columns

In addition, the current design hard-wires logins (=users) to employees (=persons). Which means it becomes unnatural to create per-department accounts or even accounts for automated interfacing.

[ehuelsmann]

Additional finding: the results of the 'get_all_users' function from LedgerSMB::DBObject::User doesn't return the 'entity_id' column, so there's no way to traverse the relation diagram from LedgerSMB::DBObject::User to LedgerSMB::Entity::User, whereas the latter allows saving of roles and resetting passwords and the former doesn't...

[ehuelsmann]

LedgerSMB/DBObject/User.pm is a library/backend object, but goes directly to the web authentication layer to retrieve the current password...

(layer violation which prevents me of using it for the purpose of setup.pm growing user management)

[ehuelsmann]

As it turns out, there are multiple ways to code a password reset:

1. LedgerSMB::Entity::User::reset_password()
2. LedgerSMB::DBObject::User::change_my_password()
3. LedgerSMB::DBObject::User::save()

And maybe others, but especially for the last one, I had to read the code of the admin__save_user() function to see that this is its main purpose for existing users (!).

[einhverfr]

A couple thoughts on this.
On Aug 24, 2015 12:20 AM, "Erik Huelsmann" [email protected] wrote:

As it turns out, there are multiple ways to code a password reset:

LedgerSMB::Entity::User::reset_password()
LedgerSMB::DBObject::User::change_my_password()
LedgerSMB::DBObject::User::save()

Right. Wondering if change_my_password should be moved to session object
or of we need a a "me" object for users to change their own password.

And maybe others, but especially for the last one, I had to read the code
of the admin__save_user() function to see that this is its main purpose for
existing users (!).

—
Reply to this email directly or view it on GitHub.

[einhverfr]

For 1.6 what I would like to do is refactor this a bit:

1. Utility functions for managing users and roles should go into an extension we put on pgxn
2. Actual saving of records in our db would be separated from that.

Then we can also clean up our object model code since this is also both setup and installation-related.