Hi,

FYI, I created some months ago a basic room PHP project here: 
https://github.com/remyd1/galene_room

Main goal was a bit different, because it was to let users create their 
own room.

Admins, however, may delete rooms, list rooms, etc, using an API.

Best regards,


Le 28/09/2021 à 20:29, Jeroen van Veen a écrit :
> Hey!
>
> I'm working on and off a management interface for Galene in Pyrite 
> (https://github.com/garage44/pyrite/issues/9)
> and was wondering how to best approach user management. Ideally the 
> user definitions are separate from the group
> files. Any thoughts on a separate users.json that contains entries like:
>
> [
> {"name":"jeroen","password":"foobar","groups":{"pyrite":{"op":true,"presenter":true,"other":true}}},
>     {"name":"pyrite","password":"foobar","groups":{}}
> ]
>
> The idea is to be able to set permissions per group, while having only 
> one user entry at a central place. After modifying users.json,
> there will be another action from the backend that updates all 
> accompanying group files. As I understand it, there is only 1 
> administrator user
> defined in data/passwd? Would it be feasible to have multiple users in 
> there, so each user can have an administrator flag?
>
> And what would be a good approach to delete or rename a group? Doing a 
> request to the new group name works fine to make
> it available in the list, but I wonder what will happen to the group 
> that is being renamed/deleted. Should I use protocol.js in the
> backend as well to connect to a group and kick all users out, before 
> attempting to rename/delete it? If so, would it be useful to have
> a 'hidden' user available that can act on behalf of the backend?
>
> Cheers,
>
> Jeroen
>
>
> _______________________________________________
> Galene mailing list --galene@lists.galene.org
> To unsubscribe send an email togalene-leave@lists.galene.org

-- 
Dernat Rémy
Chef de projet SI, CNRS
Infrastructure des Systèmes d'Information ISI
ISEM Montpellier