CUNY Academic Commons

Wait -- I've figured it out. I change the slug to change the email address.

That's one way. The other way is via the group's "Manage > Email Options" page:
https://redmine.gc.cuny.edu/issues/2880#note-18

it's also unclear how the cuny.is address for the group is different from the slug.

This got lost in the shuffle. The plan is to default to using the cuny.is group slug if a custom group email address has not been entered.

Perhaps we shouldn't even allow the group email address to be customized and just let cuny.is group slug support take precedence.

Perhaps we shouldn't even allow the group email address to be customized and just let cuny.is group slug support take precedence.

This is the simplest solution, as long as we're okay saying that there's no situation where it's necessary to have the email address and cuny.is name differ. This seems fine to me, but it should be acknowledged as a consequence.

during the dev call we agreed to move forward with this strategy. thanks to you both

Boone, I'm looking at the cac-yourls plugin code and have a few questions.

Do I use the cac_yourls_get_group_shorturl() function to grab the YOURLS group slug?

I just checked production to see if there are any groups using a custom YOURLS group slug with:
wp db query 'SELECT * FROM wp_bp_groups_groupmeta WHERE meta_key = "cac_yours_shorturl"'

And the query returns zero entries.

In cases where cac_yourls_get_group_shorturl() returns nothing, do I just fallback to the group slug?

I just checked production to see if there are any groups using a custom YOURLS group slug with:
wp db query 'SELECT * FROM wp_bp_groups_groupmeta WHERE meta_key = "cac_yours_shorturl"'

This appears to be a CLI-related (cache?) bug. Do `wp db cli` and then type the query.

The current logic here is not great. The shorturl is requested and saved the first time the group is loaded in the front-end. In practice, this means that most groups have a URL saved. But it would probably be more elegant to have this initial save routine happen inside of cac_yourls_get_group_shorturl(), so that you can reliably fetch it programatically.

If you feel like making this change to the plugin code, go ahead and do it. Otherwise, if you're writing code that'll always be fired by someone actually viewing a group page, it's probably safe-ish to assume that the groupmeta will always be there (since the group has, in fact, been visited, so the shorturl should exist). Barring this, you could reproduce the logic of https://github.com/cuny-academic-commons/cac/blob/e100d3031ff5263e7a56ed3f90744e76b13cba96/wp-content/plugins/cac-yourls/includes/bp-groups.php#L74, which actually fetches and saves the shorturl.

Sorry for the lousy implementation :(

Thanks for the tip about wp db cli.

I did the DB query and found that the group- prefix is used for the majority of cuny.is group slugs.

For the RBE new topic email address, I originally also had a group- prefix, but it was decided that we should do away with it.

If we fallback to the cuny.is slug, this will bring back the prefix to the RBE new topic email address as well. This will break existing group new topic email addresses.

How do we want to proceed? Do we still want to use the cuny.is slug, but strip the group- prefix if it is being used? This might create even more confusion.

I guess it's Matt's call. Seems to me that this is an argument for not merging the two.

I'm leaning towards simplifying things by having the cuny.is link and email address prefix be the same. Is that what would happen? Ie, the URL would be cuny.is/cunydhi and the email address would be cunydhi@groups.commons.gc.cuny.edu ?

cuny.is group links are auto-generated for groups, and they are prefixed by default with 'group-'. See https://redmine.gc.cuny.edu/issues/6241, https://redmine.gc.cuny.edu/issues/3064#note-10 (10 and 11). So here are the options.

1. Keep cuny.is and email addresses independent (status quo)
2. Link the two, and go with the group- prefix.
3. Link the two. For existing groups, go with the existing cuny.is link, which will generally have the 'group-' prefix. For future groups, skip the 'group-' prefix; see linked conversation for the counterarguments.
4. Link the two. For existing and future groups, skip the 'group-' prefix. This will require a script that modifies existing group links.

IMO the complexity here weighs in favor of making the two values separate. Set the email address to whatever the optimum value is, set the cuny.is link to whatever its own optimum value is. 95% of groups will never change this, and those that do will just have to change it in two different places (if necessary). There's little to be gained from forcing them to match.

For historical context, we added the ability for group admins to change the group slug first (#307). Next, we added a group's new topic email address, which uses the group's slug if a custom group email address was not added (#2880).

Lastly, we added cuny.is shorturl support for groups, which has its own group slug system (#6241).

The majority of cuny.is group links are formatted like this - https://cuny.is/group-{SLUG} where {SLUG} is the group slug. A group's new topic email address is currently {SLUG}@groups.commons.gc.cuny.edu.

For DHI, the cuny.is link is http://cuny.is/cunydhi-group, so the group's new topic email address would tentatively be cunydhi-group@groups.commons.gc.cuny.edu. Currently, cunydhi@groups.commons.gc.cuny.edu is DHI's group topic email address.

1. Keep cuny.is and email addresses independent (status quo)

At the moment, option 1 is tied to the group slug.

There is also a fifth option:

5. Allow group admins to change the email address independently from cuny.is and the group slug. This is also possible, however for whatever reason, does not seem to be enabled on the Commons. I can easily enable this, but is this what we want?

See:

Ignore the group- prefix here. That is default behavior, but we removed this prefix on the Commons.

Based on this discussion, this would probably cause even more confusion, so we probably shouldn't consider this.

I am fine with leaving the two values separate, as Boone suggests, but I believe there are actually three elements here:
1. the group slug, which is used in the group URL
2. the cuny.is link
3. the email address for the group

If we are going to keep 2 and 3 separate, would it make sense to combine 1 and 2, so that the cuny.is link and the default group URL matched? "Slug" is not very user-friendly, anyway, so maybe we could just have people set the cuny.is link and it would also set the link at commons.gc.cuny.edu

Does that make sense? My overall goal is to simplify things as much as we can

Allowing group admins to change the URL of the group (commons.gc.cuny.edu/groups/my-group-slug) is dangerous, because it breaks incoming links in a way that's irreparable. Changing the cuny.is shortlink is somewhat less worrisome. Combining the two into a single interface will make it more likely that admins will change the group URL, which is something I'd like to avoid.

I've added Erik here and on #9051 (which is mostly a duplicate of this one) to try to get a handle on how we might best organize this information. If we can propose some relatively simple UX changes soon, we can probably squeeze this in for the 1.13 release.

A few questions/observations after going through the process of creating a group for the first time in the test environment. Take these with a grain of salt:

Is a "slug" essentially the full URL of the group used internally by the Commons? So if I create a group called "myTestGroup" the slug is: "https://commons.gc.cuny.edu/groups/myTestGroup"? Is this the same as the "Group Link" that is editable when you create a group? (Step 3. Slug)

Then there's the short URL, which is the cuny.is link and is editable by the group creator - this re-directs to the full group URL.

I guess I'm wondering if "Step 3. Slug" can be eliminated altogether - IMO it's not at all obvious to the user what a slug is, how it's different from a "Group Link", and why the user would want to edit the slug/Group Link if they can use their short URL anyway.

IMO we should consider removing the ability for admins to change the slug, or at least hide it (by removing the creation and edit step, and maybe burying it somewhere else). It's relevant for very few users, and potentially harmful. See #307 for background.

Thanks Erik for the mockups.

To summarize, what Erik has proposed is to keep the Short URL and new topic e-mail address fields as separate configuration options, while removing the "Slug" tab. I would be in favor of that.

Just wanted to add some further detail regarding:

My understanding from reading the ticket in more detail and speaking to Ray on Tues. is that the default new topic e-mail address originates from the slug, but can be changed by the user.

At the moment, the new topic e-mail address can be changed by the user if the slug is edited.

There is the further ability to set the new topic e-mail address independently from the slug, but that isn't currently exposed on the Commons. We will enable this functionality once we implement what Erik has put together in the mockups.

About the "Manage > Slug" tab being removed, I don't have a problem with removing this. Now that we have the group short URLs feature, the need to change the slug shouldn't be as much of an issue as it was back then.

Matt, do you have any other thoughts?

One other thing we should think about adding is a warning prompt before a group admin decides to change the Short URL or the new topic email address, as this has UX implications for those that have bookmarked the previous links.

Looks great -- please proceed. Thanks!!

Yes, bp-edit-group-slug can be removed.

Let's do this for the next maintenance release.