Page MenuHomePhabricator

Unable to publish depicts changes after clicking "mark as prominent" when no other values are modified
Closed, ResolvedPublicBUG REPORT

Description

Noticed this for the first time this afternoon. I'm running master at b2e8e968cf0fc2f56a72594e69af8f6a84d02469 in MW-Docker-Dev locally. Curious if anyone else can see this problem.

Steps to Reproduce:

  1. Navigate to the File page of an image with multiple Depicts statements, one of which is not currently listed as prominent. Here's what my page looks like at this point:

Screen Shot 2019-04-05 at 12.54.25 PM.png (1×1 px, 1 MB)

  1. Click mark as prominent on the non-prominent statement. Do not change any other values.

Actual Results:
The Depicts Panel toggles into Edit mode but the "publish changes" button is disabled, as if the user has toggled the panel but not yet made any changes. It seems like the promotion of the statement to "prominent" is not getting picked up as a change.

Screenshot (note that both statements are now correctly labeled as prominent):

Screen Shot 2019-04-05 at 12.54.44 PM.png (1×1 px, 1 MB)

Expected Results:

The "publish changes" button should be active and click-able, and the user should be to submit their edit successfully even if no other values have changed.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
This comment was removed by egardner.

Ok, after a little more digging, here is what I think is going on:

Currently, the DepictsPanel has a method called hasChanges, which other methods of this object call in order to determine whether things have changed. This is used to determine whether to enable or disable that "publish" button for the user. A "change" here can mean both new data input in to a text field, but also the promotion/demotion of statements to a "prominent" state.

Here's the catch: this patch added a property called isEditable to the DepictsPanel object – a simple true or false value that says whether the panel is editable or not. The hasChanges method will bail out early if isEditable is set to false (in order to avoid some other potential errors).

So if the user is viewing the DepictsPanel in "read-only" state (meaning isEditable is false), and they click "make prominent" on a statement, the hasChanges method looks like it gets called before the panel gets switched over into editable state. This means that the change is not correctly detected, and the "publish" button does not get enabled properly (even though the panel does eventually get set to the edit state).

Ramsey-WMF moved this task from Untriaged to Triaged on the Multimedia board.
Ramsey-WMF added subscribers: Cparle, matthiasmullie.

Change 501819 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Remove guard clause from DepictsPanel.hasChanges()

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

@Cparle and @matthiasmullie this might be a big issue we need to address quickly. On Monday, can you prioritize reviewing Eric's patch (which, as Eric mentions, probably needs a bit of work still)?

Change 501856 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/extensions/WikibaseMediaInfo@master] Separate isEditable from hasChanges

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

Change 501819 abandoned by Eric Gardner:
Remove guard clause from DepictsPanel.hasChanges()

Reason:
Abandoning in favor of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/ /501856

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

Change 501856 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Separate isEditable from hasChanges

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

Change 502213 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/extensions/WikibaseMediaInfo@master] Fix isEditable property/method collision

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

Change 502213 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Fix isEditable property/method collision

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

This feature seems to be working correctly on both Beta and Test commons; moving to "Verify on Production".