Hi all, an easy solution for the “Accidental Save” issue is to set the template files to READ ONLY in your file system. I just tested this and when I tried to edit a template file Obsidian threw an error saying it couldn’t write to the file. Its easy to reverse this when you do want to edit the templates. And this of course could be applied to any file you don’t want changed.
Keep in mind that if you have Sync set up, this will probably create issues.
@Iconca I completely agree. I, too, am to afraid to use it how I want to because of how easy it is to make a change to something you want just so.
@rigmarole Snapshots will definitely help but sometimes I don’t know until months later that I’ve changed something and even sometimes I don’t know what and the note has been added to since so it gets complicated.
I don’t know what the solution is but I wish there were something in the GUI that allowed me to “lock” certain parts of the notes. I realise this is tricky.
I’ve been experimenting with the plugin mentioned in another thread;
However, it doesn’t lock notes; just makes them open as previews.
Is it bad to reply to this given that it’s from a while ago?
The only thing preventing me from using Obsidian as a place to gather knowledge is the inability to lock fields.
It isn’t bad if you have additional information to contribute. But bumping the thread just to bump it would be against our COC for “campaigning”. So kindly: please no more. We all wish our favourite features could get priority.
I often store code snippets, solutions from websites and scripts and so on in Obsidian. Basically I use it as my personal knowledge base. Once a note is edited to it’s final state, I would like to write protect it, so there is no possibility for accidental changes.
I tried to workaround this issue by simply toggling the protection bit of a note directly in macOS Finders Fileinfo-Panel. Unfortunately, Obsidian “flips out” on these files, so it doesn’t work this way.
There should be a checkbox or a context menu item somewhere to toggle the protection mode of a note.
I propose to fix the “workaround” first. If this works, a GUI feature could easily be implemented on a plug-in level.
I can’t implement feature requests, but I can propose potential workaround. When reading your request, I immediately thought of the Force note view mode plugin. This allows you to force the mode any file is opened in.
In other words, if you add obsidianUIMode: preview to the finalised notes in your vault with this plugin enabled, at least you have to consciously switch back to an editing mode before you’re able to do any changes to that file. 
Another option is using some CSS and a cssClass to lock editing of a note. The CSS:
.lock-note * {
-webkit-user-modify: read-only !important;
}
and in the Properties of the note(s) you want locked:
The Properties in document will be editable, i.e., you can remove the lock-note class by clicking the x, but not if you switch to Source mode. If you get stuck in lock-mode, you can remove the cssclass from the sidebar Files properties tab or using an external app.
Do you know how this works, @ariehen ? It also seems like it’s better to use contenteditable: false, according to contenteditable - HTML: HyperText Markup Language | MDN
But it beats me how this is meant to work…
Huh, it looks like user-modify is “non standard” and “depreciated”.
https://developer.mozilla.org/en-US/docs/Web/CSS/user-modify Seems to work though.
I hadn’t used contenteditable before, but it pops up in the app.css a few times:
Will give that a try the next time around.
