Python scripts in CMS folder can trash settings

Question

This morning I did S/R on a colleagues project (MumUni) and the S/R report said I had changed Properties and Settings. That surprised me since I never change settings on that project, even though I am an Administrator for the project. Using the Hg Workbench tool, I was able to determine that Paratext had added three properties to settings.xml when I ran a Python script from in the cms folder a few days ago using Checking > Advanced on the menu.

Prior to this morning, I had not done S/R on the project for a week or so, so when I did S/R this morning my version of settings.xml with week old properties and three new ones, overwrote legitimate changes my colleague made 9 hours previously.

Further testing has shown that whenever I run a Python script from the Checking > Advanced menu, if I click on the Options button and change any of the options, the changes get recorded in settings.xml of the project, if I am an Administrator of the project. If I am an Observer, settings.xml remains unchanged. This behavior occurs when any script, regardless of whether it is a script I wrote or one pre-installed with PT8.

I like the feature of Paratext of storing user choices for options for the Advanced Checks between sessions, but it is too dangerous to store them in settings.xml, because of the damage that can occur.

I am Paratext [Phone Removed]under Windows 10.

Answer 1

I think that when Python scripts were first developed, storing options in settings.xml was a reasonable decision. However, most of the original scripts have been replaced by more robust tools elsewhere in Paratext, so the role of Python scripts has changed.

You expressed a parallel between text and script options. I would like you to consider that there are several significant differences between the options on a Python script and scripture text.

• Scripture text is relevant to the entire team and supposed to last a long time. Options on a Python script are mostly view options that affect only what is to appear in a report and are relevant only to one person, and only for the short length of time they are doing a particular task. The options have no long term significance.

• Scripture text can only be changed by the user assigned to the text. Python script options can be changed by anybody except an Observer. If multiple people change a scripture text, Paratext gives a warning, and provides a way for users to resolve the conflict. If there is a conflict when multiple users change settings.xml at the same time, there is no warning given to the users. Not only that, but ordinary users have no what of even identifying what the conflict is. I only discovered a conflict by happenstance because I was using TortoiseHg workbench.

• The granularity of a change set for Scripture text is a single verse, so that multiple users can make changes to the same chapter without causing conflicts, as long as they don’t change the same verse. With settings.xml, the granularity is the entire file. If anyone changes a single setting in the file, the who file is replaced.

• Paratext developers have already recognized that there is a difference between permanent data and view preferences of a user, because things like window layouts and what a user last searched for are stored somewhere else besides settings.xml.

From another perspective, storing Python script options in settings.xml exposes a serious vulnerability to critical properties. A script coder can name an option anything including “language” or “StyleSheet”. If the script coder names one of his options the same as one property names already being used in settings.xml, the script can change the value of a critical property like “language” or “StyleSheet”.

I would like to propose a simple solution that should be fairly easy to implement. Currently, when an Observer runs a Python script, Paratext keeps their choices of options in memory as long as Paratext is open, but not in settings.xml. So as long as the user doesn’t close Paratext, his/her options are remembered, which is long enough for most uses of Python scripts. The solution is to treat Administrators, Translators, and Consultants the same as Observers. This change should be fairly easy to make, and would make using the scripts a lot safer.

Comments

anon895417:

With settings.xml, the granularity is the entire file. If anyone changes a single setting in the file, the who file is replaced.

Sorry, this is incorrect. The granularity is each individual setting. A setting can conflict with a change to the same setting, but a change to another setting will not conflict.

anon895417:

A script coder can name an option anything including “language” or “StyleSheet”. If the script coder names one of his options the same as one property names already being used in settings.xml, the script can change the value of a critical property like “language” or “StyleSheet”.

Hopefully, the creator of the script is smarter than that.

anon895417:

This change should be fairly easy to make, and would make using the scripts a lot safer.

Scripts are all considered unsafe - they have the ability to change anything in the project. That’s why they are considered an advanced feature and should only be done by very savvy users.

I’m sorry if it sounds like I’m fighting your suggestions/complaints, but requests for changes in features like this would need to be reviewed and prioritized before the changes are made. Based on what I know of our development workload, that Python scripts are considered an advanced feature, and the fact that no one else is complaining about them, I would guess any change would be a relatively low priority.

---

I see your point. Thank you for being patient with me.

Answer 2

anon895417:

Further testing has shown that whenever I run a Python script from the Checking > Advanced menu, if I click on the Options button and change any of the options, the changes get recorded in settings.xml of the project, if I am an Administrator of the project. If I am an Observer, settings.xml remains unchanged. This behavior occurs when any script, regardless of whether it is a script I wrote or one pre-installed with PT8.

This is by-design. If you have multiple administrators changing the same settings on a given Python script, you will get conflicts same as when multiple people change the text.