[FEAT] Email-only issues #1402

Open
opened 2023-09-10 10:16:24 +00:00 by CSDUMMI · 9 comments

Dependency references

Needs and benefits

Many FOSS projects only provide a bug tracker in the form of the issue tracker on their source forges. This automatically excludes anyone from making a bug report, who does not have an account with that specific forge - such as non-technical people or developers who have not yet created an account with a given forge.

Allowing people to create an issue on a repository, where they only have to provide a valid email address instead of setting up an entire account, would allow non-technical people to quickly create bug reports or feature requests for FOSS projects. Bug fixes and feature requests that may otherwise not be created.

Feature Description

I propose that a repository should have a setting, allowing "Email-only issues".
With this setting turned on, a person would be given a choice before creating an issue, they could either:

  1. Login or register on the Forgejo instance
  2. Create an issue using Email.

If they select the second option, the normal issue writing process would be triggered - but before submitting the issue, the submitter would have to provide a valid email address and verify the email address before the issue is published.

After verifying their email address, the issue author would then be sent a "magic login link" to their inbox - which they can use to edit their issue and respond to comments.

Screenshots

No response

### Dependency references * https://github.com/go-gitea/gitea/issues/19434 ### Needs and benefits Many FOSS projects only provide a bug tracker in the form of the issue tracker on their source forges. This automatically excludes anyone from making a bug report, who does not have an account with that specific forge - such as non-technical people or developers who have not yet created an account with a given forge. Allowing people to create an issue on a repository, where they only have to provide a valid email address instead of setting up an entire account, would allow non-technical people to quickly create bug reports or feature requests for FOSS projects. Bug fixes and feature requests that may otherwise not be created. ### Feature Description I propose that a repository should have a setting, allowing "Email-only issues". With this setting turned on, a person would be given a choice before creating an issue, they could either: 1. Login or register on the Forgejo instance 2. Create an issue using Email. If they select the second option, the normal issue writing process would be triggered - but before submitting the issue, the submitter would have to provide a valid email address and verify the email address before the issue is published. After verifying their email address, the issue author would then be sent a "magic login link" to their inbox - which they can use to edit their issue and respond to comments. ### Screenshots _No response_
CSDUMMI added the
enhancement/feature
label 2023-09-10 10:16:25 +00:00

This is a migration of an older issue I created on Gitea

This is a migration of an older issue I created on [Gitea](https://github.com/go-gitea/gitea/issues/19434)
earl-warren added the
issue
open
dependency
Gitea
labels 2023-09-10 13:29:56 +00:00

A perhaps simpler solution might be simply to allow creation of issues by sending an email. (This has been discussed somewhat in the chat rooms over the last few days.)

Either way, I assume a "virtual"/"federated" user would be created in the DB to "own" the created issue.
This would:

  • allow association of the email address with the issue to allow replies to be sent to the email address,
  • allow the user to later "claim" that account by following the normal account creation process with the same email address.

I'll therefore add the federation label, but if anyone who's working on this or on federation disagrees, feel free to go ahead and remove it.

A perhaps simpler solution might be simply to allow creation of issues by sending an email. (This has been discussed somewhat in the chat rooms over the last few days.) Either way, I assume a "virtual"/"federated" user would be created in the DB to "own" the created issue. This would: - allow association of the email address with the issue to allow replies to be sent to the email address, - allow the user to later "claim" that account by following the normal account creation process with the same email address. I'll therefore add the `federation` label, but if anyone who's working on this or on federation disagrees, feel free to go ahead and remove it.
caesar added the
forgejo/federation
label 2023-09-10 15:23:17 +00:00

While a simpler solution, it'd also have several limitations:

  • The issue author couldn't edit their issue
  • The issue author couldn't use the templates defined by the project (even more important, if this feature is used by people unfamiliar with the project or software development in general)
  • The issue author couldn't use reactions
  • The issue author couldn't close an issue

While some of these limitations could be addressed (through magic links in the emails), letting the issue author use the same web interface as everybody else would both reduce work to those implementing it and improve accessibility by not having to maintain two different interfaces.

I thus think that a light account is the better option here. A light account, to me, means:

  1. The account is linked to a specific email
  2. The account is accessed through magic links sent to the email
  3. The account can create issues, comment on issues and PRs and edit their issues.
  4. The account has no repositories and cannot be an owner or member of any team in any organization.
  5. The account can be turned into a full account by setting a password.
While a simpler solution, it'd also have several limitations: - The issue author couldn't edit their issue - The issue author couldn't use the templates defined by the project (even more important, if this feature is used by people unfamiliar with the project or software development in general) - The issue author couldn't use reactions - The issue author couldn't close an issue While some of these limitations could be addressed (through magic links in the emails), letting the issue author use the same web interface as everybody else would both reduce work to those implementing it and improve accessibility by not having to maintain two different interfaces. I thus think that a light account is the better option here. A light account, to me, means: 1. The account is linked to a specific email 2. The account is accessed through magic links sent to the email 3. The account can create issues, comment on issues and PRs and edit their issues. 4. The account has no repositories and cannot be an owner or member of any team in any organization. 5. The account can be turned into a full account by setting a password.

Your points make sense, but the scope of the issue is then a bit different from what I had initially understood.

As I now understand, your suggestion is to allow the use of magic links instead of passwords as a login method. Is that correct?

Your points make sense, but the scope of the issue is then a bit different from what I had initially understood. As I now understand, your suggestion is to allow the use of magic links instead of passwords as a login method. Is that correct?

I'm suggesting that, but such an account should only have very limited abilities (as I outlined about) and existing account should be able to use magic links as a replacement for passwords.

I'm suggesting that, but such an account should only have very limited abilities (as I outlined about) and existing account should be able to use magic links as a replacement for passwords.

such an account should only have very limited abilities

The only restriction I see from your suggestion above, relative to a full account, is:

The account has no repositories and cannot be an owner or member of any team in any organization.

If the only other difference from a normal account is that there is no password set and magic links are used instead for logging in, what would be the purpose of that restriction over it simply having the same abilities as a normal account?

> such an account should only have very limited abilities The only restriction I see from your suggestion above, relative to a full account, is: > The account has no repositories and cannot be an owner or member of any team in any organization. If the only other difference from a normal account is that there is no password set and magic links are used instead for logging in, what would be the purpose of that restriction over it simply having the same abilities as a normal account?

I think that magic links are less secure than a password and should thus not be used for critical operations.

My motivation with this suggestion is to allow non- or less-technical people to use the issue tracker on repositories that allow this in a fast way.

And since a big hurdle there is having to create an account with a username and password, I think it is better to allow for these use-cases accounts authenticating using less-secure and more convenient magic links.

I think that magic links are less secure than a password and should thus not be used for critical operations. My motivation with this suggestion is to allow non- or less-technical people to use the issue tracker on repositories that allow this in a fast way. And since a big hurdle there is having to create an account with a username and password, I think it is better to allow for these use-cases accounts authenticating using less-secure and more convenient magic links.

I think that magic links are less secure than a password and should thus not be used for critical operations.

Since a password can be reset with a magic link, the security is no less. If anything, it is greater, because there is not the risk that the user chooses a poor password. In either case, anyone with access to their email account can gain access to their Forgejo account (and probably all of their other accounts) if they don't use 2fa.

a big hurdle there is having to create an account with a username and password

If they still have to log in I don't see much difference tbh – but I'm not opposed to adding magic links as a login method. I think it's a good idea.

I guess the only other difference with your proposal is that the user wouldn't have to choose a username. But that begs the question: what username would be shown in the UI? If there was no actual username, some kind of substitute would be needed (maybe a hash of the email, or a random combination of words?)

> I think that magic links are less secure than a password and should thus not be used for critical operations. Since a password can be reset with a magic link, the security is no less. If anything, it is greater, because there is not the risk that the user chooses a poor password. In either case, anyone with access to their email account can gain access to their Forgejo account (and probably all of their other accounts) if they don't use 2fa. > a big hurdle there is having to create an account with a username and password If they still have to log in I don't see much difference tbh – but I'm not opposed to adding magic links as a login method. I think it's a good idea. I guess the only other difference with your proposal is that the user wouldn't have to choose a username. But that begs the question: what username would be shown in the UI? If there was no actual username, some kind of substitute would be needed (maybe a hash of the email, or a [random combination of words](https://jimpix.co.uk/words/username-generator.asp)?)

Since a password can be reset with a magic link, the security is no less

That's true. I hadn't thought of it like that.

Based on our discussion I'd make my proposal concret as:

  1. Allow the use of magic links instead of passwords
  2. Suggest the creation of a magic-link account when an anonymous session wants to create a new issue

W.r.t. the username that these accounts should use, I think it's a far easier requirement to set a username than a password and thus the magic-link accounts should choose their own username like any other.

> Since a password can be reset with a magic link, the security is no less That's true. I hadn't thought of it like that. Based on our discussion I'd make my proposal concret as: 1. Allow the use of magic links instead of passwords 2. Suggest the creation of a magic-link account when an anonymous session wants to create a new issue W.r.t. the username that these accounts should use, I think it's a far easier requirement to set a username than a password and thus the magic-link accounts should choose their own username like any other.
dachary added the
User Research - feature
label 2023-10-27 18:52:34 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: forgejo/forgejo#1402
There is no content yet.