Manually approve new registration #13083
Conversation
Codecov Report
@@ Coverage Diff @@
## master #13083 +/- ##
=======================================
Coverage 42.32% 42.32%
=======================================
Files 726 726
Lines 77679 77683 +4
=======================================
+ Hits 32876 32878 +2
- Misses 39405 39408 +3
+ Partials 5398 5397 -1
Continue to review full report at Codecov.
|
|
But if you confirm by email user will still be activated so it will not be functional with both enabled |
|
That's true. It would be possible to choose (exclusively) between confirming automatically, by email, or manually. (Is that problem?) I think that enabling more than one way of confirmation would need database change but maybe I am wrong? |
|
Yeah it would but than you should add a note for this in docs and example ini that this feature is supported only when |
|
I think we have to rethink this more. Email confirmation will let you know the emails are addressable but manually confimation will not. I think we have more codes need to be changed on those aspect. |
That's true, @lunny. However, this PR is for a particular use-case: We are a small team at university and we need to let students and cooperating partners join our development. We have some open source project, some of them are closed. We don't even need to track email addresses. The point is that if we want to control access to the gitea instance, we can currently use external authentication (we don't have,) or manually create users. This simple PR will improve our workflow by just approving new users. Backward compatibility is preserved. |
|
@qeef I know. I don't against the PR. I mean, if we can mark these email addresses as non-confirmed so that the future PRs could send a confirmation email to know if the notification emails could be received. |
|
@lunny Marking emails as non-confirmed is one option, IMO. It would require a new column in the database. The second option that comes into my mind is adding two new columns Did you have a particular idea? |
|
I was yet thinking about future PRs as mentioned above. I tend to say that email confirmation is a little bit of different functionality. Currently, Therefore, I propose to discuss emal confirmation in different issue/PR. |
|
Hi @qeef, is_active and is_confirmed would be essentially the same. is_active exists to prevent users from pretending to be someone else and prevent that person from logging in. I'm don't quite understand how this is supposed to work. How are the users registering? what are they doing? |
|
can't they just use the dummy mailer? |
|
Hi @zeripath.
it means that
This PR use The use-case is the manual control of the access to the Gitea instance (without necessity of external authentication configuration.) Currently, the manual access control can be done by creating users by admins. This PR let users create their accounts themselves, and let administrators just approve it (therefore speeds up the process.) |
|
Guys, is there anything more I can do? |
|
I fixed the last review and rebased to the current |
The new settings option is used when manually approving new registrations.
When manual registration confirmation is desired (by default `false`) create new user in the database that is *not active*. The user must then be activated manually. This change speeds up the process of adding new confirmed users for Gitea instances without external auth mechanism. (Currently the option is to manually create new user by admin.)
Co-authored-by: a1012112796 <1012112796@qq.com>
Add manual confirmation of the newly registered users.
This change speeds up the process of adding new confirmed users for Gitea instances without an external auth mechanism. (Currently, the option is to manually create a new user by admin.)
As this is a small change, I haven't created an issue. However, I am ready to do that if it is desired.
I am sure that the PR is not perfect and looking forward to the comments. Thanks!