How do subgroups work? about galene

[jech]

Fixed in 61990ff.

[oddfellow]

I just tested "allow-subgroups": true with version 0.2 and it works as described: The group (e.g. "groupwithallowedsubgroups.json") can be accessed on /group/groupwithallowedsubgroups and a subgroup can be accessed at /group/groupwithallowedsubgroups/randomsubgroup123

EDIT: maybe the mailing list is a better place for this question?

[Niols]

I just tested "allow-subgroups": true with version 0.2 and it works as described: The group (e.g. "groupwithallowedsubgroups.json") can be accessed on /group/groupwithallowedsubgroups and a subgroup can be accessed at /group/groupwithallowedsubgroups/randomsubgroup123

Oh I do understand how this works now. I didn't realise one had to access a subgroup G/H directly for it to be created; I thought the subgroup G/H would be created when acceding G (and that, therefore, only the subgroups of G) would be accessible. Thank you for the explanation. I also tried the other way (creating G/H.json and going to /group/G/H) and it works too.

I suppose this leads to the three following discussions:

1. Does the fact that I did not understand indicate a "bug" in the README? Maybe an other formulation of the paragraph about subgroups could be found. Or do we consider that the current explanation is good enough?

2. Should it be a feature request that subgroups like G/H can have "public": true and show in the list of public channels? (EDIT: I realise now that they do show in the public channels once they have been accessed once, I suppose this could be considered a bug?)

3. Should it be a feature request to add an indicator that a group supports subgroups? Or even give an easy way to create a subgroup (there isn't much to do so I suppose it can just be an input box to enter the name of the subgroup).

4. While I'm here, it seems like subgroups can be of any depth (eg. G/H/I.json). Should this be added to the README?

EDIT: maybe the mailing list is a better place for this question?

I suppose you are right here, if there is both a users mailing list and a bug report platform; I am a bit too used to some projects using the issues of GitHub as a conversation platform. Is there a policy about such things? GitHub allows to show messages to users that add issues. Such a message could contain something like: "Is your issue about a bug or a feature request? If not, consider contacting the users mailing list instead."

[jech]

I realise now that they do show in the public channels once they have been accessed once, I suppose this could be considered a bug?

Yes, it's a bug. The function group.ReadPublicGroups (https://github.com/jech/galene/blob/master/group/group.go#L823) should walk the whole hierarchy, it only walks the toplevel directory.

Should it be a feature request to add an indicator that a group supports subgroups? Or even give an easy way to create a subgroup (there isn't much to do so I suppose it can just be an input box to enter the name of the subgroup).

I'm open to suggestions. but beware — we don't want to overload the user interface.

maybe the mailing list is a better place for this question?

Yes, the issue tracker is for issues that need tracking, the mailing list is for general discussion. However, this particular message does contain a real issue (about public subgroups not being visible on the landing page), so leaving open for now.