Gitea: [FEATURE REQUEST] Add option to disable email change and account deletion

Created on 14 Apr 2019  Â·  8Comments  Â·  Source: go-gitea/gitea

Description

IMHO it could be very helpful to prevent users from changing their email address. This would be the case in closed instances with small organizational teams where user accounts are handled by the administrator (registration disabled). It is pretty common to disallow the use of private/external mail accounts to be in compliance with several legal restrictions, however users may be tempted to do this for convenience.

Without significant benefit (but being consistent with this approach and 'closed instances') a similar option to remove the account deletion part would be neat.

Screenshots

GiteaAccountSettings

kinenhancement kinproposal

Most helpful comment

A similar situation was solved for us by adding custom variants of the template in question (simply add a copy to custom/templates/ as detailed in the docs) where you can either remove the elements entirely, or add something like a disabled tag to the field whilst also removing the Add... button (we've done the latter).

This solution is a local fix, but it's relatively easy to do and has helped us customize our distribution to our needs. Let me know if it sounds like something for you and I can help you out if needed.

All 8 comments

Hi

I have created a kind of demo user.
A user who can only use pull requests and issues for certain repos. The idea is that a user who wants to add something or has some problems but doesn't want to register.

So that means, that the demo user shouldn't be allowed to:

  • delete account
  • change email (maybe avoid this with a email request)
  • fork other repos
  • change password
  • enable 2fa
  • ssh/gpg keys

Nothing, really. Just to create a pull request and an issue.

Is it possible to implement this as well?

A similar situation was solved for us by adding custom variants of the template in question (simply add a copy to custom/templates/ as detailed in the docs) where you can either remove the elements entirely, or add something like a disabled tag to the field whilst also removing the Add... button (we've done the latter).

This solution is a local fix, but it's relatively easy to do and has helped us customize our distribution to our needs. Let me know if it sounds like something for you and I can help you out if needed.

@oscarlofwenhamn Is it possible also to do this template adjustements only fpr non-admin users?

I think .SignedUser.IsAdmin is available on all templates so you could add tests for that.

Agreed, you should be able to do something like:

<input id="email" name="email" value="{{.SignedUser.Email}}" {{if not .SignedUser.IsAdmin}}disabled{{end}}>

...
{{if .SignedUser.IsAdmin}}
    <div class="field">
    <button class="ui green button">{{$.i18n.Tr "settings.update_profile"}}</button>
    </div>
{{end}}

to keep it short and concise.
Bear in mind I haven't actively worked with the templates for a few months, so I might be off in the application, but something like this should work depending on your use-case.

Very nice!

I just realized this could potentially be a fairly easy PR to create (I will not have the time to fix it in the immediate future so anyone else is free to grab it if they want):
A setting in the app.ini file with either something like a boolean DISABLE_EMAIL_EDIT = (false), or a value-based setting ALLOW_EMAIL_EDIT = (all) [all, admin, none], which in turn could be mapped to a setting similar to how .SignedUser.IsAdmin is used above. E.g.

<input id="email" name="email" value="{{.SignedUser.Email}}" {{if .DisableEmailEdit}}disabled{{end}}>

...
{{if not .DisableEmailEdit}}
    <div class="field">
    <button class="ui green button">{{$.i18n.Tr "settings.update_profile"}}</button>
    </div>
{{end}}

alt.

<input id="email" name="email" value="{{.SignedUser.Email}}" 
  {{if not or (eq .AllowEmailEdit "all") (if and (eq .AllowEmailEdit "admin") (.SignedUser.IsAdmin))}}disabled{{end}}>

...
{{if or (eq .AllowEmailEdit "all") (if and (eq .AllowEmailEdit "admin") (.SignedUser.IsAdmin))}}
    <div class="field">
    <button class="ui green button">{{$.i18n.Tr "settings.update_profile"}}</button>
    </div>
{{end}}

Again, I'm a few months off working with this so the exact application of the Go template syntax might be off, but I believe the general idea could be applied.

This would fix part of the proposed feature request, and could easily be modified and reapplied to account for the deletion setting as well (though as a separate setting, I would suggest).

We actually modified the templates for our purpose as well, and use always the .IsAdmin flag for disabling email edit, account deletion, group leave functionality etc. works pretty well. I might have a look at it, in 2-3 weeks, seems fairly simple. I would suggest leaving the „none“ value as it makes no sense. Maybe expose the Allow setting and map this to SignedUser.DisableEmailEdit = true/false,

Also the email management panel might get a setting too: .DisableEmailManagement or so

Von meinem iPhone gesendet

Am 01.07.2020 um 10:06 schrieb oscar.lofwenhamn notifications@github.com:

I just realized this could potentially be a fairly easy PR to create (I will not have the time to fix it in the immediate future so anyone else is free to grab it if they want):
A setting in the app.ini file with either something like a boolean DISABLE_EMAIL_EDIT = (false), or a value-based setting ALLOW_EMAIL_EDIT = (all) [all, admin, none], which in turn could be mapped to a setting similar to how .SignedUser.IsAdmin is used above. E.g.

...
{{if not .DisableEmailEdit}}




{{end}}
alt.

...
{{if or (eq .AllowEmailEdit "all") (if and (eq .AllowEmailEdit "admin") (.SignedUser.IsAdmin))}}




{{end}}
Again, I'm a few months off working with this so the exact application of the Go template syntax might be off, but I believe the general idea could be applied.

This would fix part of the proposed feature request, and could easily be modified and reapplied to account for the deletion setting as well (though as a separate setting, I would suggest).

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lunny picture lunny  Â·  3Comments

cookiengineer picture cookiengineer  Â·  3Comments

kifirkin picture kifirkin  Â·  3Comments

jonasfranz picture jonasfranz  Â·  3Comments

adpande picture adpande  Â·  3Comments