Page MenuHomePhabricator

Instrument eventlogging for description editing
Closed, ResolvedPublic2 Estimated Story Points

Description

Add events to the existing MobileWikiAppEdit schema at least for the following four steps:

  • The editor is launched, either (in case the article already has a Wikidata description) selected from the "Edit title description" / "edit introduction" popup menu , or by tapping on the "Add short description link" if the article does not have a description: use the existing startaction
  • The editor is ready (cursor blinking): add a new readyaction
  • The save button is tapped: use the existing saveAttempt action
  • The edit is saved successfully: use the existing savedaction

Also, all these should indicate whether a new description is being added or an existing description is being updated, via a new WikidataDescriptionEdit field with values new and existing, and required = false.

Once there is a path from the editing screen to logging in (T154785) /creating an account, we should also augment the source field in the MobileWikiAppLogin and MobileWikiAppCreateAccount schemas with an WikidataDescriptionEdit value.

Event Timeline

That userId field looks like it could come out of the schema.

Change 333993 had a related patch set uploaded (by Mholloway):
Instrument EventLogging for description editing

https://gerrit.wikimedia.org/r/333993

agreed- it would also allow us to track over time because we wouldn't have
to do a 90 day rolling cleanup

That userId field looks like it could come out of the schema.

Come out of the schema in what sense? (This is the public, permanent MediaWiki user ID attached to each edit.)

@Dbrant, @Tbayer: Here's the updated schema. Please confirm if it looks good.

https://meta.wikimedia.org/wiki/Schema:MobileWikiAppEdit

This edit looks great to me. (I may still augment the description of the actions with text from the task description, e.g. because "ready" may appear a bit ambiguous later.)

Come out as in be removed. Is it of analytic value?

@Dbrant mentioned one possible application of the userId field on IRC, but there's another issue here: user ids vary by wiki. For instance, 'MHolloway (WMF)' is user 2371822 on mediawiki.org, user 338049 on huwiki, and user 24531888 on enwiki. What we would be* logging in the app, at this point, would be the user's id on whatever wiki corresponds to the language state of the app whenever he or she logged in or created an account, regardless of which wiki the user happens to be editing.

The only way to remedy this would be to make an API call to update the numeric user ID every time the app's language state changes.

*Currently, we're logging -1 in all cases, because numeric user ID handling in the app has been broken since the switch to AuthManager (if not earlier). (I didn't realize this when I first brought this stuff up yesterday.) AuthManager doesn't return the numeric user ID on login or account creation, so I've been working this afternoon on adding extra API calls to augment the user information.

Change 334371 had a related patch set uploaded (by Mholloway):
Get user ID after logging in or creating an account

https://gerrit.wikimedia.org/r/334371

The only way to remedy this would be to make an API call to update the numeric user ID every time the app's language state changes.

This doesn't work as I'd hoped it would. The cookie provided by the API for the login session after login or account creation only relates to that specific site. I haven't yet looked into what extra magic is happening on the web to effect multi-site login sessions.

@Dbrant @Tbayer Does it suffice to just log the user ID for the site the user is logged into? I would expect that in most cases this will be the same site as the user is editing.

Alternatively, we could update the User object to remember the specific login site, and send no ID if the login site doesn't match the site being edited.

Can we find out how the iOS app solves this? I just used it (version 5.3.2) to make edits on dewiki and enwiki, which were correctly logged in the schema with my local user ID in each case (7564 on dewiki, 35184 on enwiki).

Change 334720 had a related patch set uploaded (by Mholloway):
Update user ID handling for current functionality

https://gerrit.wikimedia.org/r/334720

Change 334371 abandoned by Mholloway:
Get user ID after logging in or creating an account

Reason:
Superseded by Iffcbb69dfb5acd73333a52cd49a7b8884784b424

https://gerrit.wikimedia.org/r/334371

With the latest iteration, per-wiki user ID is being reported correctly in all cases. I think my problems yesterday were because of a bug in my code after all, but I think the iOS app has a better approach in any case (in which it requests the numeric user ID as needed rather than storing it), so the new patch works along the same lines.

Change 334371 restored by Mholloway:
Get user ID after logging in or creating an account

https://gerrit.wikimedia.org/r/334371

Change 334720 abandoned by Mholloway:
Update user ID handling for current functionality

Reason:
Getting the user ID lazily is probably the wrong way to go (at least on our platform) since we don't want to introduce potential roadblocks to editing while the user waits on a slow connection for a user ID retrieval call to return.

Restored the old approach of maintaining the user ID and updating as necessary (i.e., on login, account creation, and language change) throughout the application lifecycle.

https://gerrit.wikimedia.org/r/334720

Change 334371 merged by jenkins-bot:
Get user ID after logging in or creating an account

https://gerrit.wikimedia.org/r/334371

Change 333993 merged by jenkins-bot:
Instrument EventLogging for description editing

https://gerrit.wikimedia.org/r/333993

Once there is a path from the editing screen to logging in (T154785) /creating an account, we should also augment the source field in the MobileWikiAppLogin and MobileWikiAppCreateAccount schemas with an WikidataDescriptionEdit value.

Created T157080 and T157081 to track this work.