Read-only (setting|file) and encrypted eyaml values

[oneiros]

As discussed previously, we currently have one questionable decision and an edge case we did not think through when it comes to the combination of read-only files and encrypted values:

When we added decryption of encrypted values in eyaml, we made a decision to not allow this if the read_only configuration option is set to true. Sadly, I do not recall why we made this decision and we did not document it afaict.

Later, we added another configuration option, allow_encryption, so you can explicitly enable or disable en-/decryption. This now leads to a situation, where you can have the following in your config/hdm.yml:

read_only: true
allow_encryption: true

And the latter will not have any effect because of the former. This is unfortunate imho.

And then there is the edge case: In case the user hdm is running as has no write permission on a file, we display its values the same way as in read-only mode. This makes sense to prevent edits, when they would not be possible, but also means that you can have:

read_only: false
allow_encryption: true

and still not be able to decrypt anything 🤯

From the code's perspective the simple reason is that we use different HTML for read-only and read-write views of a value. The latter displays a form and decryption is implemented as part of that form. In theory, forms can be used for read-only views as well. HTML offers both a disabled and a readonly attribute for form fields for this.

So my proposal is this: We display the form in any case, but set the readonly attribute on the textarea if a value cannot be written and only show the buttons that are applicable according to the configuration.

So in case read_only is set to true and allow_encryption to false, we would get:

In case read_only is set to true or the file cannot be written to but allow_encryption is set to true, we would get:

And only if read_only is false and allow_encryption is true we would see all the options:

This would be a simple change that might even simplify some of our code and imho would lead to more consistency and flexibility for the users.