Last modified: 2014-09-08 11:17:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T62808, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 60808 - Flow: API actions succeed on Flow-enabled page
Flow: API actions succeed on Flow-enabled page
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Flow (Other open bugs)
master
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: easy
: 60861 (view as bug list)
Depends on: 69322
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-04 03:04 UTC by spage
Modified: 2014-09-08 11:17 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description spage 2014-02-04 03:04:29 UTC
I used Special:ApiSandbox to submit an edit in which I appended text to ee-flow's Talk:Sandbox, a page that is Flow-enabled. The edit succeeded (revision 4649), but when I went to the page it's still a Flow board and so Flow items are shown instead of the "page text".  Looking at http://ee-flow.wmflabs.org/wiki/Special:Export for Talk:Sandbox, you can see the new text  "Test addition with API to Flow-enabled page" in revision 4649, but when I viewed the Flow board Flow immediately created a new revision 4650 with text changed back to the default <flow-talk-taken-over> message. I tried it again and the same thing happened (revisions 4651 then 4652).

Flow blocks most URL page actions on Flow-enabled pages; I don't know if it should block or fail API actions as well. The reset of page content back to <flow-talk-taken-over> is by design (read TalkpageManager->ensureFlowRevision) and users won't see any of this content anyway until Flow is disabled on the page. So bots could make edits to Flow-enabled pages that will never be seen and are constantly reset.

Clearly we need some way for API clients to tell if a page is Flow-enabled (legoktm comments "probably easiest if we just stick it in the page_props table", but for bot writers who don't update code to check this, what's the right behavior?
Comment 1 Brad Jorsch 2014-02-04 15:15:13 UTC
In the situation as described, yes, the API edit should be failed via the appropriate hooks.

You should probably use both APIEditBeforeSave and PageContentSave, the former to give a useful error message to API clients and the latter to catch any other code paths (e.g. Extension:TranslationNotifications) that might try to write to a page.
Comment 2 Alex Z. 2014-02-05 02:30:24 UTC
It would be really nice to have some sort of graceful fallback for some things.

Could action=edit&section=new create a new topic?

It wouldn't really be unexpected behavior, and just that would take care of the majority of bots that edit talk pages (assuming they're using that and not creating the section themselves).

https://www.mediawiki.org/wiki/Talk:Flow/Architecture/API#enwiki_bots_that_edit_talk_pages
Comment 3 Kunal Mehta (Legoktm) 2014-02-05 03:08:09 UTC
(In reply to comment #2)
> It would be really nice to have some sort of graceful fallback for some
> things.
> 
> Could action=edit&section=new create a new topic?

That's bug 57989 :)
Comment 4 Kunal Mehta (Legoktm) 2014-02-05 05:31:32 UTC
*** Bug 60861 has been marked as a duplicate of this bug. ***
Comment 5 Jon 2014-09-08 11:17:28 UTC
This still seems to be a problem. When I attempt this via the API it still reports success.

{
    "edit": {
        "result": "Success",
        "pageid": 13955,
        "title": "Talk:Flow QA",
        "contentmodel": "flow-board",
        "oldrevid": 110241,
        "newrevid": 127251,
        "newtimestamp": "2014-09-08T11:16:06Z"
    }
}

It doesn't seem to cause much damage though so updating with enhancement request and easy tag since should be a good volunteer task to work on.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links