There is also a request to “Lock Playlists” even for the creator/originator of the Playlist.
Here your wife could create the Playlists for the classes, and make then available in a locked form to other users.
If necessary, as creator/originator, she could unlock them to modify/adjust them, and then lock them again, but it would be deliberate change being made by her and is only available to her.
Sadly in Roon about the only thing that IS secure is command line access to the Roon OS core systems.
Really it is about time this changed…well it should have been built in from the ground up but here we are years later and still no progress.
Having run projects to add security into established programs, it is a pain to add later than at the beginning. But, in this case, the framework may indeed be there, just not activated.
Ooh, you tease! 
I hope so as to me it makes sense to be able to make a playlist read-only or at least lockable by the creator. If someone has a separate profile I doubt they would want their shared playlists modifiable.
Surprised this isn’t a feature… in my trial period and was thinking about lifetime membership, but this is a huge gap in the feature set.
I’m more surprised it has been a feature request for five years now and no progress or development has ever been made or announced (other than “it’s difficult”).
It’s not exactly mirrors and beads, it’s a basic software feature, especially when its makers promote multi-user, multi-room usage.
What you may consider a “basic software feature” does not mean it is simple to implement…
I point I make regularly at work, in fact more “to make a feature look and work simply and effectively, is in fact very difficult and takes time”
But doesn’t stop us doing it, just need to understand the requirements and think through the operation and implementation.
I am well aware of that. But “not simple to implement” does not automatically mean you can’t make and/or communicate any (plans for) progress at all in five years time. 
Well, @Grump, this “feature request” require Roon to implement “access control”. This requires Roon to scope out just how far they want to take “access control”. That is not basic nor simple. Whatever level of access control they would decide to provide, they would have to work out the UI and the overall user experience. I would argue that this is nothing short of a huge feature to add that would require a rewrite of a ton of existing code plus adding a bunch more new code. How many Roon subscribers do you think actually need “access control”?
Big decisions…lot’s of work…limited need…nope, not surprised it has yet to implemented.
I appreciate that.
That still doesn’t automatically mean you can’t make and/or communicate any (plans for) progress at all in five years time. After all, five years ago, Danny said in this thread:
His last comment is from 2017:
So I still understand this. But we’re talking years here, that was all I was basically saying.
Totally agree, Roon make a big point about never touching your local files, except to delete them! Does the “Delete Album” function exist primarily for removing streaming albums (I don’t stream)? If so, perhaps it could be limited to streaming services only? Otherwise, IMO the “feature” should go.
Do you remember when Roon had the option for managing your library via a one way import? I argued then that Delete should go when the rest of that stuff was removed. Although, now that they have added a CD-Ripping function, there exists a point for Delete.
I wrote that “big point”.
Many programs modify your tags during edits or try to keep their own app-specific metadata in your files by changing their tags. This is what Roon does not do.
Roon doesn’t ever modify your files. In fact, Roon doesn’t even delete them. You do it, by hitting the delete button and then acknowledging that you want to do this with big red warnings making sure you understand.
Lol, I’ve never pressed delete, it scares me! Big red warnings are good though. Hopefully they’re drunk/malicious visitor proof too.
I’d argue the fact that you have to do way too many clicks (4?) to even find the delete functionality makes it drunk proof… Malicious use in your home? You probably need to worry about someone smashing the iPad more.
But I do wonder what’s the point of having the delete function within Roon at all? Who needs to delete music files from within Roon that wouldn’t be better served doing so from the OS? If you do actually choose to use the Delete Album function, it removes all the actual music files (.flac in my case), but does not remove any other related files (e.g. .log, .pdf, .jpg) in the directory nor the directory itself. So you end up with orphaned files and directories.
personally, i have 2 use cases:
I do that as well. But (and not to belabor the point), old ripped music likely has old associated .log, .cue, etc… files laying around. If you use Roon’s Delete Album, you are not deleting those old related files.
I guess my take is having the Delete functions within Roon carry a risk (albeit slight risk) with, IMHO, little added value since deleting music files is easily and better managed outside of Roon.