Feature #13198
closedGroup cloning
0%
Description
I'm starting this ticket to consolidate our initial planning on building group cloning for our next release to pair with the site cloning that we just put out. A few points:
- Duplicating the Library seems to be the most important piece, thinking about the use cases of departments or professors with a lot of assets stored there that they want to make available to a cloned group (different team, semester, etc). But we have similar concerns as site cloning with attribution and permission. Some professors have students upload assignments to a group, for example. Those shouldn't be duplicated. Perhaps it's a similar thing where only Library items uploaded by an admin get duplicated, and the same notification of admins about duplication that we did for cloned sites?
- Could this also be the same for any Forum topics created by an admin, in case admins want to carry over Forum topics like trainings or writing prompts? Maybe this could be optional.
- 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?
- For members, in most cases I think a cloned group admin will want to start over with invites. Like a new semester of students, etc. But in some cases, like a department or project team, maybe not. Is it best to just make people re-invite in the latter case, and not replicate group members at all when cloning?
- Events and Digital Research Tools don't need to be cloned (and should either be deprecated, especially with the dominance of outside calendar services?)
Files
Updated by Boone Gorges over 4 years ago
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.
Updated by Colin McDonald about 4 years ago
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?
Updated by Boone Gorges about 4 years ago
- File Screenshot_2020-09-08_13-59-30.png Screenshot_2020-09-08_13-59-30.png added
- File Screenshot_2020-09-08_13-59-48.png Screenshot_2020-09-08_13-59-48.png added
- File Screenshot_2020-09-08_14-00-08.png Screenshot_2020-09-08_14-00-08.png added
With apologies for length, I've done some analysis for the group. First, a very brief outline of the salient parts of the OpenLab's cloning process, which show some of the UX and other decisions. Second, an outline of content/settings in Commons group, with initial suggestions about how/whether to handle it during cloning.
City Tech OpenLab¶
On the OpenLab, you can trigger the group clone process from within the group Settings/Manage section. See screenshot.
If you are the administrator of at least one other group on the site, you see a 'Clone' radio button at the very beginning of the group creation flow. This is similar to what we implemented during site creation. See screenshot.
During the group creation process, if you've chosen to clone, a number of settings are pre-filled using the settings from the source group. I can share these if necessary, though my notes below will reflect many of the details. Other settings are cloned automatically.
Outline of group content on the Commons¶
Broadly, it's helpful for me to think about group settings and group content separately. Below, I've outlined a couple different categories of settings, and then sketched the different kinds of content. In most cases, I've made recommendations about how they should be handled. But these are all subject to discussion based on use case. A full spec for the feature will clarify for each of these things whether (a) they should be cloned invisibly, (b) they should not be cloned, (c) they should be pre-filled during group creation, (d) they need a special UI during cloning to specify, or whatever.
A. Group settings that must be unique, so cannot be copied:
1. Slug/URL
2. Quick link. This is automatically generated based on slug.
3. New topic email address. This is automatically generated based on slug.
B. Group settings that don't need to be unique from a technical point of view, but probably shouldn't be copied for other reasons:
1. ID of the creating user. For now, this will likely always be the same as the source creator_id anyway. But in the future, we may have cases where you can clone others' groups, and this is a piece of data we would not want copied.
2. 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.
3. Social media accounts. These are used to power the links/logos in the group header. They're likely to be unique to individual groups.
4. External blogs. Blogs listed here have their new posts imported into the group's activity stream via RSS. But this is likely to be unique per group, even in the case of cloning.
5. Group description. This is one that we may want to prompt for during the group clone process, and suggest/pre-fill the source group's description, which would then be editable during the clone process.
6. Academic Term. As in the case of 'group description', we should perhaps prompt for this during group cloning.
7. Avatar. Source group's avatar should be the default value but we can prompt for it during group creation.
C. Group settings that probably should be cloned without prompting:
1. Default email subscription setting
2. Permissions for group invitations
3. 'Campus' metadata
4. 'Primary Purpose' metadata
5. 'Disciplinary Cluster' metadata (if Teaching)
6. Status (public, private, hidden)
7. Whether forum is enabled for the group
D. Group content:
1. Membership. I'm thinking we probably don't want to clone anything here.
2. Forum content. It may be helpful to distinguish between (a) topics and replies, and (b) content created by a group admin, and other content. On the OpenLab, group cloning includes only admin-created topics. The OpenLab solution is likely to be appropriate in a teaching context, but might make less sense in other contexts.
3. Events. Probably don't want to clone this.
4. Library. There are five different types of library content. (a) Docs, (b) External Links, and (c) Files should probably all be cloned. (d) Forum Attachments should be cloned only if the corresponding forum topic/reply is copied; see above. (e) Papers should probably not be copied at all, since they're deprecated.
5. Digital Research Tools. I think this feature is not fully working (see https://redmine.gc.cuny.edu/issues/12155). But once it is, I think it's probably not appropriate to copy any of it during clone. This is because group tools are dependent on tools that are marked as "used" by members; but if membership is not cloned, then clones will have no "used" tools (aside from those used by group creators). I do think that we can probably clone the Enabled/Disable toggle for the DiRT navigation item.
6. Site. We can't clone without prompting, because some site details, like slug/URL, must be provided manually. I think we need something like the following: (a) If the source group has a site, have a yes/no toggle on whether the clone should also clone the group site. (b) If yes, prompt for the URL and any other unique settings for the group. (c) Then, clone all content using the same logic as standalone site cloning.
Updated by Sonja Leix about 4 years ago
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?
Updated by Boone Gorges about 4 years ago
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.
Updated by Sonja Leix about 4 years ago
- File Clone-group-flow-v1.pdf Clone-group-flow-v1.pdf added
Hi team,
I've created a first iteration of the Group cloning flow.
I didn't read a clear direction on whether to pre-fill the group name field and the meta fields (campus, purpose), so I left those blank for now.
6. Site. We can't clone without prompting, because some site details, like slug/URL, must be provided manually. I think we need something like the following: (a) If the source group has a site, have a yes/no toggle on whether the clone should also clone the group site. (b) If yes, prompt for the URL and any other unique settings for the group. (c) Then, clone all content using the same logic as standalone site cloning.
I've followed what Open Lab does somewhat for this (see second to last page in PDF).
Looking forward to your feedback! If you'd like me to adjust anything before Friday, please share feedback by EOD Wednesday.
Updated by Colin McDonald about 4 years ago
Just to close up the above point first, I think we can inform the user of the parent group's URL and name as we do for parent sites, and autopopulate the same with Campus and Primary Purpose (then leave Term/Year blank if Teaching, but retain Disciplinary Cluster). See screenshot attached.
As for other feedback from the Friday meeting, we decided not to copy over any forum topics at all, even if started by an admin -- that way we're also not bringing over any forum attachments. We need to well-document all of this and keep track of special cases where this is a problem. Then we could add more complexity later if issues keep happening. We'll also only take docs authored by an admin, but not others.
Documentation will also be important to make sure that cloning admins know to make sure that things in their library, especially external links to Dropbox/Google/etc, are not being copied over and making private content from the prior group accessible to new group members. Some post-cloning cleanup is often going to be necessary. A prompt on the final screen that says "Please click here for steps to make sure your cloned group is ready to use." that links to a checklist of cleanup to-dos would be good.
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.
Updated by Boone Gorges about 4 years ago
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.
Updated by Boone Gorges about 4 years ago
- Category name set to Group cloning
- Assignee changed from Boone Gorges to Jeremy Felt
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?
As in the case of site cloning, there's some existing tools we can leverage:
- In CBOX OpenLab, we clone using the following: https://github.com/cuny-academic-commons/openlab-theme/blob/f210fe42fa068450b5cc9013b90bde42f9039c53/lib/course-clone.php#L310 The individual methods for coping groupmeta, docs, and files should be largely reusable/adaptable for CAC.
- The City Tech OpenLab (the progenitor of CBOX OpenLab) has more legacy code in it, but it does have one major improvement: the asynchronous handling of the cloning process. Each step (groupmeta, files, etc) is run in the background, making the front-end experience much less painful. It might be worth pulling some inspiration from it. See: https://github.com/livinglab/openlab/blob/184be4f426237deada01b03ef6136e48116b31f4/wp-content/themes/openlab/lib/course-clone.php#L98, https://github.com/livinglab/openlab/blob/184be4f426237deada01b03ef6136e48116b31f4/wp-content/themes/openlab/lib/clone-wp-async-process.php
Obviously there will be some differences for the Commons, but maybe this will be a useful starting point. One major difference is our Library feature. The CAC library is mostly a skin that sits on top of Files (bp-group-documents) and Docs (buddypress-docs). For those item types, copying over the Files and Docs should automatically trigger the cac-group-library tool to create its own metadata; see eg https://github.com/cuny-academic-commons/cac-group-library/blob/87a1a60a36a54504cf187b6b9286f5a8f57b1cc9/src/Sync/BuddyPressDocsSync.php#L12. But the "external link" library item type doesn't have a separate underlying content type - the library item (title, description, URL, group_id, etc) is all there is. So those will have to be queried and copied separately. I've attached a wp-cli script that I used for library copying - it's a bit of a mess and it does more than one thing, but you should be able to see how it queries for library items, then (near the bottom, after the return statement) clones them into new groups. This would only be necessary for external_link.
Because this job is quite a bit more complex and involves more parts of the codebase than site cloning, we may want to break it up. For example, it might make the most sense for me to handle library cloning, since I wrote a lot of that stuff. But it would be great for you to take the lead on the rest, especially integration into the front-end.
Take a bit of time to think through, and we can set up a time to talk in the next week or so if you'd like.
Updated by Sonja Leix about 4 years ago
- File Clone-group-flow-v2.pdf Clone-group-flow-v2.pdf added
Colin, thanks for the feedback and summarizing feedback from Friday's meeting.
we decided not to copy over any forum topics at all, even if started by an admin -- that way we're also not bringing over any forum attachments... We'll also only take docs authored by an admin, but not others.
How are we communicating during the cloning process which content is being copied over to the clone and which isn't (both for sites and groups)? Will there be any necessary post-clone cleanup for Sites too?
I've incorporated the feedback shared in the attached mockups. I've basically added a few more conditional things in the mockup:
1. When a user selects to clone an existing Group that does NOT have an associated Site, there will only be one screen to complete the cloning flow.
2. When a user selects to clone an existing Group that has an associated Site, the user has an option to clone the associated site (which the user can configure in the next step), create a new site to associate to the cloned Group (the user can create a new site in the next step – UI already exists for this), or just clone the Group without a Site. >> Let me know if all those options are needed and make sense.
3. I've added the link to the post-cloning cleanup checklist in the confirmation screen.
Please take a look and let me know if all of this makes senses and what further feedback you have.
Updated by Jeremy Felt about 4 years ago
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.
Updated by Colin McDonald about 4 years ago
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.
Updated by Matt Gold about 4 years ago
This is good but a bit complicated. Perhaps we could format the message as a bulleted list to make it easier to parse?
Updated by Colin McDonald about 4 years ago
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.
Updated by Sonja Leix about 4 years ago
- File Clone-group-flow-v3.pdf Clone-group-flow-v3.pdf added
Thanks for the copy Colin and feedback Matt.
I've incorporated it in the mockups, see attached.
Updated by Jeremy Felt about 4 years ago
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
Updated by Boone Gorges about 4 years ago
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.)
Updated by Colin McDonald about 4 years ago
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))
Updated by Jeremy Felt about 4 years ago
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.
Updated by Sonja Leix about 4 years ago
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.
Updated by Boone Gorges about 4 years ago
- Status changed from New to Testing Required
Jeremy has completed a first pass at this and it's ready for a look on cdev.
We still need eyes on the added copy. Look specifically at the success page and the "warning" notice about content that will be cloned. We also need a URL for the "clean up" button.
Updated by Colin McDonald almost 4 years ago
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/
Updated by Colin McDonald almost 4 years ago
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?
Updated by Boone Gorges almost 4 years ago
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.
Updated by Boone Gorges almost 4 years ago
- Status changed from Testing Required to Resolved