[Librefm-bugs] [bug #26492] Changes to the way groups work

[Toby Inkster]

Update of bug #26492 (project librefm):

                  Status:                    None => In Progress            

    _______________________________________________________

Follow-up Comment #2:

Categorising groups certainly seems like a good idea - I hadn't expected the
explosion in groups that we got and naively thought that a single group
listing would be enough.

I'm not sure that the categories below are necessarily the best way of doing
things though. Looking at the currently existing groups, most of them seem to
fall into the following categories:

* Genres of music
* Media players
* Operating systems
* Free culture
* Regional

Regarding 'Ubuntu' versus 'ubuntu', I added a case-insensitive existence
check before creating a group yesterday. See bug
https://savannah.nongnu.org/bugs/?26477. Some existing groups which broke the
new rule may have slipped under the radar though.

For group merging, I've had in my mind for a few days, that if both groups
are owned by the same person, they should be able to merge them together.

Groups do have 'leaders' though they are referred to as 'owners' in the
source code and not indicated in the UI at all. 

Regarding ownership changes, the way I planned on implementing it was on the
edit-page, to include a drop-down list of all current members, and allow
ownership to be assigned to any of them. Once ownership has been assigned to
someone, then the previous owner is no longer tied to the group and may leave.


Regarding profile deletion, I hadn't considered that, as there was no profile
deletion feature at the time I wrote this functionality. A possible solution
would be to include as part of the profile deletion script: for any groups
which the user is a member of and the group has no other members, delete the
group along with the user; for other groups which the user owns, but have
other members, ownership is automatically transferred to the member who joined
earliest.

I considered including a banning mechanism, but decided not to include it to
begin with as it would be easy enough to implement later on.

Lastly, sorting groups by members: I didn't do this to begin with because I
couldn't remember what restrictions (if any) PostgreSQL had on using "GROUP BY
x" and "ORDER BY y" where x and y where not the same. I suppose even if there
are restrictions, the sorting could be done by PHP without too much slowness.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26492>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/