Page MenuHomePhabricator

Non standard calandar model breaks JS UI
Closed, ResolvedPublic


on I added a qualifier to a claim by API-function wbsetqualifier


Something goes wrong. Now you can't neither add new properties to item nor modify or delete this property in Frontend, see

Event Timeline

Balu created this task.Feb 17 2015, 7:52 AM
Balu raised the priority of this task from to Needs Triage.
Balu updated the task description. (Show Details)
Balu added a subscriber: Balu.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 17 2015, 7:52 AM
Lydia_Pintscher triaged this task as Unbreak Now! priority.Feb 17 2015, 8:19 AM
Lydia_Pintscher added a project: Wikidata.
Lydia_Pintscher added a subscriber: Lydia_Pintscher.

Set to unbreak now for investigation to see how bad this is.

hoo added a comment.Feb 17 2015, 8:56 AM

Ok, this is worse than I initially thought... the problem here is the calendar model URL used, it should be /entity/ not /wiki/. But the actual root problem is that we don't validate these URLs AT ALL.

hoo added a comment.Feb 17 2015, 9:02 AM

Example: ("calendarmodel":"")

I tried but can't reproduce it.

What exactly does "something goes wrong" mean? There is really, really not enough information given to do anything for you, @Balu. Sorry to say that.

Balu added a comment.EditedFeb 17 2015, 9:13 AM

@thiemowmde: it means, that with sending the above string to api.php the frontend isn't usabele anymore. I can't say more. I am only observing this effect. What can I tell more?

@hoo: this URL is documented here: Is this docu wrong?

: oh no, sorry, I've copied this wrong. I now see the error. Thx.

I think the current behavior is not too bad. The Wikibase JavaScript code found some value it cannot allow you to edit because the UI is not able to represent the current state. What's broken about this is that the UI is not able to handle non-standard calendar models, but that's more of a feature request than a bug. We might also think about how to make the JS code more fail-safe, so that at least the remainder of it is executed when it encounters such an error, but I find that to be a minor problem.

This is just the kind of issue you get when your data model and API support more than your UI does. In that case, crashing is a much better choice of action than for example silently dropping or overwriting the non-supported value.

I agree that is stupid (it causes data loss) and closed it. I wish we could:

  1. Catch exceptions somehow so the UI doesn't "crash" completely. Only the problematic statement should be non-editable. See @Snaterlicious comment at
  2. Enhance the UI, similar to what we call "special" coordinate precisions, as suggested in the discussion at Unknown calendar models should be displayed in the dropdown as they are. The user can either keep the "special" calendar model (no data loss) or change it to one of the known calendar models.
Tobi_WMDE_SW renamed this task from API function wbsetqualifier blocks frontend to Non standard calandar model breaks JS UI.Mar 11 2015, 12:50 PM
Tobi_WMDE_SW lowered the priority of this task from Unbreak Now! to High.
Tobi_WMDE_SW removed thiemowmde as the assignee of this task.Mar 24 2015, 1:22 PM
Tobi_WMDE_SW lowered the priority of this task from High to Normal.
Lydia_Pintscher closed this task as Resolved.Apr 14 2015, 10:23 AM
Lydia_Pintscher claimed this task.

Will open a new ticket to add option to selector.