#133 Change the way QM handles permissions

[catonyx]

Feature: QM files are changed to read-only when Saved from within the QM tool even when used with version control tools but allow edits even when read-only.

Problem 1: When the .qm files are saved in version control (SCM tools), this creates confusion and is error prone for developers. If a developer opens a model files in QM for viewing, it is editable and can generate files with these changes even when qm file is read-only.

Problem 2: If a developer checks out the file, the file becomes writeable (in most version control tools anyway) but then goes back to read-only when saved from the QM tools (even though it is still checked out). Depending on the situation and version control tool usage, this can cause confusion on check-in. In some cases, the file may not be submitted correctly.

Potential solution: Change this to match a typical usage for cpp, docx, and other files stored in version control. This would mean that a "Save" would not alter the permissions and would rely on the operator or version control tool to do this.

In addition, it would be nice to either have a warning or error if a developer attempts to edit (via QM tool) a model when it is read only (perhaps forced to check it out first, etc.). I wound consider this to be a "standard" behavior for software.

I do not understand why so many people are trying to edit the .qm directly (like in a editor) but apparently this is the rational for the current behavior which was discussed in the forum.

Reference conversation
https://sourceforge.net/p/qpc/discussion/668726/thread/8bb9967d/#b304

If necessary, these solutions could possibly be conditional in the options/preference such as SCM mode but should easy to configure for multiple developers that may be using the same paradigm.

We have 5 developers that would appreciate seeing improvements in this area.

Thanks for considering.

[Mikael Persson]

I landed on this bug ticket from being surprised by this behavior. I generally share the OP's opinion that this is unintuitive behavior.

Without trying to overtake / clutter this bug-ticket, I would describe my use-case, and hopefully there is a better solution. How I hit this is that we generally like to use pre-commit hooks in our git repositories to apply basic sanitizing checks and linters on any code that is checked in. These are failing to even read the qm files (incl. generated .h/.c files) due to 400 permission rather than 444, let alone applying fixes.

(Q1) Why use an owner-only read-only permission level (400) rather than a broader read-only permission level (440 or 444)? I get the rationale for read-only, but not for owner-only read-only.

An obvious solution for my issue is to exclude QM files from pre-commit hooks or any other linter/analyzer tools (or wrap the scripts with "chmod"). Which raises another obvious question:

(Q2) What is a typical setup to applying such tools to QM files and the generated sources? (e.g., cpplint, clang-format, clang-tidy, static analyzers, checking for typo's, missing docs, etc.) I assume I'm not the only one who is nervous about having any non-trivial amount of "naked" code embedded in an XML file.