https://bugzilla.wikimedia.org/show_bug.cgi?id=60808
Web browser: ---
Bug ID: 60808
Summary: Flow: API actions succeed on Flow-enabled page
Product: MediaWiki extensions
Version: master
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: Flow
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected],
[email protected], [email protected],
[email protected]
Classification: Unclassified
Mobile Platform: ---
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?
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
