Changes to space_member_remove

[Ghotitox]

The change in syntax and terminology, and unclear documentation is causing problems for me. Previously,

space_member_remove(123456, userlist, remove_projects = TRUE, ask = FALSE)

would move projects from the class space to the students' personal spaces-- this is important for me to get right, since students are building a portfolio throughout their college career. I have tried to read the comments on Github https://github.com/rstudio/rscloud/pull/54 but it is not clear what you are saying. It is very unclear which of the new options relating to "content_action" would do the same. "Leaving the content where it is" makes no sense, if I am removing people from a space-- but if I were forced to guess, this might be the new option I want. Exactly what does "Archive" do? Remove access from the students, but preserve access for the space owner? I assume "trash" would delete the students' spaces and projects?

Additionally, can we choose more than one option? I discussed this with the team before-- in universities we are supposed to keep records for 2 years. So, can we both move student projects to their personal space AND keep a copy in an archive? Something like

space_member_remove(123456, userlist, content_action = c("archive", "leave"), ask = FALSE) ???

Thanks!

[hekhuisk]

Hi @Ghotitox! As you said, previously when you would remove a user from a space it would also remove all of the user's content in that space and move it to their personal workspaces. Back in October we have changed how removing a member from a space works based on customer feedback. The options now are leave, archive, or trash.

• leave: When a user is removed from the space, any content the user owns in the space will be left in the space as is.
• archive: When a user is removed from the space, any content the user owns in the space will be moved to the space's archive. Space archives are something new we added back in September which is intended to help customer's like yourself with compliance of having to keep records for a certain period of time.
• trash: When a user is removed from the space, any content the user owns in the space will be moved to the space's trash.

You may only choose one option. If student's wish to have a copy of the work themselves they can choose to move it themselves.

[Ghotitox]

Thanks for the reply-- but this is not how RStudio.Cloud was sold to me, and making these kinds of critical functionality changes in the middle of semesters without consulting or advising users causes enormous problems. I have to remove students from all of last semester's class spaces in our department NOW (to prevent charges we can't afford), but our degree program is designed so that students need to keep their portfolios of work from previous courses. Last August we very carefully explained to the students that this would be done automatically at the end of the semester, since that was the functionality at the time. Why not have a fourth option that preserves this important previous functionality? And again, we also need to keep student work ourselves for 2 years, so allowing both previous functionality and leave ing) or archive ing all of it simultaneously would be best for use in coursework.

I do like the ability to control copying content, but would like for this to be set at the project level. For example, I want Tests to be controlled, but their homework projects to be theirs for their portfolios.

[malcolmbarrett]

I agree. This is important to my workflow as well and improves the student experience. Students want a copy indefinitely, so it makes sense to be able to move their projects to their own space.

[malcolmbarrett]

Was this changed on the backend, too? When I try to install an older version of rscloud, I see

  Status: 400
  Response: Transfer content prohibited.; transfer_content_prohibited

Is that expected given this change?

[Ghotitox]

Was this changed on the backend, too? When I try to install an older version of rscloud, I see

  Status: 400
  Response: Transfer content prohibited.; transfer_content_prohibited

Is that expected given this change?

Yes, they removed the ability for instructors to move items to the students' personal spaces, so it just can't be done. You have to beg your students to do it themselves (which I hate-- this implies that they can move their projects while the course is still ongoing, which precludes doing things such as cheating investigations; if they don't do it themselves, when you remove them from your space you can archive their projects... but for the student at this point they are gone.

[malcolmbarrett]

Ah, I didn't gather the feature was completely removed. Thank you for the info. I do hope it's brought back, as this completely upends my workflow, and I don't think this is an adequate replacement.

[Ghotitox]

I agree- I discussed this with some of the developers and they they said they "heard my concerns", and thought there would eventually be some kind of change made. I never heard anything back about it. I would recommend submitting a ticket on this, to force them to hear this request from someone else.

[stevenolen]

Hi folks! I'm sorry to hear that this change is forcing a shift in your workflows! I wanted to pop in and add a little commentary about the change.

The error message you received from the backend tells quite a bit of the story around the permissions change. As an instructor, you have control over this space and the content created in it, so I can understand why the workflow akin to "ejecting" this content in a space you own feels reasonable. However, a distinct permission issue is embedded in that -- you, the instructor, don't have permission over another user's personal space (and therefore, must lack permission to create/place content within that space). If you could do this, you could force another user in our system above content limits for their account tier, etc. That's their decision to make.

The current workaround is to have the student leave the space -- they will be prompted to take their content with them.

I'd like to take this back to the team and discuss making this experience better for you. I can completely understand that pestering students to click a button can be way more burdensome than it sounds! Hopefully, I've at least made it clear why we wouldn't be able to revert a change like this and why we made such a change in the first place. If you have ideas for how we could improve this workflow, given the current requirements, I'd love to be able to listen and share them with the team!

[malcolmbarrett]

Thank you for the background info.

I do understand this perspective. I also know that, without question, moving their projects to their personal space is what the students in my course want me to do.

Perhaps there's a balance here, where removing someone from a course space triggers an email that allows them to move their projects or something like that? The key detail is the automation, e.g. make this as easy as possible for students to end up with the projects when they want them (and, again, I'm quite confident that most do)

[Ghotitox]

So, you are telling us that students will never be able to keep their projects, because of the project limit cap? Ideally, projects students create in a class wouldn't count against their free-level projects cap when moving them into their personal space. The whole point here is for students to be able to learn. You can't learn coding if you can't keep your old files.

I guess could cram all of the things we do in my classes into one large project, but that would be very poor pedagogy, and poor organization-wise. I typically organize things into around 14 small projects with a different focus during the semester.

My main selling point for using Posit.cloud in the first place was for our students to be able to create a portfolio throughout their three classes using Posit.cloud in our curriculum-- that way they could easily refer to their earlier projects in later classes, to build on them. Ideally, in job interviews they could pull up Posit.cloud and show their interviewer all of the thing they had done in these classes. In our curriculum all but one of their projects will be VERY small... we do one project with a somewhat large (around 3 million observations) data set, just to expose them to that. So, it isn't that much server storage space (I don't think).

I guess if students didn't access these things in 24 months or something, then you could warn them and delete them in they became inactive. Hopefully there is some decent solution here.

[stevenolen]

So, you are telling us that students will never be able to keep their projects, because of the project limit cap?

Absolutely not, and apologies if I wasn't clear! I wasn't implying that students couldn't keep their projects because of a cap, only that their personal (and potentially free-tier) accounts may be subject to different content limitations than your account/space where the project originated. Under that expectation, it needs to be the student's choice in handling this content migration. The free tier limit (25 projects in their personal space) appears plenty for students who have only used their posit.cloud project for your course. If they had, however, used their posit.cloud personal space for 25 projects already, they'd need to take a few moments to archive or export existing work in that space before being able to migrate the 14 projects from your course. Hopefully, that clears up your concern!

I guess if students didn't access these things in 24 months or something, then you could warn them and delete them in they became inactive. Hopefully there is some decent solution here.

You're definitely on to something with a 'temporary holding area'! We've considered this and will discuss it along with other suggestions soon!

Perhaps there's a balance here, where removing someone from a course space triggers an email that allows them to move their projects or something like that?

@malcolmbarrett this is definitely an idea the team will consider; we had a similar one!

[Ghotitox]

@stevenolen Thanks for thinking about this with us. The biggest problem with the current restrictions is that all of this has to be initiated by the student, but the instructor is required to boot them out to avoid extra charges. The additional fact that instructors in the US are going to generally be doing this around New Year's or June makes it difficult to get students' attention when many don't check their university emails much anyway. So perhaps the following would be acceptable and feasible for everyone:

1) Owners of Organizational Spaces can boot people out, and boot their projects with them (optionally keeping a copy in the archive for educational records purposes for some amount of time). If there are any projects we don't want to boot to them, we can archive these in our own spaces before executing this process (as we can currently do).

2) Booted projects go to a holding area. People with booted projects get a notification to their email account and prompted the next time they log in. For each project in the holding area they can choose between a) download zip and move to trash b) archive c)move to personal workspace, or d) just move to trash.

Thanks!

[stevenolen]

Happy to help! 😄

The biggest problem with the current restrictions is that all of this has to be initiated by the student, but the instructor is required to boot them out to avoid extra charges

This makes perfect sense! Unfortunately, personal space permissions dictate this in some way (all actions taken on a personal space need to be done by the owner of the personal space).

The temporary holding area + notification feels like a great compromise, which I'll discuss with the team during our weekly triage. To be as transparent as possible, that likely would not be a trivial change -- so we may additionally investigate simpler alternatives as a stopgap!