Ops: Script to fix project preferences

[ChristianBeer]

Description of the Change
Adds a script that does some maintenance on project specific preferences. Currently does:

• squash duplicate app_id entries (and optionally delete deprecated appids)
• delete empty venue tags (confuses older clients)
• migrate preset from attribute to tag (Drupal specific)
• validates the XML snippet

Alternate Designs
Can be done using other script languages but we already have everything in place for PHP to work well with the DB.

Release Notes
N/A

[lfield]

I just tried this and got the following error.

PHP Fatal error: Cannot use object of type DOMNodeList as array in /boincdata/boinc/project/lhcathome-dev/html/ops/fix_project_prefs.php on line 62

[ChristianBeer]

Fixed. Please try again. I don't have access to a project where I can test this myself anymore.

[lfield]

I tested this and it looks like it did not break our dev project. I am happy to merge this as unless you chose to execute this script, it will have no affect on the code base. However, why do we need to have a 'fix' script in the first place? Suggests that something else is broken which should be fixed.

[ChristianBeer]

This script was originally developed for Einstein@Home which treats selection of apps differently and also uses Drupal to manage the preferences and has stricter requirements on XML validity. So while fixing project specific things I wrote this script to fix the EaH database. As this might be useful for other projects that encounter problems with the project specific XML it might be handy to have a script ready that just needs to be augmented to fix a future problem. This is also a good start for a validation mechanism.

[brevilo]

Hi Christian, can you remind me about the following:

• "which treats selection of apps differently": in which way? we're certainly upstream-compatible
• "also uses Drupal to manage the preferences": how does that concern non-project-specific preferences?

Thanks

[ChristianBeer]

"which treats selection of apps differently": in which way? we're certainly upstream-compatible

In the way how EaH adds new apps to the selection which resulted in duplicate entries and deprecated apps being still present in the preferences. This might be true for other projects using this selection mechanism too. So it might not be specific to EaH but at the time I only had the EaH specific cases in mind.

"also uses Drupal to manage the preferences": how does that concern non-project-specific preferences?

I meant the project specific preferences in Drupal. Which in the beginning used an attribute to mark presets (in addition to venues) but when we found out that the Client can't handle a second attribute we switched from attribute to tag. This is the Drupal specific part I meant.

[brevilo]

Right, that makes sense. Thanks!