Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sponsorship packages #508

Merged
merged 5 commits into from
Mar 8, 2024
Merged

Sponsorship packages #508

merged 5 commits into from
Mar 8, 2024

Conversation

davidfurey
Copy link
Member

@davidfurey davidfurey commented Feb 16, 2024

What does this change?

Creates a new sponsorship attribute called sponsorshipPackage. This is to allow the US Ads team to sell sponsorships under the ‘Advertising partner’ or ‘Exclusive advertising partner’ labels. These labels will never be applied to Foundation funded journalism.

An update to our externally facing content funding guidelines will be published before this change is used.

How to test

Cannot be tested until tags-thrift-schema PR is released. See guardian/tags-thrift-schema#43

  • Deploy to CODE.
  • ensure you have permission
    image
  • Attempt to create a new sponsored tag
  • See that you can set the sponsorshipPackage to default, advertising partner or exclusive advertising partner
  • See that once you have created the tag you can edit this field but cannot edit the sponsorship type
  • Attempt to edit a pre-existing sponsored tag
  • See that its sponsorshipPackage is set to the default value initially

How can we measure success?

US ads team are able to create new sponsorships that meet their requirements.

Have we considered potential risks?

Existing tags will continue to have no value for this field until they are first edited. This is captured as an Option value in Scala and an optional field in thrift.

Images

Creating a sponsored tag

Before

Screenshot 2024-02-16 at 17 27 01

After

Screenshot 2024-02-16 at 17 26 37

Editing a sponsored tag

Before

Screenshot 2024-02-16 at 17 38 59

After

Screenshot 2024-02-16 at 17 26 45

Accessibility

Copy link
Contributor

@twrichards twrichards left a comment

Choose a reason for hiding this comment

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

tested in CODE - all working nicely AFAICT

Code LGTM and I learnt that return false from a component (as you have done) is better than return null when you don't want the component to render anything.

render () {

if (!this.props.sponsorship) {
return false;
Copy link
Contributor

Choose a reason for hiding this comment

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

if you want it to render nothing, I think returning null is better to avoid false being printed to the screen

Suggested change
return false;
return null;

Well, TIL https://medium.com/@davidkelley87/stop-using-return-null-in-react-a2ebf08fc9cd

Copy link
Member Author

Choose a reason for hiding this comment

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

So I should stick with return false? Most of this was copy+pasted from SponsorshipPackageType.react.js

@davidfurey davidfurey merged commit 392920b into main Mar 8, 2024
1 check passed
@davidfurey davidfurey deleted the sponsorship-packages branch March 8, 2024 14:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants