System config frontend #87
Conversation
|
Hi Sarah, I don't have any objection to pursuing something like this. I plan the 1.3.0 release for late June, after JGit 3.0 is released. I don't want to rush your proposal since I believe it involves a lot of changes, so I would not favor targeting the 1.3.0 release. We should probably re-architect user services as part of this - which you(?) experimented with a while ago. It's been recommended to me before that authentication should be split from the user service. I think this proposal will be the motivation for finally doing that. I'm thinking user service should have a list of AuthenticatorServices which are used in authenticate(). Right now LDAP and Redmine both create users/teams from within authenticate, so obviously that would still be required. Once we do this, realm.userService will probably become a setting most everyone will never change - unless they are doing something really custom. BTW, What, if anything, are we doing with pull request #74? |
|
Hi James, I just send you a detailed mail about both pull requests this one and #74. Some thoughts I got in mind regarding authentication and users:
Yes, that's right. it was the branch were I made some mistakes e.g. inside the rcp client while trying to refactor. After this attempt I thought it might be better to start from the frontend instead from the backend and then decide if it is better to write a new user+group+auth-management (ugm) in parallel and keep it synced with the code by deactivating the new parts with a feature toggle inside the code by default (so a developer can activate it locally to continuously develop the new feature and the new version of ugm is still in sync with each change in the rest of the code) and then switch to the new ugm when it is finished or to try to refactor the existing userService idea. So, what do you think is the better strategy here?
I do not think it is a good idea at all to continuously import user accounts from other resources because in bigger companies you might miss to delete these accounts in gitblit later, e.g. if an employee leaves the company. But, I think it would be a nice feature, if you can import accounts from another system right after gitblit when you can not connect to a central user management instance permanently. Then an import saves a lot of time to create a mass of accounts manually. So, I would add this feature to this first draft with an "import" button, which opens a modal dialog that lets you select from where to import the user accounts (and if you like to define a username and groupname based filter) into the internal gitblit user management. This way gitblit supports both common scenarios: permanently connect to one ore more central ugm system and dedicated import of user accounts into internal gitblit user management. |
|
Hi Sarah, I am closing this PR for now. I'm not ready to tackle a settings ui. -J |
Hi James,
I have finished the ui frontend for the management and configuration of the user services. It is still just a dummy with no real connection to the backend. But I thought, it would be best to discuss this suggestion with you first before I invest more time to implement the necessary changes in the backend. So please take a look and let me know what you think.
Why a frontend? It would be nice to ease the life of administrators and free them from the necessity to write property files. A frontend inside the web ui introduces a nice and self-explaning overview of the system configuration regarding authentication and permission.
Why multiple user services?
I think it would be nice to be able to configure multiple user services alongside and define an order according to which the user services will be checked to authenticate users and map groups to gitblit system roles. I could even think of one more option per user service: enable usage of remote groups to define repository permissions (would be just one more checkbox per row in the ui draft above).
Regards