Unexpected exclusion behavior for string preference

[apizz]

I've been working on a manifest for AirServer and am having some trouble achieving the desired visual exclusion messages between two preferences.

Scenario:

Preference 1 (com.airserver.dualAirPlay), which is boolean, if set to true indicates that AirServer will communicate itself as two separate devices - an Apple TV and an audio-only streaming device for iTunes. If this preference is set to true it also allows for a second optional preference (UserLosslessAudioReceiverName), which is a string, to set unique name for this audio-only streaming device.

As a result I'm trying to accomplish the following in the AirServer manifest:

1. If UserLosslessAudioReceiverName is added, produce an exclusion message if com.airserver.dualAirPlay is not also added.
2. If UserLosslessAudioReceiverName is added but com.airserver.dualAirPlay is not set to true, produce an exclusion message.
3. If com.airserver.dualAirPlay is added and set to true and UserLosslessAudioReceiverName is added, produce an error if the UserLosslessAudioReceiverName text field is empty.

Manifest Setup:

I based my manifest off the com.microsoft.Outlook manifest, which has two boolean preferences PII_And_Intelligent_Services_Preference & kFREIntelligenceServicesConsentV2Key, each which require the other to be present and true. Notable, upon adding the required preference and changing the setting each preference to be true or false immediately updates the applicable exclusion messages.

Below is my manifest for the two applicable preferences
com.airserverapp.dualAirPlay

                <dict>
			<key>pfm_name</key>
			<string>com.airserverapp.dualAirplay</string>
			<key>pfm_type</key>
			<string>boolean</string>
			<key>pfm_description</key>
			<string>Only enable this preference when you wish to set a custom name for the device running AirServer in the AirPlay device list.</string>
			<key>pfm_exclude</key>
			<array>
				<dict>
					<key>pfm_target_conditions</key>
					<array>
						<dict>
							<key>pfm_contains_any</key>
							<array>
								<string></string>
							</array>
							<key>pfm_target</key>
							<string>UserLosslessAudioReceiverName</string>
						</dict>
					</array>
				</dict>
			</array>
		</dict>

UserLosslessAudioReceiverName

                <dict>
			<key>pfm_name</key>
			<string>UserLosslessAudioReceiverName</string>
			<key>pfm_type</key>
			<string>string</string>
			<key>pfm_description</key>
			<string>This option creates a second AirPort Expresss-like audio receiver suffixed with an Ex. Streaming music to this endpoint will force the iOS device to stream your music in lossless quality. Enabling this setting can also allow you to watch a video on your iOS device and send only the audiostream to the AirServer.</string>
			<key>pfm_exclude</key>
			<array>
				<dict>
					<key>pfm_target_conditions</key>
					<array>
						<dict>
							<key>pfm_n_range_list</key>
							<array>
								<true/>
							</array>
							<key>pfm_target</key>
							<string>com.airserverapp.dualAirplay</string>
						</dict>
						<dict>
							<key>pfm_present</key>
							<false/>
							<key>pfm_target</key>
							<string>com.airserverapp.dualAirplay</string>
						</dict>
					</array>
				</dict>
			</array>
			<key>pfm_value_placeholder</key>
			<string>Lossless Quality Receiver Name</string>
		</dict>

Issues:

When the UserLosslessAudioReceiverName preference is added, it correctly produces an exclusion warning that com.airserverapp.dualAirPlay doesn't exist:

When com.airserverapp.dualAirPlay is added, it correctly produces an exclusion warning that com.airserverapp.dualAirPlay must be true in order for UserLosslessAudioReceiverName to be present.

However, changing com.airserverapp.dualAirPlay to true doesn't remove the exclusion message.

Conversely, if I add pfm_default with a value of true for com.airserverapp.dualAirPlay it correctly doesn't show the previous exclusion message. However, changing this default setting of true to false does not then produce the expected exclusion message.

Additionally, with pfm_default with a value of true for com.airserverapp.dualAirPlay if I first add this preference and then add the UserLosslessAudioReceiverName preference, it correctly produces the desired exclusion message that UserLosslessAudioReceiverName is blank.

However, adding text to the UserLosslessAudioReceiverName field does not then remove the exclusion message. Only after toggling the com.airserverapp.dualAirPlay to false and then true will the message go away.

Conversely, with pfm_default set to true for com.airserverapp.dualAirPlay, if I first add the UserLosslessAudioReceiverName preference and some text into the field, when I add the com.airserverapp.dualAirPlay it does correctly produce no exclusion messages.

Removing the previously entered text does not produce the exclusion message, but toggling the com.airserverapp.dualAirPlay checkbox off and then on again does produce the exclusion message.

Theory:

It appears there's something in ProfileCreator that correctly causes the exclusion rules between two boolean preferences to be updated correctly. The above issues appear to be a function of when ProfileCreator analyzes the exclusion rules for string preferences and that these never get rerun after these preferences are added or updated.

Possible Solution?

If there's not an easy mechanism to rerun exclusion rules for string preferences when the text field is de-selected, or some other action is taken in the GUI, perhaps it would be possible to add a "Refresh" button for text fields that have one or more exclusion rules tied to them, which could then be clicked to rerun these rule checking mechanism.

[erikberglund]

Thanks for the detail, I will look at it soon, have been away for a few days and one more, then Ill look and fix whats need fixxing

[erikberglund]

I'm going to look at this now. If you are only interested if the key is empty, you can use the pfm_value_empty key which does that. But it's true that strings doesn't get automatically updated. I can add a change for that too. But, I will change to pfm_value_empty and test to see the issue and how it should be solved here.

[erikberglund]

I've updated the trigger that if a cell view that is a textfield is the target of an exclusion or inclusion rule, it will update. Sent you a video on Slack, check that and see if that solved what you were looking for.

[apizz]

The video you sent in Slack looks good! Thanks for fixing this.