Lock and password protect instrument visibility
S5 - Suggestion
The possibility to lock by password, the visibility or not of an instrument seems judicious to me, I use MuseScore in the framework of teaching and pedagogical tools and then this function will allow to deploy to the students who will have Access via the cloud, to online materials, however with a security regarding lessons and exercises, listening and rhythm, intervals, etc.
They can indeed intervene on the capture of the answers, but obviously they could only hear without showing what is masked.
I hope to have been clear in the explanation motivate my request.
Community and team friendships,
and happy New Year
For future reference, the "Assigned" field is for the person planning to write the code to implement a feature, rather than the person requesting it.
Password protection of scores came up time and time again, but this won't be possibe with an open source product like MuseScore, where everyone could just grab the source, modify it to circumvent the protection and rebuild. Or maybe even just extract the mscx fron an mscz and then edit it to loose that protection.
Since MSCZ is just a ZIP file, and ZIP files can be password protected, is there any way to take advantage of that? Not that this would address the specific request of protecting individual instruments.
I'm not sure this solves any of the problems that people think to resolve with password protecting a score
Password protecting a zip file is not really protecting anything. With a file, all the time in the world and a good GPU, it's probably easy to find the password with brute force.
To me, it's more philosophical. MuseScore is a free tool, the code is available to anyone. We are all about sharing our work and make it easy for users to share their work. Having a digital protection of any kind in MuseScore goes against all that and as other explained, it would be very hard to make it bullet proof.
I understand that for some use case, it would make sense to have the possibility of locking the score or locking a staff, but I'm not sure we want to address these use cases because of all the ill effects that they will add.
I think having some sort of password protection against someone accidentally making changes to a score would not be a bad idea. I don't think most users, even in a school environment, are looking to make this a top secret project, just to slow down anyone wanting to make unauthorized changes. Yes, this is open source, but it would take me some time to figure out how to bypass password protection and then recompile it. Of course most places where these is a server has it set up so that there are directories that can be read by certain people but not writable without permission. If you are allowing it to be put on another's computer then there is no reason for a password protection. When it comes to password protecting a specific item within a score, this could turn into a ridiculous exercise in options of what each person wants protected. As far as the situation in the original post is concerned, the file could be converted to an MP3 for listening with an accompanying text file giving the time stamps for the specific exercises.
If the programmers were to include a password protection against all modifications for situations such as the OP, then they would need to review what makes a file dirty. Right now, doing a search on a score marks the files as dirty (the file name has a star after it) and this, among other things, would need to be addressed.
I'm don't care one way or the other about password protection implementation, just thought I'd give some thoughts.
Data storage and analytics are also performed on premises, via on-premises https://www.protectimus.com/guides/on-premise-platform/ systems. Businesses may employ in-house resources to collect, store, and process massive volumes of data in near real-time. They will be able to base their judgments on the most recent and relevant data available.