Skip to content

✨ [amp-consent] Add purposes to user actions for inline PromptUI#32470

Merged
micajuine-ho merged 11 commits intoampproject:masterfrom
micajuine-ho:granularPromptUi
Feb 12, 2021
Merged

✨ [amp-consent] Add purposes to user actions for inline PromptUI#32470
micajuine-ho merged 11 commits intoampproject:masterfrom
micajuine-ho:granularPromptUi

Conversation

@micajuine-ho
Copy link
Copy Markdown
Contributor

Partial for #31607

  • Create new setPurpose action in the PromptUI, so that publishers can explicitly tell AMP which purposes shave been accepted and rejected
    • setPurpose accepts multiple args (purposes) and each must be set to True/False (denoting if the purpose has been consented to)
<button on="tap:ABC.setPurpose(purpose-foo=true)">ACCEPT FOO</button>
<button on="tap:ABC.setPurpose(purpose-foo=false,purpose-bar=true)">ACCEPT FOO & BAR</button>
<label for="consent-purpose-xyz">
  <input type="checkbox" on="change:ABC.setPurpose(purpose-xyz=event.checked)" id="consent-purpose-xyz" />
  Toggle Bar Consent
</label>
  • The purposes will be stored in the consentStateManager, which will eventually store these values in local storage (to cache) and propagate them to the consent policy manager (to block and unblock).

  • Modified the existing accept and reject actions in the PromptUI to accept a purposeConsentDefault argument that will tell AMP to use this value as a fallback for all purposes state in purposeConsentRequired.

<button on="tap:ABC.accept">Accept</button> 
<button on="tap:ABC.reject(purposeConsentDefault=accepted)">Reject</button>

@micajuine-ho micajuine-ho requested a review from dmanek February 8, 2021 16:07
@micajuine-ho
Copy link
Copy Markdown
Contributor Author

@dmanek PTAL

Separated the "closing" actions from from the new setPurpose action and did some refactoring so that we have clear responsibilities for these methods but also reuse code when possible.

Also moved the purposeConsents to the consentStateManager rather than the consentInstance since idealistically, the consent instance really only should have a consentInfo (which is where the purposeConsents will be stored in the future) and the manager is giving the consentInfo (via update()). So, in the manager will be responsible for passing along the purposeConsents to the instance within consentInfo

dev().error(TAG, 'No consent state manager');
return false;
}
return this.isPromptUIOn_;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: isPromptUiOn Sorry, missed this earlier.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea it's weird, b/c in our config we have promptUI, promptUISrc, and postPromptUI... should get to changing this (maybe a fixit week item 👀)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants