Skip to content

Unexpected exclusion behavior for string preference #83

@apizz

Description

@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.

screen shot 2018-11-25 at 3 07 47 pm
screen shot 2018-11-25 at 3 07 52 pm
screen shot 2018-11-25 at 3 07 58 pm

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:
screen shot 2018-11-25 at 3 31 18 pm

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.
screen shot 2018-11-25 at 3 31 21 pm

However, changing com.airserverapp.dualAirPlay to true doesn't remove the exclusion message.
screen shot 2018-11-25 at 3 31 27 pm

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.
screen shot 2018-11-25 at 3 54 42 pm

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.
screen shot 2018-11-25 at 3 53 00 pm

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.
screen shot 2018-11-25 at 4 03 28 pm

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions