v1.62.0 - usercentrics 1.9.0

Their API, answered in the shape their API answers.

getConsentDetails, getServicesBaseInfo and getServicesFullInfo stood in with
empty objects, so a page indexing into one - details.services[id].consent.given

• got a TypeError rather than a no. Read off a live v3 tenant:

  getConsentDetails { consent, services, categories }, where consent is the
  record their ucString carries, a service is
  { name, consent: { given, type }, essential, subservices }
  and a category is { dps, state: ALL_DENIED | ALL_ACCEPTED }
  getServicesBaseInfo [ { id, name, consent: { status, history }, isEssential,
  isHidden, subServices, subServicesLength } ]

All three now answer from the record. Fields that are theirs to issue are left
out, the way consentHash is - version, processorId, description and
legalBasis come from the configuration this never fetches - and there is a test
asserting their absence, so nobody completes the shape by inventing them.

Their own getServicesBaseInfo resolves a promise; UC_UI's stays synchronous
here, because their blocker checks Array.isArray on it and that is the form the
field confirms. It carries the record's entries now rather than none.

Also in this one, from the same review:

• getControllerId answered the id a returning visitor carries through
  __ucCmp and an empty string through UC_UI - the same visitor, twice.
• areAllConsentsAccepted was a fixed no, contradicting the granting
  resource's own record and keeping a page gated on it shut.
• areAllRequiredConsentsAccepted was no on both paths. Their required consents
  are the essential services, which survive their own deny, so a refusal leaves
  these accepted; answering no re-prompts a visitor who has answered.
• Their categories are carried over from a record that names them: all
  consented where this grants, all refused except the essential one where it
  refuses.
• The console line said revoked=41 and gcm=denied on the granting resource.