Skip to content

test users

Tom Richards edited this page Jul 1, 2020 · 11 revisions

For local development (and CODE) new contributions and subscriptions can be created using https://support.code.dev-theguardian.com (only accessible inside GNM network), when signed-in with an account...

  • if you need to receive emails (e.g. holiday stops confirmation, delivery address change confirmation etc) then use your guardian email with the + trick (e.g. tom.richards+meaningfulname@guardian.com)
  • if you dont need to get emails then you can use meaningfulname@gu.com (as @gu.com is an email black-hole) ...where meaningfulname refers to the purpose of the account (e.g. gw_fix)

Note that DEV & CODE identity use the same DB, so you can sign-in with the same creds (in fact under normal circumstances local nginx is configured to proxy CODE identity-frontend onto profile.thegulocal.com for sign-in etc. - see README and pull/439).

test-users

Also see /support-frontend/wiki/Test-users.

Currently test-users work using a special string (encrypted timestamp) held in the First Name field of the Identity user. During the first 48hours after the string is generated it points all/most of our systems to the UAT instances of Zuora & Salesforce, with the main use case being able to test PROD systems (typically UIs) but with test payment details (see Stripe, GoCardless and PayPal).

The current mechanism is a constant source of confusion and so would benefit from an overhaul - see wiki/Major-TODOs#overhaul-test-users-across-rr-to-become-identity-feature.

manage-frontend itself doesn't have a test-users implementation, but instead relies on the X-Gu-Membership-Test-User header from members-data-api and it then uses this value to pass onto other APIs (see wiki/Proxying-API-Gateway-Lambdas) - this complexity could be avoided if test-users became an identity feature and was exposed as a flag in the existing Identity integration - see wiki/Major-TODOs#overhaul-test-users-across-rr-to-become-identity-feature

Clone this wiki locally