Page MenuHomePhabricator
Search Advanced Search

Advanced Search
Use Results
Hide Query

Use the application-specific Advanced Search to set additional search criteria: Tasks, Commits. (More information)
  • T330724: Handle recurring IPNs for Dlocal
    • Task
    • ·Closed
    Cstone got this IPN from an initial UPI payment: ``` lang=json { "id":"F-413092-9b996803-00f0-4488-89e8-6c030a326956", "event_info": {"type":"payment"}, "amount":823.00, "status":"PAID", "status_detail":"The payment was paid.", "status_code":"200", "currency":"INR", "country":"IN", "payment_method_id":"IR", "payment_method_type":"WALLET", "payment_method_flow":"REDIRECT", "payer":{ "name":"Jimmy Wales", "user_reference":"", "email":"jwales@example.com", "document":"AAAAA9999C", "address":{"city":"Mumbai","empty":false} }, "wallet":{"token":"e299a5f9-920a-4be9-99d2-547841db9b4e"}, "order_id":"40060.1", "description":"Wikimedia 877 600 9454", "notification_url":"https://paymentsipntest4.wmcloud.org/dlocal", "callback_url":"https://localhost:9001/index.php?title=Special:DlocalGatewayResult", "created_date":"2023-03-07T22:58:57.000+0000" } ``` We should send a job with this info to the jobs-dlocal queue, and that job should look up the pending table details and send the combined info to the donations queue. For inspiration you could look to the [[ https://phabricator.wikimedia.org/diffusion/WFSP/browse/master/PaymentProviders/Adyen/Jobs/RecordCaptureJob.php | Adyen RecordCaptureJob class ]]. (but just implement Runnable instead of extending the deprecated RunnableJob).
  • T325191: Write up medium term project outline for ESI+CentralNotice
    • Task
    • ·Closed
    Things to include: * Overview of changes to CN * What the service would do ** Language choices (inc pros/cons) * What expertise would be needed ** To inform who needs to be included on the virtual team * Rough timeline (order of magnitude :) )
  • T324297: Support DLocal recurring cards in DonationInterface
    • Task
    • ·Closed
    - add the recurring flag to the createPayment API call - make sure the returned token gets sent to the donations queue - include a test that looks at the queue message For BRAZIL: special logic to show donors that recurring is not supported on debit cards. Either look for MD / VD bank code, or any card which has 3DS turned on.
  • T320734: CentralNotice: Add ESI test string to base HTML
    • Task
    • ·Closed
    - Add a test string, controlled via a config variable, inside a comment in the base HTML. - Make a config change to set the variable to the test string (see parent task)
  • T318883: Implement PayPal EC ManageRecurringPaymentsProfileStatusCancel in SmashPig
    • Task
    • ·Closed
    Doc Link: https://developer.paypal.com/api/nvp-soap/manage-recurring-payments-profile-status-nvp/ This is to cancel a recurring payment on the PayPal end, something we have not done with other PaymentProvider classes in SmashPig. So it can use a new function name (cancelRecurring?) and response class. Params: 'USER' => (from config), 'PWD' => (from config), 'VERSION' => 204, 'METHOD' => 'ManageRecurringPaymentsProfileStatus', 'ACTION' => 'Cancel', 'PROFILEID' => $params['subscr_id']
  • T316584: Adyen - UML sequence diagrams
    • Task
    • ·Closed
  • T316582: Review steps and create subtasks for Adyen Pending Transaction Resolver
    • Task
    • ·Closed
  • T311944: Meta talkpages for Central Notice banners turned into banner overview pages from the admin interface
    • Task
    • ·Closed
    **List of steps to reproduce** (step by step, including full links if applicable): * Log in with you Wikimedia account * Go to a page around central notice on Meta, for instance [[ https://meta.wikimedia.org/wiki/CentralNotice/Request/Wikipedia_Pages_Wanting_Photos_Campaign_2022#Central_Notice_admin_comments | a banner request ]], but also the [[ https://meta.wikimedia.org/wiki/CentralNotice | general information page ]] on central notices * Try to go to the talkpages of this page, where it now says "banners" * ... and find yourself not ending up on a talkpage, but in the admin interface for banners. **What happens?**: People end up in the admin interface (per my sockpuppet: without editting access), instead of on the talkpage of the Meta page. **What should have happened instead?**: visiting the talkpage **Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.**: Firefox and Chrome both give this problem. Happens logged in (with or without CN Admin rights on Meta), as well as not logged in. {F35299663} {F35299662} {F35299661}
  • T310915: Bundle test unintended duplicate donations
    • Task
    • ·Closed
    I’m putting this on everyone’s radar in case there’s a potential issue! The info below is from the bundle test and the donors informed us that they accidentally made duplicate donations. One of the messages was “My donation has been duplicated, due to a confusing message in the first transaction” Ticket#1129359 - CID 55740407 (Spain) Ticket#1129330 - CID 7963918 (Spain) Ticket#1129363 - CID 55741381 (Belgium) Ticket#1129377 - CID 11462036 (Belgium)
  • T310895: Some parameters dropped by Special:GatewayChooser for recurring donations
    • Task
    • ·Closed
    Not sure when this started, but I don't see any recurring card donations with utm matching the bundle test on Wednesday 15th, and this issue could cause that (note that you may need to use fresh private/incognito windows for the links below to avoid caching) **To reproduce:** Visit a Special:GatewayChooser URL with recurring=true e.g. https://payments.wikimedia.org/index.php/Special:GatewayChooser?amount=2&country=BE&currency=EUR&gateway=ingenico&opt_in=1&payment_method=cc&recurring=true&uselang=fr&variant=monthlyConvert_011&utm_campaign=test&utm_key=test&utm_medium=test&utm_source=test **Expected result:** All parameters are passed through and you end up on a correct payments form https://payments.wikimedia.org/index.php?title=Special:IngenicoGateway&appeal=JimmyQuote&country=BE&currency=EUR&payment_method=cc&gateway=ingenico&variant=monthlyConvert_011&amount=2&opt_in=1&uselang=fr&utm_campaign=test&utm_key=test&utm_medium=test&utm_source=test **Actual result:** The amount, uselang, and all utm_ parameters are dropped. https://payments.wikimedia.org/index.php?title=Special:IngenicoGateway&appeal=JimmyQuote&country=BE&currency=EUR&payment_method=cc&recurring=1&gateway=ingenico&variant=monthlyConvert_011 **Effects** - The donor has to select an amount again - the form is always in English - we are unable to attribute the donation to a banner/email This does not appear to happen if the initial URL has `recurring=false` https://payments.wikimedia.org/index.php/Special:GatewayChooser?amount=2&country=BE&currency=EUR&gateway=ingenico&opt_in=1&payment_method=cc&recurring=false&uselang=fr&variant=monthlyConvert_011&utm_campaign=test&utm_key=test&utm_medium=test&utm_source=test
  • T302936: Refactor & rename FormChooser::getOneValidForm
    • Task
    • ·Closed
    Should just return one gateway code. Get rid of wgDonationInterfaceAllowedHtmlForms and selection weight. Logic should be about like this: - Get list of all enabled gateways - Read configurations for all of them - Compare country, currency, payment_method from query string against config to narrow down list of gateways - Use tiebreaker function created in T302935 to just return one gateway Replace contents of DonationInterfaceFormSettings.php with config for tiebreaker function that makes the selected gateways consistent with original logic (enforced by unit tests created in T302891)
  • T297012: Post-payment Monthly Convert *Yes* button text overflows container on some devices
    • Task
    • ·Closed
    Hi, I'm going to triage this as 'high' priority because it's a live bug that would show up for any one-time credit card donor on an impacted device. I don't know exactly which viewports would produce the issue. Here's what I see on my iphoneSE in portrait mode: {F34821340}
  • T291431: Update CentralNotice admin UI to fix or replace broken JQ multiselect widget
    • Task
    • ·Closed
    Removal of JQMigrate (see T280944) breaks the creaky old multiselect widget used to select languages and projects (see T291410) One possible drop-in replacement multiselect, though it'll look different: https://ehynds.github.io/jquery-ui-multiselect-widget/#selectedlist That one would have the advantage of working with the same HTML that our backend generates, while OOUI would require rewriting the selector construction.
  • T290986: Email preference center: Implement polished UI
    • Task
    • ·Closed
    As a Donor I would like to see attractive ui for the email preference center so that I can understand and use the form. DoD: * implement the formatting shown in the screen shot and mockups, accommodating the currently implemented fields and controls. * Ignore the element on the right hand side with various types of subscription and things like "snooze" Screen shots are here: https://docs.google.com/document/d/1wKtGxJn06bs6OGAFV7DKUfVw2salKdU_NAUn5SMGks0/edit# Trilogy mockup: https://design.bytrilogy.com/wikimedia-email-preference-center?frequency=cat&button=&s=#epc-form-col-content-salutation-email-edit {F34922194}
  • T290103: Adyen Checkout: Remove flash of unused card type selection buttons
    • Task
    • ·Closed
    Screenshot of the flash that sometimes shows: {F34626941}
  • T287604: Adyen Checkout: Investigate possible changes to allow simultaneous deployment of old and new integrations
    • Task
    • ·Closed
  • T285449: Master tests failing for CentralNotice, "RuntimeException: Config accessed before it is set"
    • Task
    • ·Closed
    See example empty patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralNotice/+/701244 Caused by {T277728}
  • T283306: Adyen Checkout: Fine tune CSS
    • Task
    • ·Closed
    Make the new fields blend seamlessly into the existing fields - fonts - corner rounding - focus highlights - error messages. Also hide the 'continue' button on ideal
  • T281550: Make errors in drop-in card fields look like other errors
    • Task
    • ·Closed
    Current state of things: {F34435123} Will take some CSS and some i18n, as well as better handling of the errors in whatever function we pass to config.onError. Looks like the onError callback gets pretty detailed data to locate the problem.
  • T281443: DonationInterface: Update MaxMind + GeoIP libraries to latest version
    • Task
    • ·Closed
    Looks like it needs a minor code update, but we're a little ways behind.
  • T281304: deprecate and or move wikitech documentation to Mediawiki
    • Task
    • ·Closed
    As per discussion, the definition of "done" for this task will be: - Review of pages on Wikitech and make note of which ones are outdated. The results of this review are [[ https://www.mediawiki.org/wiki/User:AGreen_(WMF)/Draft:Fundraising_documentation_notes | here ]]. It does not make sense currently to copy over or stub new things on Mediawiki, since first we need to plan topics, subtopics and how they should be organized. See T288279 for this. I would also like to double-check that we really don't want anything left on Wikitech. Once that's done we can we can have a batch script run to archive all that, without having to do so manually for every article. --- Original definition of done: * Go through anything on wikitech and mark duplicate pages as depricated or out of date. * Anything not on mediawiki should get copied and pasted over to Mediawiki * Stub in pages for any gaps/topics that should be created in media wiki//
  • T278672: Docker dev setup: get default ports and compose project name from .env
    • Task
    • ·Closed
  • T278174: Fix flash of Mediawiki UI elements on Special:EmailPreferences
    • Task
    • ·Closed
    Currently, DonationInferface's Special:EmailPreferences shows a flash of Mediawiki elements sometimes. Let's fix it! :)
  • T277246: Omnipay mini test development and assessment
    • Task
    • ·Closed
    Similar to what was done with Spreedly: T271075 Please spend 5 work days setting up as much of Omnipay as possible along with one of our current payment providers. older omnipay task: T271074 one option is the braintree setup: hhttps://github.com/thephpleague/omnipay-braintree DoD: * describe the pros and cons of using this system at WMF * Would this system help us integrate faster or lower maintenance effort? * would you want to move to this system and deprecate any of our current systems?
  • T277196: wle_001 variant for e-mail opt-in is broken
    • Task
    • ·Closed
    https://payments.wikimedia.org/index.php?title=Special:EmailPreferences/optin&variant=wle_001 says, 'Fatal exception of type "Exception".' Here's the debug output for the same URL on Docker: [b36e74bdc03c7cf507f13499] /index.php/Special:EmailPreferences/optin?variant=wle_001 Exception from line 108 of /var/www/html/vendor/zordius/lightncandy/src/LightnCandy.php: Can not find partial for 'optinTop_wle_001', you should provide partials or partialresolver in options Can not find partial for 'optinBottom_wle_001', you should provide partials or partialresolver in options Backtrace: #0 /var/www/html/vendor/zordius/lightncandy/src/LightnCandy.php(50): LightnCandy\LightnCandy::handleError(array) #1 /var/www/html/extensions/DonationInterface/gateway_forms/MustacheHelper.php(36): LightnCandy\LightnCandy::compile(string, array) #2 /var/www/html/extensions/DonationInterface/email_forms/EmailForm.php(49): MustacheHelper::render(string, array, array) #3 /var/www/html/extensions/DonationInterface/special/EmailPreferences.php(100): EmailForm->getForm() #4 /var/www/html/extensions/DonationInterface/special/EmailPreferences.php(44): EmailPreferences->renderQuery(string, array) #5 /var/www/html/includes/specialpage/SpecialPage.php(600): EmailPreferences->execute(string) #6 /var/www/html/includes/specialpage/SpecialPageFactory.php(635): SpecialPage->run(string) #7 /var/www/html/includes/MediaWiki.php(307): MediaWiki\SpecialPage\SpecialPageFactory->executePath(Title, RequestContext) #8 /var/www/html/includes/MediaWiki.php(940): MediaWiki->performRequest() #9 /var/www/html/includes/MediaWiki.php(543): MediaWiki->main() #10 /var/www/html/index.php(53): MediaWiki->run() #11 /var/www/html/index.php(46): wfIndexMain() #12 {main}
  • T277131: Docker - preserve user settings for xdebug
    • Task
    • ·Closed
    When I run setup.sh my preferred settings are blown away ie xdebug.remote_autostart=on xdebug.remote_enable=on in both web & cli It would be good to have to put them back less often
  • T276582: Docker dev setup: Mediawiki debug log output
    • Task
    • ·Closed
  • T275054: Many invalid CentralNoticeImpression events
    • Task
    • ·Closed
    500k invalid events in the last day: https://logstash.wikimedia.org/goto/7ecbceeeedc656c28eb9be181f671106 > Additional properties are not allowed ('optedOutCampaigns' was unexpected) It seems to have started two days ago, maybe with af9b0791b4049a81f2314e1e081c8e6a4ef4f809.
  • T272794: [[MediaWiki:Centralnotice-user-prefs-intro/uk]] Meta-Wiki URL should include Special:MyLanguage/ prefix
    • Task
    • ·Closed
    The Meta-Wiki URL should include Special:MyLanguage/ prefix. I have tried just adding it into the translation, but this yields a "problematic link" warning, as Translate thinks the required link is not included. ---- **URL**: [[https://translatewiki.net/wiki/MediaWiki:Centralnotice-user-prefs-intro/uk]]
  • T271154: Deploy accumulated changes in CentralNotice master 2021-01
    • Task
    • ·Closed
    As of this writing (updated 2021-01-26) the commits involved are: ``` $ git log --pretty=oneline --abbrev-commit --no-merges origin/wmf_deploy..origin/master | grep -v "Localisation updates" 1530ef09 build: Updating dependencies c909866c build: Updating eslint-config-wikimedia to 0.18.0 69e48308 Use Special:MyLanguage for link in user preferences 2746b8ad Selenium: CentralNotice banner is displayed on Main Page b52b67b7 Explanatory text in user preferences for camapign types 927b2ad1 Move Campaign class tests to separate class 6890320f Control displaying campaigns based on user preferences 094f87ea Campaign filtering 33c729fc Schema updates for campaign filtering 80d0e769 Add missing @var and improve documentation feb75270 build: Updating dependencies d2e9b63d Avoid $wgRequest in special page and hook dd531c21 Small formatting improvements in Campaign.php 28fabae5 Avoid wfMessage in special page and pager 84710ab7 Use User->isRegistered(), not deprecated isLoggedIn() 4f3ef9d6 Improve docs around object type hints 647e0d9b Anchor regex for campaign sanitization 5af54ba9 build: Updating mediawiki/mediawiki-phan-config to 0.10.5 23f32801 build: Update stylelint a2b17422 build: Updating mediawiki/mediawiki-codesniffer to 34.0.0 3444f81a build: Updating mediawiki/mediawiki-codesniffer to 33.0.0 ``` This includes patches for the new campaign filtering feature.
  • T271077: Step 1: Investigate Paypal through braintree
    • Task
    • ·Closed
    reference docs https://phabricator.wikimedia.org/T243095 Braintree https://developer.paypal.com/docs/archive/checkout/how-to/braintree-integration/ List the major tasks required to integrate. - - - Fill out the spreadsheet: https://docs.google.com/spreadsheets/d/1VXzwqtCjn8lJ5WdknafaYkm9Eba5sQJmvm10GFCbOGs/edit#gid=0
  • T271074: Step 2: Investigate Omnipay
    • Task
    • ·Closed
    https://omnipay.thephpleague.com/ What are the high level pros and cons compared to smashpig? If smashpig disappeared tomorrow and we had to use this, what would we have to recreate custom for ourselves? Fill out the spreadsheet: https://docs.google.com/spreadsheets/d/1VXzwqtCjn8lJ5WdknafaYkm9Eba5sQJmvm10GFCbOGs/edit#gid=0
  • T268954: Docker dev setup: Minor improvements and doc following initial feedback
    • Task
    • ·Closed
    Initial feedback showed up some minor gotachs and confusing bits of doc. Here are some quick fixes for that.
  • T268687: Docker dev setup: Set up IPN listeners
    • Task
    • ·Closed
  • T268646: Code review, fix major and minor issues, follow up on new requirements, write tests and release management for CN campaign filtering
    • Task
    • ·Closed
    User preferences UI mockups: https://docs.google.com/presentation/d/1Ocli1ozAlyHPL8YBd2nb5_5fevLXYaFbTLmiC-YZCio/edit#slide=id.gb188dacd48_0_839 I hear there are some patches backing up behind some of the contractor work. The campaign filter features definitely needs to go out but clone campaign could be delayed if needed. https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralNotice/+/604279/ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralNotice/+/607461/ DoD: * Review campaign filter feature * Get patches and feature ready to release in early January. Based on my and @AndyRussG's review of Campaign Filtering, here's what need to be done: - [X] additional review as it's been cursory so far - [X] split out schema into separate patch for deployment - [X] relabel fields in CampaignType manager UI "label message" and "force selection" - [X] rename "Campaign displaying" section header added in user preferences - [X] ~~add link to CampaignType Manager in Campaign Manager~~--there is a link in the upper right corner of the screen - [X] rename db field not_campaign_type to be more clear and consistent ("not_type") - [X] fix tests broken by the first patch - [X] fix tests broken by the second patch - [X] fix styling issues brought up in latest comments from DannyS on campaign filter (would be mostly resolved ✱) - [X] add tests -- we might want more in AllocationTests but for now there's more test coverage - [ ] ask for input from core team about changes to user preferences UI - [X] smoke test some on the Beta Cluster - [X] fix issue: in logs, changes to campaign type results in a blank detailed description of the change - [X] improve functionality around translatable names for campaign types ([[ https://phabricator.wikimedia.org/T268646#6693395 | see ]] [[ https://phabricator.wikimedia.org/T268646#6693463 | these ]] [[ https://phabricator.wikimedia.org/T268646#6697133 | four ]] [[ https://phabricator.wikimedia.org/T268646#6697738 | comments ]])✱ - [X] use null instead of magic number for no campaign type assigned to a campaign - [X] ~~fix use of magic number in CampaignType object to indicate the type is not yet saved to the DB~~ Code removed ✱ - [X] ~~use divs instead of table for add/edit campaign type form layout (optional)~~ Code removed ✱ - [X] ~~use OOUI for add/edit campaign type form (optional)~~ Code removed ✱ - [X] numerous miscelaneous minor code issues (variable and method names, whitespace issues, type hints, inline doc, default parameter values, etc.) (would be partly resolved ✱) - [X] ~~validate and catch duplicate campaign type names (currently you get an unfriendly DB error if you create a new type with the same name)~~ Code removed✱ - [X] ~~don't add an extra DB query to every single pageview that reaches PHP (which includes every pageview for logged-in users)~~ Code removed ✱ - [X] allow control over ordering of campaign types in user preferences and CN Admin UI (optional)✱ ✱ These issues/tasks would be resolved (or partly resolved, where indicated) by following the simplified config-based approach mentioned [[ https://phabricator.wikimedia.org/T268646#6698811 | here ]]. - [X] convert to simplified config-based approach Original RFP/spec that was sent to the contractor: https://docs.google.com/document/d/1HDODIse0zhWAnUtu5Hmd7did6zofYLN9dwAew55g4RA/edit
  • T268511: Consume new messages from Email Preferences form
    • Task
    • ·Closed
    Messages sent to the email preferences queue in T268510 may have a different format from current opt-in / unsubscribe messages. Create a job to pull these messages from the queue, validate them, and update the contact record in CiviCRM.
  • T268510: Create new subpage for Special:EmailPreferences
    • Task
    • ·Closed
    Could be the default when neither opt-in nor opt-out is passed in the parameters. * Create a basic template under email_forms * Add logic to call CiviProxy using helper class from T268497 * Add any missing params for info gained from CiviProxy to EmailForm.php * Add title string to i18n and add new case in setPageTitle * Add logic to validate submission and send message to queue set up in T268512
  • T268497: Use Guzzle to make API request to CiviProxy to retrieve opt-in / opt-out fields.
    • Task
    • ·Closed
    This is to be written in DonationInterface, probably in a helper class to be used by the Special:EmailPreferences page. Guzzle is just so it's mockable - seems to already be installed in MW vendor directory.
  • T267500: Docker dev setup: Set up memcached
    • Task
    • ·Closed
  • T266840: Docker dev setup: Review, update, organize and comment payments-LocalSettings.php
    • Task
    • ·Closed
    The initial version of [[ https://gitlab.com/andyrussg/fundraising-dev/-/blob/master/config/payments-LocalSettings.php | payments-LocalSettings.php ]] (which provides Mediawiki settings for Payments wiki on Docker) is a mishmash from the following sources: - Basic settings generated by Mediawiki's maintenance/install.php script. - [[ https://www.mediawiki.org/wiki/Fundraising_tech/donation_pipeline_setup/settings#Payments-Wiki_LocalSettings.php | Recommended settings ]] available on Mediawiki.org for manual donation pipeline setup. - Logging setup used on production. These settings need to be reviewed and possibly brought up-to-date. Review should include making sure the logging settings work and fulfill requirements for a dev setup. Also, it looks like they could be better organized for readability and more thoroughly commented. The reason this file is in the fundraising-dev repository is to make it easy for FR-Tech to update and maintain settings, and keep then coordinated across development environments. Thanks!!!
  • T266158: Payments on Docker: issue with composer cache directory
    • Task
    • ·Closed
    I'm getting a directory structure like this, inside src/payments: ``` ' var www html cache composer' ``` Then inside that is what looks like composer-related stuff, plus, an .htaccess file.
  • T266090: XDebug on payments on Docker
    • Task
    • ·Closed
    - Add any additional setup needed - Test - Write instructions in README.md
  • T266089: Add SmashPig config for payments wiki on Docker
    • Task
    • ·Closed
  • T266088: Make payments phpunit tests pass under Docker
    • Task
    • ·Closed
  • T262977: Get queues working on docker
    • Task
    • ·Closed
    DoD Get queues working on docker
  • T262976: Get payments wiki working on docker
    • Task
    • ·Closed
    DoD Get Payments wiki working on docker (added later: in a way that's easily reproducible and useful for all FR-Tech developers as an initial part of a Docker-based development environment) some notes: https://etherpad.wikimedia.org/p/fr-tech-docker
  • T262975: Get civi working on docker
    • Task
    • ·Closed
    DoD Get civi working on docker
  • T255810: Banner history logger records incorrect status code following campaign fallback
    • Task
    • ·Closed
    If a campaign that has banner history enabled is fallen back from, and the campaign that is fallen back to shows a banner, the banner history log shows status code 4, 'banner_chosen', rather than status code 6, 'banner_shown'. In addition to fixing this, we should verify behaviour in other fallback scenarios.
  • T255593: Close filehandle in MW API code
    • Task
    • ·Closed
  • T255476: Prepare CN deploy 2020-06
    • Task
    • ·Closed
  • T255170: Add PHP object caching to MW employer data API
    • Task
    • ·Closed
  • T252596: CentralNotice: Deploy new regional geotargeting and banner template features
    • Task
    • ·Closed
    Note: both new features involve schema changes.
  • T250751: Address final code review comments on geotargeting
    • Task
    • ·Closed
    I hear there is some feedback on variable names and other notes. The team should discuss which are actual blockers to deploying the feature and address them.
  • T247885: When a donor whose initial form was in language=NL cancels an iDEAL donation, the resulting error message is in English
    • Task
    • ·Closed
    At this link, fill in name and email and click 'Doorgaan' https://payments.wikimedia.org/index.php?title=Special:AdyenGateway&appeal=JimmyQuote&ffname=adyen&payment_method=rtbt&payment_submethod=rtbt_ideal&recurring=&uselang=nl&language=nl&currency=EUR&amount=1.5&country=NL Then on the iDEAL page click 'terug' at the bottom of the page. The resulting error message (on paymentswiki) is in English when it should be in Dutch.
  • T246863: Adapt DonationInterface to new method signatures and response objects for Adyen and Ingenico
    • Task
    • ·Closed
  • T246825: Normalize approvePayment method signatures and responses for Ingenico and Adyen PaymentProviders
    • Task
    • ·Closed
    This task does not include adapting calling code.
  • T246819: Add IDEAL to adyen front end
    • Task
    • ·Closed
    Adyen supports iDeal recurring via SEPA across all integrations (including the current HPP Wiki uses)payment request: https://docs.adyen.com/classic-integration/recurring-payments/store-payment-details example: https://docs.adyen.com/classic-integration/hosted-payment-pages/payment-request applicable for recurring as well, just need to pass in 'ONECLICK,RECURRING' to recurringContract field: https://docs.adyen.com/classic-integration/hosted-payment-pages/one-click-payments
  • T246461: Prepare CN deploy 2020-03
    • Task
    • ·Closed
    It's been a while since we did a CN deploy and stuff is accumulating!!
  • T242278: Update civi SmashPig extension to be able to charge Adyen recurring
    • Task
    • ·Closed
    There is Ingenico specific code here that needs to be removed that deals with response codes. The work in T243340 will update the SmashPig code to standardize error codes and information returned on success (e.g. payment IDs). This ticket is for the changes that we will need to make in the Civi extension to use those standardized responses.
  • T239967: rework fredge search to include new fields and general debug
    • Task
    • ·Closed
    DoD * Add these fields to the fredge report Evelyn is using in civi: ** IP address ** Country ** Currency code ** Order amount ** “TS” the timestamp in which they first hit payments wiki ( in contribution tracking table ) * also the scrambling of results earlier might be an indication that the report might break at high amounts of donations submitted. If anyone can spend time looking at this, that would be great but we don't have large lists to work with at the moment. Original bug report As part of the daily review of the stopped fraud que, I am pulling all transactions (merchant Reference #'s) stopped at 600 out of Ingenico, sorting Merchant reference #'s, by date, from newest to oldest and submitting them via Civi Fredge to obtain a list of fraud parameters associated with the list I submit. The results I am getting are oddly starting to be randomly scrambled as of 12.2....Coincident to the issue I raised in Phab task https://phabricator.wikimedia.org/T239769 (not sure if it is related at all) which sees erroneous transactions stopped at 600. Please refer to the 600 trx stopped in this spreadsheet : https://docs.google.com/spreadsheets/d/1z8sOMtfgrlb5P0JNKTj_Fq6ba4UCgBo-9EqsLU9yFls/edit#gid=503946220. I've tried to highlight the MR #'s in red that are randomly scrambled. This has not been the case for the last 4 months since I've been driving this process. Is there some reason the Civi query is scrambling the result? The Fredge results are key to decisioning on manually settling transactions or not and the search results appearing out of order protract the time it takes to conduct the review, which is already a high overhead process. Thanks!
  • T236627: CentralNotice: Adapt impression event schema for campaign fallback
    • Task
    • ·Closed
    We need to add the new campaignStatuses property, which records what happened with campaigns that were fallen back from.
  • T235284: FRUEC: Debug large discrepancy in data in initial test run.
    • Task
    • ·Closed
    A test run of FRUEC using only data on 2019-09-20 showed a large discrepancy for Landing Page events and Banner Impressions between legacy and testing databases: ``` MariaDB [(none)]> select count(*) from pgehres.landingpageimpression_raw where timestamp >= '2019-09-20 20:00:00' and timestamp < '2019-09-20 22:00:00'; +----------+ | count(*) | +----------+ | 2401 | +----------+ 1 row in set (0.00 sec) MariaDB [(none)]> select count(*) from fruec.landingpageimpression_raw where timestamp >= '2019-09-20 20:00:00' and timestamp < '2019-09-20 22:00:00'; +----------+ | count(*) | +----------+ | 1076 | +----------+ 1 row in set (0.01 sec) ``` ``` MariaDB [(none)]> select sum(count) from pgehres.bannerimpressions where timestamp >= '2019-09-20 20:00:00' and timestamp < '2019-09-20 22:00:00'; +------------+ | sum(count) | +------------+ | 720530 | +------------+ 1 row in set (0.03 sec) MariaDB [(none)]> select sum(count) from fruec.bannerimpressions where timestamp >= '2019-09-20 20:00:00' and timestamp < '2019-09-20 22:00:00'; +------------+ | sum(count) | +------------+ | 255530 | +------------+ 1 row in set (0.02 sec) ``` Both systems ingressed the same number of files for the period compared in the above queries: ``` MariaDB [(none)]> select count(*) from pgehres.squidlog where timestamp >= '2019-09-20 20:00:00' and timestamp < '2019-09-20 22:15:01'; +----------+ | count(*) | +----------+ | 18 | +----------+ 1 row in set (0.34 sec) MariaDB [(none)]> select count(*) from fruec.files where timestamp >= '2019-09-20 20:00:00' and timestamp < '2019-09-20 22:15:01'; +----------+ | count(*) | +----------+ | 18 | +----------+ 1 row in set (0.00 sec) ```
  • T234737: FRUEC: Allow multiple files to contribute to aggregate bannerimpressions cells
    • Task
    • ·Closed
    As currently implemented, FRUEC assumes that log files will contain exclusively events with timestamps within the 15-minute period corresponding to the timestamp in the filename. However, there can be overlap in timestamps for events from multiple files. This means that for the aggregate data in the bannerimpressions table, it is not possible to always link each aggregate cells to a single file. Removing that link would break FRUEC's system for purging events from specific files. It should be possible to fix this by changing the DB schema, creating link tables between files and aggregate bannerimpressions cells, and storing in the link tables the total impression counts aggregated from a given file for each cell. Spun out from T234352.
  • T234352: FRUEC: Fixes following contact with real data
    • Task
    • ·Closed
    Two issues so far: - DEBUG Invalid language code: zh-tw (cn_event.py line 44) - ~~mysql.connector.errors.IntegrityError: 1062 (23000): Duplicate entry '2019-09-20 18:00:00-wlm2019_version2-wlm 2019-5-5-3' for key 'timestamp'~~ Spun out as T234737
  • T233538: CentralNotice needs 'editToken' replaced with 'csrfToken'
    • Task
    • ·Closed
    CentralNotice needs 'editToken' replaced with 'csrfToken' in resources/infrastructure/bannereditor.js and resources/infrastructure/ext.centralNotice.adminUi.campaignPager.js per [[ https://codesearch.wmflabs.org/search/?q=%5B%27%22%5DeditToken%5B%27%22%5D&i=nope&files=&repos= | "everything" code search]].
  • T233145: Turn on EventLogging from Donate Wiki at 100%
    • Task
    • ·Closed
    Current sample rate is set at 1% via $wgFundraiserLandingPageELSampleRate. However, legacy recording of landing page hits is unsampled.
  • T232968: Create FRUEC process-control job
    • Task
    • ·Closed
  • T232235: Improve state component's munging of new data added for Campaign Fallback
    • Task
    • ·Closed
    For discussion, please see comments on the [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralNotice/+/517931 | Fallback Gerrit change ]].
  • T231406: Landing page event logging events have -1 as schema revision number.
    • Task
    • ·Closed
    It seems likely this is due to incorrect formatting in extension.json, introduced here: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FundraiserLandingPage/+/508906 Seen on the eventlogging_EventError kafka stream: ``` {"event": {"code": "validation", "message": "Invalid revision ID -1", "rawEvent": "{\"dt\": \"2019-08-28T05:41:03Z\", \"event\": {\"country\": \"MX\", \"landingpage\": \"Special:LandingPage\", \"language\": \"en\", \"sample_rate\": 1, \"utm_campaign\": \"spontaneous\", \"utm_medium\": \"spontaneous\", \"utm_source\": \"fr-redir\"}, \"ip\": \"bla.bla.bla.bla\", \"recvFrom\": \"cp2004.codfw.wmnet\", \"revision\": -1, \"schema\": \"LandingPageImpression\", \"seqId\": 4427763, \"userAgent\": {\"browser_family\": \"Chrome\", \"browser_major\": \"70\", \"browser_minor\": \"0\", \"device_family\": \"Other\", \"is_bot\": false, \"is_mediawiki\": false, \"os_family\": \"Linux\", \"os_major\": null, \"os_minor\": null, \"wmf_app_version\": \"-\"}, \"uuid\": \"e7c2c4208391533a8276e867a8b727f2\", \"webHost\": \"donate.wikimedia.org\", \"wiki\": \"donatewiki\"}", "revision": -1, "schema": "LandingPageImpression"}, "recvFrom": "eventlog1002.eqiad.wmnet", "revision": 14035058, "schema": "EventError", "timestamp": 1566970865, "uuid": "6d641e3cc95611e987621418775b0d42", "wiki": ""} ```
  • T231404: Client-side event impression event logging is broken
    • Task
    • ·Closed
    This is due to an outdated check of mw.config.get( 'wgEventLoggingBaseUri' ) to see if the EventLogging extension is enabled. Along the way, we should complete the update of the use of EventLogging in the CN display module, as per T214709. ([[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/EventLogging/+/508903 | Here ]]'s the change removing access to that config.)
  • T229194: PHPUnit tests failing with "Cannot write with role DB_REPLICA"
    • Task
    • ·Closed
  • T227879: Bug: Qunit tests should not be ignored
    • Task
    • ·Closed
    It looks like some Qunit tests are not being executed anymore as a result of changes to resource modules list introduced in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralNotice/+/512429 , specifically - the `onResourceLoaderTestModules` at `CentralNoticeHooks.php:409` when searching for test files implies that module has a `scripts` property but with newly added `packageFiles` replacement this is not true anymore for `ext.centralNotice.display` and hence `tests/qunit/subscribing/ext.centralNotice.display.tests.js` and `tests/qunit/subscribing/ext.centralNotice.display.chooser.tests.js` are not being included into Qunit tests list, which could lead to false positive CI status.
  • T226967: CentralNotice: Error handling for banner preview background calls
    • Task
    • ·Closed
  • T226655: CentralNotice: Review incoming patches 2019-06 and 2019-07
    • Task
    • ·Closed
    - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/509575/ Merged - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/518951/ - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/485514/ Merged - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/EventBus/+/514701/ Merged
  • T226552: Andy: estimate old tasks
    • Task
    • ·Closed
    Please just take 1 hour and see how many of your tasks you can estimate: https://docs.google.com/spreadsheets/d/1tVOTDvTKgUcUoQspEnpoNrDnTAkNcs1IRxBEK-m2pnQ/edit#gid=0
  • T226344: Review Campaign Fallback
    • Task
    • ·Closed
    https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/517931/ DoD: handle the multiple rounds of code review and feedback
  • T225688: CentralNotice tests failing due to deprecated ResourceLoader constructor
    • Task
    • ·Closed
    Form https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-hhvm-docker/53779/console: Use of ResourceLoader::__construct without a Config instance was deprecated in MediaWiki 1.34. [Called from CNChoiceDataResourceLoaderModuleTest::testChoicesFromDb in /workspace/src/extensions/CentralNotice/tests/phpunit/CNChoiceDataResourceLoaderModuleTest.php at line 46]
  • T225101: CentralNotice banner preview: follow-up improvements
    • Task
    • ·Closed
    Details and fixes for banner preview features (live and on-wiki). https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/497611/ https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/508720/ Please see comments for details.
  • T224733: investigate recent divot in landingpage log activity
    • Task
    • ·Closed
    We're getting alerts from monitoring of kafkatee's landingpages log rotation, for zero activity for >2H (warning) or >4H critical. Centralnotice logs are active during these times. Is it just that we have no fundraising campaigns up? Or is there a change to the traffic pattern we need to account for in monitoring?
  • T224444: CentralNotice: Deploy accumulated changes (2019-05-27)
    • Task
    • ·Closed
    - [X] Verify everything works locally on the beta cluster and locally for master branch HEAD. - [X] Look over any changes that might have been merged since last deploy attempt. - [X] Revert the reversion of the merge patch on wmf_deploy branch . - [X] Merge master into wmf_deploy to add new changes. - [X] Verify that everything works locally for new wmf_deploy HEAD. - [X] +2 wmf_deploy changes in Gerrit. - [X] Check everything works on production right after train deploys: - [X] Tuesday (group0) - [X] Wednesday (group1) - [X] Thursday (group2)
  • T224034: CentralNotice: Remove bannerController RL modules
    • Task
    • ·Closed
    `ext.centralNotice.bannerController` and `ext.centralNotice.bannerController.mobile` are old, empty RL modules that were never removed from CentralNotice. Get rid of them to help clean up the RL module manifest.
  • T222658: review live banner preview code
    • Task
    • ·Closed
    Please take notes here and in gerrit.
  • T222463: CentralNotice: Review incoming patches 2019-05
    • Task
    • ·Closed
    - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/506232/ Merged (Audiences team) - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/506317/ Merged (Audiences team) - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/502772/ Merged (Audiences team) - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/497644/ Merged (Audiences team) - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/506044/ Merged (Performance team) - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/510584/ Merged - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/510585/ Merged - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/512429/ Merged - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/512430/ Merged
  • T219214: Review live banner preview
    • Task
    • ·Closed
    https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/497611/
  • T215086: Add null banner preview to CentralNotice for performance testing baseline
    • Task
    • ·Closed
    This will prevent confusing spikes in graphs monitoring performance data.
  • T214410: Investigate impact and protection from errors in banners JS
    • Task
    • ·Closed
    It looks like catching errors from injected script tags may be possible. See: https://stackoverflow.com/a/51857110/1165940 https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror Would this prevent an error in JS in a banner from halting JS execution on the whole pageview? What is the current situation? That is, how do errors in banner JS currently impact on the site, on mobile and desktop? See T214330 for a recent issue of this sort.
  • T213978: Deprecation warning from CentralNotice: OutputPage::parseInline
    • Task
    • ·Closed
    We have two major versions of MediaWiki in which to clean this up, I believe? > Use of OutputPage::parseInline was deprecated in MediaWiki 1.33. [Called from SpecialCentralNoticeBanners::generateBannerEditForm in /X/mediawiki-extensions/CentralNotice/special/SpecialCentralNoticeBanners.php at line 546] in /X/mediawiki-core/includes/debug/MWDebug.php on line 309
  • T213915: wmf_deploy updated but not merged and deployed into .12
    • Task
    • ·Closed
    https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralNotice/+/484352/-1..2 was merged to bump CN in .13, but it wasn't deployed to .12, leaving .12 in an inconsistent state This task acts as three things: 1) A reminder that wmf_deploy affects multiple branches 2) Please remember to deploy your changes to all active branches, even if you intend for it to just ride the train on the latest release, you still need to deploy it for any active older releases :) 3) Please deploy the change above properly into .12 to fix the below ``` modified: extensions/CentralNotice (new commits) ```
  • T208004: Call to undefined method LanguageEn::truncate()
    • Task
    • ·Closed
    === Error === Request ID: `INSERT_ID` ```name=message Fatal error: Call to undefined method LanguageEn::truncate() in /srv/mediawiki/php-1.33.0-wmf.1/extensions/CentralNotice/special/SpecialCentralNotice.php on line 1543 ``` ```name=trace,lines=10 n/a ``` === Impact === Fatal errors in production === Notes ===
  • T203925: Save times for changes to translation variable text in centralnotice paralysingly slow
    • Task
    • ·Closed
    On average it is taking 3.5-4 minutes to make a 1 character change to the text in translation variables within CentralNotice. It has just taken me nearly and hour and a half to systematically create 8 variables and copy and paste some text into them. Making a change triggers a server error after waiting ~2 minutes upon which you have to reload the page which then takes another 2 minutes. For comparison, to make a change without using Translate Extension, it takes ~15 seconds.
  • T203499: Update EventLogging schema for CentralNotice
    • Task
    • ·Closed
    Changes required: - Add testing field for banner previews. - Make campaign field optional (for banner previews). As well as changing the actual schema, we'll update the client-side code to add the new field, and update the schema version number.
  • T203020: Turn off LandingPage events from testwiki
    • Task
    • ·Closed
  • T200449: Create job to deliver the eventlogging_LandingPageImpression topic
    • Task
    • ·Closed
    Events from the [[ https://meta.wikimedia.org/wiki/Schema:LandingPageImpression | LandingPageImpression EventLogging schema ]] should be written to rotating log files. Similar to logs for the eventlogging_CentralNoticeImpression topic, except not sampled. See also T189820... Thanks much!!!!!!!
  • T196564: DB schemas (production changes and test DB) and SQL commands to run for new banner and LP impression data from EL
    • Task
    • ·Closed
    Here's what we need: 1) Specify what (if any) new columns and tables may be needed in pgehres, and make the changes 2) Create a database for ingressing test data during an initial testing phase 3) Ensure a seamless switchover from the current pipeline to the new data from EventLogging Let's plan here the exact SQL commands to run and plan exactly how and when to run them. Requirements: - No data loss or corruption due to switchover. - Existing tools used on the production database should work without changes. Thanks!!!
  • T195908: FundraiserLandingPage: Parse EL sample rate URL param as number
    • Task
    • ·Closed
    This is the same issue we had with the impresion EventLogging feature in CentralNotice: we need to parse the URL parameter as a number, otherwise it is sent as a string in the EventLogging event, which does not conform to the event schema.
  • T195594: New scripts to ingress data from Kafkatee into MySQL
    • Task
    • ·Closed
    As per T192839, for sampled impression and landing page data we won't ingress data directly from the Kafka topic in to the database, but rather will write files from the stream and will read those, as in the legacy system. However, the format of the new files is pretty different from the old ones. Also, the [[ https://github.com/wikimedia/wikimedia-fundraising-tools-DjangoBannerStats | legacy python scripts ]] that processed data in the old format are pretty crufty. So, instead of writing new code to re-create the legacy format and feed it to the crufty legacy scripts, we'll re-do the legacy scripts to read the new format. This should make the system more maintainable and stable, so it's definitely within scope for this switchover. We may wish to make some minor changes in the database schema, but we should ensure that queries currently used will continue to work. Thanks!!
  • T195276: CentralNotice: Some URL params break EventLogging impression schema
    • Task
    • ·Closed
    CentralNotice allows overriding the following with URL parameters: - `randomcampaign` - `randombanner` - `recordImpressionSampleRate` - `impressionEventSampleRate` All of these should be stored as numbers in `mw.centralnotice.data`. However, when they're set via URL parameters, they're stored as strings. This produces invalid EventLogging impression events, since the [[ https://meta.wikimedia.org/wiki/Schema:CentralNoticeImpression | schema ]] has them as numbers.
  • T185933: Donatewiki: use EventLogging to log pageloads
    • Task
    • ·Closed
    Create schema for landing page views Add EventLogging call to FundraiserLandingPage
  • T185932: CentralNotice: use EventLogging instead of custom beacon
    • Task
    • ·Closed
    Part of the KafkaTee pipeline replacement Need to define a schema and update the CN subscribing wiki client-side code Could add the EventLogging and have both up for a bit to compare numbers.
  • T185816: CentralNotice: Prevent autofill of multiple selection fields by browsers
    • Task
    • ·Closed
    Multiselect fields are sometimes autofilled by the browser, making it seem that a given configuration state has been saved, when in fact it hasn't.
1
2
Next
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL