Last modified: 2014-02-12 23:45:39 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 T58833, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 56833 - 3rd party wiki's with $wgMFAnonymousEditing enabled are not allowed to edit
3rd party wiki's with $wgMFAnonymousEditing enabled are not allowed to edit
Status: RESOLVED INVALID
Product: MobileFrontend
Classification: Unclassified
Feature requests (Other open bugs)
unspecified
All All
: Unprioritized enhancement
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-09 08:28 UTC by Kunal Mehta (Legoktm)
Modified: 2014-02-12 23:45 UTC (History)
10 users (show)

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


Attachments

Description Kunal Mehta (Legoktm) 2013-11-09 08:28:56 UTC
Anons don't have edit counts or even a username.

Patch incoming.
Comment 1 Bingle 2013-11-09 08:29:20 UTC
Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1386
Comment 2 Gerrit Notification Bot 2013-11-09 08:30:42 UTC
Change 94487 had a related patch set uploaded by Legoktm:
Make MobileWebEditing logging code support anons

https://gerrit.wikimedia.org/r/94487
Comment 3 Bingle 2013-11-09 08:35:23 UTC
Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1387
Comment 4 Jon 2013-11-09 20:17:50 UTC
I'm confused. you can't edit anonymously so why would this work.
Comment 5 Kunal Mehta (Legoktm) 2013-11-09 22:41:16 UTC
If you set $wgMFAnonymousEditing = true, anonymous users should be able to edit.
Comment 6 Jon 2013-11-09 23:02:05 UTC
yes.. but this is never set and only there for 3rd party wikis... the point of event logging is to track editing on wikimedia projects not 3rd party installs...
Comment 7 Kunal Mehta (Legoktm) 2013-11-09 23:10:27 UTC
I don't understand your objection to this bug.

There's an issue preventing $wgMFAnonymousEditing from working properly if EventLogging is installed. It's a simple 5 line fix that I've already submitted.

The eventual goal is to fix bug 53069 so anonymous editing will be enabled for WMF sites per [[m:Founding principles]]. This is a clear blocker since WMF sites do run EventLogging.

This is a bug, not an enhancement request because anonymous users cannot save pages due to EL throwing an error.
Comment 8 Jon 2013-11-09 23:15:28 UTC
Well then the bug should be "3rd party wiki's with $wgMFAnonymousEditing enabled are not allowed to edit".

I thought you were requesting the enabling of EventLogging for anonymous users. Whether this is desired is /not/ clear and is definitely an enhancement request.

A better solution would be not to fire an event at all...
Comment 9 Kunal Mehta (Legoktm) 2013-11-09 23:25:13 UTC
(In reply to comment #8)
> Well then the bug should be "3rd party wiki's with $wgMFAnonymousEditing
> enabled are not allowed to edit".

Uh, no. That's not the issue.

The issue is that if $wgMFAnonymousEditing is enabled, and EventLogging is installed, it tries to log with a username of null and a null editcount, which EL rejects since the type is wrong, and prevents the user from editing.

My initial bug report was skimpy, and that's my fault. 

> I thought you were requesting the enabling of EventLogging for anonymous
> users.
> Whether this is desired is /not/ clear and is definitely an enhancement
> request.

The current code already attempts to log events for anonymous editing.

The first solution I came up with was to just not log those fields, so anonymous edits are still logged, just without a username and edit count.

> A better solution would be not to fire an event at all...

Disabling logging of anonymous edits would also fix this bug, but it seems a lot more heavy handed then my solution of logging some of the data.
Comment 10 Jon 2013-11-10 18:49:57 UTC
To be clear an EventLogging validation error doesn't stop the edit itself...
Comment 11 Jon 2013-11-12 18:19:16 UTC
After reading this some more I'm now even more convinced this is not a 'bug'. With $wgMFAnonymousEditing enabled and EventLogging installed, the edit will still go through (thanks to your other patch) however will log a validation error against the schema (which is not a big deal)

The user is not prevented from editing at all.

When enabling anonymous editing we should definitely re-think logging - whether we do it or not and what we need to log in those situations (we may need to add a field anonymous editor for example) - but doing so now seems overly premature and I would expect it to be done as part of that development. If you feel a bug for this is important please open a new bug to avoid more confusion in this one.
Comment 12 Gerrit Notification Bot 2013-11-12 18:29:19 UTC
Change 94487 abandoned by Legoktm:
Make MobileWebEditing logging code support anons

Reason:
AFAIK, there is no 'required': true set for those fields in the Schema, so it should log properly.

Regardless, abandoning per bug.

https://gerrit.wikimedia.org/r/94487
Comment 13 Kunal Mehta (Legoktm) 2013-11-12 18:31:26 UTC
(In reply to comment #11)
> After reading this some more I'm now even more convinced this is not a 'bug'.
> With $wgMFAnonymousEditing enabled and EventLogging installed, the edit will
> still go through (thanks to your other patch) however will log a validation
> error against the schema (which is not a big deal)

Right, I realized that I was working on two separate branches so the error I thought I saw here was actually the other bug.

> When enabling anonymous editing we should definitely re-think logging -
> whether
> we do it or not and what we need to log in those situations (we may need to
> add
> a field anonymous editor for example) - but doing so now seems overly
> premature
> and I would expect it to be done as part of that development.

Agreed. Thanks for discussing.
Comment 14 Jon 2013-11-13 02:31:34 UTC
And thanks for poking at the code and highlighting these problems. Very much appreciated (I know that can sometimes be lost in text based communications!)

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


Navigation
Links