Locked score unlocks by mouse interactions

According to my test: Just dragging was enough to unlock the score.

One of the main purposes for the lock score function was in response to teachers who did not want their students to edit their homework. Making this feature more discoverable would defeat the purpose.

Another way to unlock: have 2 scores open, lock one.
Switch to the other and back to the locked one: it is unlocked now

Actual result: the score leaves SCORE_LOCK state
Seems you mean STATE_LOCK, don't you?

How is locking a score useful (like to prevent another user in a different session to accidentally modify it), it it isn't a score property that gets saved along with the score?

Can't save it, as the score is locked, catch-22

This is not a problem. Locked score can allow save (and save as).
Locked is just to avid "accidental changes".

Semi-hiding an option to protect homework doesn't seem the right approach to me.

@frfancha just try it. As soon as you use Ctrl-Shift+L to lock a score all menus are disabled, so no way to save

Yes, I get that, and that is wrong.
You should be able to save including the locked attribute.

There is nothing corresponding to write to a score. It is a state, internally used by MuseScore (like edit, note-enty, play, etc), while doing certain operations, nothing that would be written to a score

Again I get that.
One of the discovery done through this thead is that having that "locked" attribute as a true piece of info saved in the score could be useful.

By the way, having it as a true attribute would most probably simplify the code responsible to check the locked state and therefore solve all the bugs discovered here

Just a note that there is a different form of score locking implemented for the purpose of the score comparison tool, so make sure you can't edit the "last saved version". I briefly looked into"productizing" that (perhaps by incorporating that code into the existing lock command). First attempts were promising but there were some bugs I couldn't immediately solve, and I had too much else going on to continue. Still do, unfortunately.

Reading the original forum issue, a readonly score is requested but the best MuseScore offers is a locked score which is also far too easy to unlock ;-). The readonly score is where @Marc Sabatella is referring to?

In a future Musescore UI for the score lock feature, perhaps the "Mark as Final" feature in Microsoft Word might be a relevant model. Once set, the UI clearly shows the lock, but ANY user has the ability to turn off the lock and edit.

I'm looking at implementing this in v4.
I don't intend to add any additional functionality but my assumption is that in lock mode:
a) the only way to make ANY modification to the score is to first explicitly unlock it
b) all commands that do not modify the score should still be available, including save, selection commands, copy, pan, zoom, navigation commands - the only exception would be "mode change" commands like "note entry mode"
c) click & drag in lock mode should always pan the score regardless of what you click on

That's somewhat different to what we have now where
a) you can still modify/add elements via the palette even in locked mode
b) you can modify element/staff properties via the inspector or staff properties dialog even in "locked mode"
c) click & drag auto unlocks
d) piano roll editor still allows modifying score (NB this is being implemented currently for v4)
e) various context-menu commands like "split staff", etc. are still active
f) quite a lot of non-score-modifying commands are unavailable (e.g. save, select all, page up/down etc.)

The main challenge will be still allowing the inspector/properties panel and e.g. "staff properties" dialog to be useful without allowing them to make modifications.

Dylan’s proposal sounds very sensible.

I'm hoping Qt Quick/Qml has an easy way of disabling the whole panel!

I like the idea that "lock mode" by default hides all the dockpanels that aren't useful. It could even automatically hide unprintable stuff etc., in other words it's more like a "print preview" or a "score reading" mode that's intended for performing from etc.
Either way it's not going to be trivial to do well - what MU3 has at the moment doesn't seem worth all that much, other than the beginnings of a useful concept.

No sorry, haven't been contributing recently, would like to get back into it but kinda waiting till things settle down a bit.