[FEAT] Email-only issues #1402
Labels
No Label
backport/v1.19
backport/v1.20
backport/v1.21
bug
dependency
Chi
dependency
Chroma
dependency
citation.js
dependency
devcontainers
dependency
dropzone
dependency
F3
dependency
ForgeFed
dependency
garage
dependency
Gitea
dependency
go-enry
dependency
Go-org
dependency
go-sql-driver mysql
dependency
Golang
dependency
goldmark
dependency
Goth
dependency
Helm
dependency
MariaDB
dependency
Mermaid
dependency
minio-go
dependency
Monaco
dependency
PDFobject
dependency
ssh
dependency
urfave
dependency
Woodpecker CI
dependency
XORM
Discussion
duplicate
enhancement/feature
forgejo/accessibility
forgejo/actions
forgejo/branding
forgejo/ci
forgejo/documentation
forgejo/federation
forgejo/furnace cleanup
forgejo/internationalization
forgejo/moderation
forgejo/privacy
forgejo/release
forgejo/scaling
forgejo/security
forgejo/ui
issue
closed
issue
do-not-exist-yet
issue
open
OS
FreeBSD
OS
Linux
OS
MacOS
OS
Windows
ready-to-merge
untested
User Research - bug
User Research - communication
User Research - documentation
User Research - feature
User Research - federation
User Research - governance
User Research - release
User Research - security
User Research - testing
User Research - UI
User Research - UX
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: forgejo/forgejo#1402
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
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:
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
This is a migration of an older issue I created on Gitea
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:
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.While a simpler solution, it'd also have several limitations:
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:
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.
The only restriction I see from your suggestion above, relative to a full account, is:
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.
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.
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?)
That's true. I hadn't thought of it like that.
Based on our discussion I'd make my proposal concret as:
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.