Invite users by link or access code

[DunklerPhoenix]

Heho
It would be great for an non-public multi-user instance if its possible to invite new users by a link (one time usage and multiple usage) or a predefines access code that needs to be entered while registering.

I use little link for our sports club and don't want a public registration, but still want that users from our gym can register themselfs.
e.g. I could invite them directly via link or hang a qr code at our gym.

At the moment I block the /register page with a password over traefik.

[JulianPrieber]

It would be great for an non-public multi-user instance if its possible to invite new users by a link (one time usage and multiple usage) or a predefines access code that needs to be entered while registering.

Great idea! I have no idea how to do that xD

I generally add new users manually on the manage users page to do exactly that.

[DunklerPhoenix]

The part with the updater is really a problem. With database entries it would be kinda "easy"

This request is quiet low priority. I don't really need it at the moment because of my workaround with traefik, but maybe it's a good reason to update the updater for better db handling :D

[JulianPrieber]

I really need to find a package that can do the updating for me because I'm definitely not touching that myself.

Our framework has some database management stuff built in, but even that fails for some people.

My best bet so far has been to write just vanilla SQL requests using PHP.

[DunklerPhoenix]

I thought a bit over the problem with the non-updateable database.
What if you "misuse" the Passwort Reset Table for it?
Theoretically you can push the needed informations like the following in this table i think:

email: account-email++accesstoken

• e.g. my@email.com++VyLw2wuJGzK3Aab2rhGqqc2K4oQCWopeMGk2YuyUbxK7byyTpiQG

token: P(ermanent)/E(xpire)/U(sage)++Value

• e.g. for permanent: P++
• e.g. for expire: E++timestamp_expire_date
• e.g. for usage: U++max_allowed_usage++already_used_count

created_at: when the link is created

It's really dirty and hacky, but I think I would do something like that if I can't edit the Database ^^'
(or I would use a second database or a textfile-based variant)
Why the accesstoken is not in token, but in email? Because the email field seems to have an index property.
And because of the special signs it should be possible to differ between real e-mail verify requests and invite requests.

[DunklerPhoenix]

1. Link with an permanent access code e.g. /register?code=dhsjds (hardcoded, only one link for whole instance)

A version like this could be easily added via config file i think. For all without code the register page just shows the disabled message, for Users with code the normal registration form.

[JulianPrieber]

I can store pretty much anything in the config file. But this isn't really something that would work super easily (for this).

I can store a lot of stuff for individual users, I reused an unused entry to stuff a JSON array into a single db entry. I store simple settings there for each user. This wouldn't really work for this since I can't just save it to the admin user since I can't assume that this user even exists.

Something I might actually do is add a second database. This would be an SQLite db only for storing temporary things.
This db would reset after each update, so I can't store important data here. I'm looking for a simple db system where I could store update notifications or something like that in, to move all requests that the app currently makes to a cron job. With this, we could implement stuff like automatic updates or sending emails.
But I'm not really sure if it is good to have this db reset on every update, but then again better to have it than not.

[skeith]

Any progress on this request?

[JulianPrieber]

We have no estimated date yet, but this is something that will definitely be added.