Thanks, Colin.

Duplicating the Library seems to be the most important piece

I agree, and it may turn out that what we really want here is a library cloning tool, especially if we have exceptions for nearly every other piece of content.

How do we manage the cloning of a group connected to a site? Can we combine the interface such that you can clone a site and then clone its connected group to get a full Group+Site clone? Or perhaps it's best to clone each thing separately and then connect them later?

On the OpenLab, if you clone a group that has a site, you're given the option: don't create a site, create a site from scratch, or clone the source group's site.

I think a library cloning tool is probably right, Boone. I wonder if we need to frame it as a group cloning tool, though, to fit it well into our current creation flow. Or at least offer the option of cloning admin forum topics (without replies) and all members, to more accurately get to a full group clone. Perhaps both are turned off by default.

That also sounds right about being prompted to clone a group that has a site, as happens on the OpenLab, once you've gone through the group clone flow. We'd just have to make it clear in documentation and maybe on the Create screen that that's possible. And how about the other way around, if you choose to clone a site that has an associated group?

Thanks Boone for this thorough write up – it's very helpful!

Just a few notes to throw into the discussion:

B2. Group name. Generally we like for these names to be unique. But we may want to suggest a name in the interface, or inform the cloning user about the source name during the clone process.

In many cases user interfaces (outside of the Commons) it is common for the cloned name to be the same as the original and the system to ammend a "copy", e.g. "Copy of Sonja's Group" or "Sonja's Group Copy". We could consider something like this to be pre-filled and the user can overwrite it.

C3. 'Campus' metadata

Wouldd it not be likely that a Group might be cloned and used at a different campus?

B2. Group name. Generally we like for these names to be unique. But we may want to suggest a name in the interface, or inform the cloning user about the source name during the clone process.

+1 to informing of the user during creation, but not pre-filling. I think we should do the same with URL/slug.

Wouldd it not be likely that a Group might be cloned and used at a different campus?

IMO this is likely to happen only in a fairly small minority of cases - say, 5% or less.

We'd also like to make the "This group has an associated Site" section a conditional extra screen that you see if that is the case, rather than something at the bottom of the main cloning page.

To put this point another way: If you choose 'Create a Group' from the Create portal, and then you choose to clone a group that is associated with a site, then you will silently be switched into the 'Create a Group + Site' flow starting with step 2 of group creation.

Jeremy, are you comfortable taking this project on for the 1.18.0 release? Given the conversations above and the forthcoming round of mockups from Sonja, will you be able to put together enough of a spec to move forward with building?

Yes to both. For everything that is different here from site cloning, there's quite a bit that ends up being the same.

I'll take a closer look next week at the posted prior art and hammer out a spec that we can build on and divide. I'm approaching this with #13331 in the back of my mind as well, so we can determine if it's worth starting to merge some of the clone handling as part of 1.18.0 or if it continues to remain separate pieces for immediate ease.

Here's my first stab at the "yellow box" note for the cloning screen area talking about what's being copied over: To avoid permissions issues, the only content that will be copied over to the clone from the existing group are Library items (files, docs, and external links) added by any admin-level user of the existing group. The only default member of the cloned Group will be the admin creating the clone (more members can be added later). Other admins of the existing Group will be notified that it has been cloned, and Library items added by other admins on the existing Group will still be attributed to them in the Library of the cloned Group.

This is good but a bit complicated. Perhaps we could format the message as a bulleted list to make it easier to parse?

Sure, thanks for reading through it. Here's a try at revising with bullet points:

To avoid permissions issues:

- The admin creating the cloned Group will be its only initial member. More can be added later.
- Any other admins of the parent Group will be notified that it has been cloned.
- Only Library items (files, docs, and external links) added by admins of the parent Group will be copied over, retaining their original admin attribution.

Okay! I've compiled everything from above into a spec of sorts. I'm sure I've missed a piece or two as I'm still poking around at groups, but this should be a good start. Please call out any thing I'm overlooking. I'll probably swing through and edit again after going through the existing group creation process a bit more.

Front-end interface changes¶

An area will be added to the top of the Create a Group screen that provides a choice between Create a New Group and Clone an Existing Group.

If Create a New Group is selected, the existing group creation form is displayed. If Clone an Existing Group is selected, a new series of screens will be shown depending on whether the group has an associated site.

Cloned group with no associated site¶

• If Clone an Existing Group is selected, a select menu appears with a list of groups on which the user is an admin.
• When a group is selected from the existing group menu, its URL appears next to the menu to help with verification.
• Empty fields for Group Name and Group Description are provided for the user.
• A hint with the cloned groups existing name is shown below the Group Name field.
• The Quick Link field is left blank for the user to populate.
• The Campus and Primary Purpose fields are automatically populated.
• If Teaching is selected as the Primary Purpose, a pre-filled Disciplinary Cluster field and an empty Term/Year field appear.
• A "Group Content" notice is displayed with information for the user that explains what data is being cloned.
• Clicking “Clone Group” creates the group and brings the user to the standard completion screen with (???) steps to clean up the cloned group.

Cloned group has associated site¶

• If the group selected in the Clone an Existing Group menu has an associated site, display options for “Yes, clone…”, “Create a new site”, or “No, don’t create a site”
• When the option is selected to clone the associated site, a Site Details tab appears as the next step to complete after populating Group Details. This Site Details tab follows the flow used when cloning a site.
• When the option is selected to not create a site, only the Group Details tab is shown, as when creating a new group without a site.
• When the option is selected to create a new site, follow the existing Group + Site flow.

Group data cloning¶

When the group is cloned, data associated with the new group may be (1) generated automatically, (2) cloned without confirmation from the user, (3) captured as new from the user, (4) pre-filled for modification by the user, or (5) not cloned or created.

Generated automatically¶

• New topic email
• Creating user ID

Cloned without confirmation from the user¶

• Email subscription settings
• Permissions for group invitations
• Whether forum is enabled
• Status
• Library docs owned by admin
• Library external links owned by admin
• Library files owned by admin

Captured as new from the user¶

• Quick link
• Group Name
• Group Description
• Avatar

Pre-filled for modification by the user¶

• Campus (pre-filled with existing)
• Primary purpose (pre-filled with existing)
• Academic term (shown as empty if a Teaching purpose)

Not cloned or created¶

• Group membership data
• Event data
• Digital Research Tools
• Library papers
• Forum topics
• Library papers

Thanks, Jeremy! This looks accurate and thorough to me.

A comment on the "You're almost done" clean-up section. Making 'Clean up...' a button suggests that it's an action. If we're just taking someone to a documentation page, a link feels more appropriate, perhaps with some clearer language: "Now it's time to get your cloned group ready for use. [[Visit our documentation on cleaning up cloned groups.]]" or something like that, which IMO makes it a little more apparent where I'm at and what happens next. In any case, I think it's worth noodling with the design of this section as the documentation is developed.

Regarding content cloning: It's specified above that certain content should be cloned if it's created by an admin of the source group. I think we may want to clarify, for development purposes as well as for documentation, whether we're cloning content created by admins of any ancestor. Say I have group A with some library items; then I clone it to B and add a second admin (co-teaching, say); then that second admin clones B to C, where I'm not an admin, and then later clones C to D. It feels like my content from A and B should be cloned to C and to D even though, in the case of D specifically, I'm not an admin of the immediate parent. (For context, the OpenLab looks at the admins of each ancestor when deciding whether to clone, for just this reason.)

Thanks Jeremy, this is very helpful and looking very good! A couple things that may or may not help refine this:

- Cloned without confirmation from the user:
Library docs owned by ANY admin
Library external links owned by ANY admin
Library files owned by ANY admin
(this addresses groups with multiple admins, where we retain their uploaded library items with original attribution, even though only one admin can initiate the clone)

- Pre-filled for modification by the user:
Academic term (shown as empty if a Teaching purpose)
((And shouldn't be shown at all if purpose isn't Teaching))

From Boone:

Say I have group A with some library items; then I clone it to B and add a second admin (co-teaching, say); then that second admin clones B to C, where I'm not an admin, and then later clones C to D. It feels like my content from A and B should be cloned to C and to D even though, in the case of D specifically, I'm not an admin of the immediate parent.

And Colin:

this addresses groups with multiple admins, where we retain their uploaded library items with original attribution, even though only one admin can initiate the clone

Working through this out loud a bit here, because it sounds a bit different from how we handled content in site cloning:

• Boone creates a group (A) and adds library items.
• Boone clones the group (A) to another group (B) and adds Colin as an admin.
• Colin clones the group (B) to another group (C) and does not add Boone as an admin.
• Colin clones the group (C) to another group (D) and does not add Boone as an admin.

Should the library items Boone owns in group (A) now exist in group (D)?

My initial gut says that items from group (A) exist in (B) and (C), but are not part of the transfer to (D) as the clone routine is no longer aware of Boone as an admin.

As discussed during Friday's call, we should add links to the documentation of what content gets cloned and how it all works.
The two places where I think it makes sense are:

1. During the Group Cloning flow as part of the section "Group Content" (super contextual)
2. On the Success screen of the Group Cloning flow

Colin, could you draft the verbiage for this, so Boone and team can implement it?
Thanks.

Hi Boone and Jeremy, just an update that testing hasn't surfaced any fixes/suggestions to pass along. Thanks for getting this set up so well! I just posted to the forum, but I'd appreciate your eyes on the release announcement draft if you have time, particularly to make sure I get the language right on cloning:

https://docs.google.com/document/d/1wQn_dAGThjAgzNtWvJm1aW9T-ZIsGqC70LaJgJPH-1s/edit?usp=sharing

We're still finalizing copy, but this is the Clean Up documentation link to put in the "Clean up..." button on the Success page. I think that the other copy on that page looks good.

https://help.commons.gc.cuny.edu/clean-up-after-group-cloning/

One quick addendum -- Scott and I were having trouble getting the emails to other admins of a cloned group to work. Is that because email sending like that is turned off on cdev?

One quick addendum -- Scott and I were having trouble getting the emails to other admins of a cloned group to work. Is that because email sending like that is turned off on cdev?

Yes. Emails will only go out to those users who are members of the Commons team group on cdev. See https://github.com/cuny-academic-commons/cac/blob/323c22233d106157b272d1c62edb06155e77516e/wp-content/mu-plugins/cac-functions.php#L1171 for the logic.