Bugs item #3532712, was opened at 2012-06-07 03:05
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3532712&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: interwiki
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Askar Safin (safinaskar)
Assigned to: Nobody/Anonymous (nobody)
Summary: It is not easy to delete interwiki
Initial Comment:
I think PyWikipedia Interwiki Bot works with interwikies badly. If someone deletes interwiki, the bot adds it back (but it is not right behavior). See more details on http://en.wikipedia.org/wiki/User_talk:Avicennasis/MainArchive/2012Q2#Your_… .
P. S. I don't use the bot, so I cannot include output of "python version.py"
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2012-06-10 08:26
Message:
1. When one user added a link to a interwiki graph and another removed it.
Which human editor did right? What are the rules for a bot to decide it?
2. We expect WikiData coming in few months
3. There are other solutions to solve the problem very easy unlike changing
it's behavior, three of them I've listed above with my last comment. Here
are some others:
3.4 Find new correct link to ru-wiki (in your example)
3.5 deny interwiki bots from editing that page with bots/nobots template
3.6 make an abuse filter to prevent wrong interwiki links
3.7 spread a ignore file to bot owners using mail list
3.8 develop a patch and submit it here
3.9 block the bots
3.10 block the page
4. I guess a fix would not be trivial (see 1.) and the priority becomes low
(see 2-3)
But if you have some proposals how this could be solved by the bots script
in a slightly easy manner, that would be great.
----------------------------------------------------------------------
Comment By: Askar Safin (safinaskar)
Date: 2012-06-10 07:34
Message:
This bug is WONTFIX, right?
Why?
----------------------------------------------------------------------
Comment By: Askar Safin (safinaskar)
Date: 2012-06-10 07:34
Message:
This bug is WONTFIX, right?
Why?
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-06-10 07:02
Message:
>As far as I know, if a human deleted not all interwikis, pywikipedia bot
>will add them again in any mode (auto. and semi-auto.). Am I right?
Right. All wrong interwiki must be removed on all projects. You may ask a
bot owner to do it for you. Otherwise the links are comming again (maybe
WikiData helps a bit in future). Another possibility is to comment out the
wrong link like
<!-- [[ru:B]] -->
If at all I guess this is a wont-fix bug
----------------------------------------------------------------------
Comment By: Askar Safin (safinaskar)
Date: 2012-06-08 11:39
Message:
I don't mean "en:A links to ru:B, and ru:B links to en:C"
I mean "en:A links to ru:B, ru:B links to en:A, but this interwikis are
wrong, so some human deleted en:A->ru:B, but some bot added it again, and
this is wrong"
Do you understand me? You can read
http://en.wikipedia.org/wiki/User_talk:Avicennasis/MainArchive/2012Q2#Your_…
for details (year, I posted this link third time) or you can see history of
page en:Thrashing_(computer_science) and all its interwikis (i already
fixed them manually)
As far as I know, if a human deleted not all interwikis, pywikipedia bot
will add them again in any mode (auto. and semi-auto.). Am I right?
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-06-08 07:26
Message:
Ok, I see. This occures, when bot owners semi-automatically fix interwiki
links only parts of the graph groups and do not run the bot for the rest.
Automatic running bots will get an interwiki conflict and leave the room.
Maybe this (sh/c)ould be solved but I guess this is not trivial. Anyway I
guess this won't be fixed since we expect WikiData which enforces the whole
behaviour must be changed.
----------------------------------------------------------------------
Comment By: Askar Safin (safinaskar)
Date: 2012-06-08 05:58
Message:
This IS wrong behavior. Consider real situation on my link:
http://en.wikipedia.org/wiki/User_talk:Avicennasis/MainArchive/2012Q2#Your_…
. There was 11 articles with interwikies to each other. But 4 of them are
unrelated with 7 other. So I had to manually remove all unnecessary
interwikies. So, I edited all this 11 articles and cleaned up all
inerwikies on them. This is very bad.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-06-07 07:40
Message:
This occures when not all wrong interwiki links are removed by hand from
the hole interwiki graph. I doesn't see any wrong behaviour.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3532712&group_…
Bugs item #3532712, was opened at 2012-06-07 03:05
Message generated for change (Comment added) made by safinaskar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3532712&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: interwiki
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Askar Safin (safinaskar)
Assigned to: Nobody/Anonymous (nobody)
Summary: It is not easy to delete interwiki
Initial Comment:
I think PyWikipedia Interwiki Bot works with interwikies badly. If someone deletes interwiki, the bot adds it back (but it is not right behavior). See more details on http://en.wikipedia.org/wiki/User_talk:Avicennasis/MainArchive/2012Q2#Your_… .
P. S. I don't use the bot, so I cannot include output of "python version.py"
----------------------------------------------------------------------
>Comment By: Askar Safin (safinaskar)
Date: 2012-06-10 07:34
Message:
This bug is WONTFIX, right?
Why?
----------------------------------------------------------------------
Comment By: Askar Safin (safinaskar)
Date: 2012-06-10 07:34
Message:
This bug is WONTFIX, right?
Why?
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-06-10 07:02
Message:
>As far as I know, if a human deleted not all interwikis, pywikipedia bot
>will add them again in any mode (auto. and semi-auto.). Am I right?
Right. All wrong interwiki must be removed on all projects. You may ask a
bot owner to do it for you. Otherwise the links are comming again (maybe
WikiData helps a bit in future). Another possibility is to comment out the
wrong link like
<!-- [[ru:B]] -->
If at all I guess this is a wont-fix bug
----------------------------------------------------------------------
Comment By: Askar Safin (safinaskar)
Date: 2012-06-08 11:39
Message:
I don't mean "en:A links to ru:B, and ru:B links to en:C"
I mean "en:A links to ru:B, ru:B links to en:A, but this interwikis are
wrong, so some human deleted en:A->ru:B, but some bot added it again, and
this is wrong"
Do you understand me? You can read
http://en.wikipedia.org/wiki/User_talk:Avicennasis/MainArchive/2012Q2#Your_…
for details (year, I posted this link third time) or you can see history of
page en:Thrashing_(computer_science) and all its interwikis (i already
fixed them manually)
As far as I know, if a human deleted not all interwikis, pywikipedia bot
will add them again in any mode (auto. and semi-auto.). Am I right?
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-06-08 07:26
Message:
Ok, I see. This occures, when bot owners semi-automatically fix interwiki
links only parts of the graph groups and do not run the bot for the rest.
Automatic running bots will get an interwiki conflict and leave the room.
Maybe this (sh/c)ould be solved but I guess this is not trivial. Anyway I
guess this won't be fixed since we expect WikiData which enforces the whole
behaviour must be changed.
----------------------------------------------------------------------
Comment By: Askar Safin (safinaskar)
Date: 2012-06-08 05:58
Message:
This IS wrong behavior. Consider real situation on my link:
http://en.wikipedia.org/wiki/User_talk:Avicennasis/MainArchive/2012Q2#Your_…
. There was 11 articles with interwikies to each other. But 4 of them are
unrelated with 7 other. So I had to manually remove all unnecessary
interwikies. So, I edited all this 11 articles and cleaned up all
inerwikies on them. This is very bad.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-06-07 07:40
Message:
This occures when not all wrong interwiki links are removed by hand from
the hole interwiki graph. I doesn't see any wrong behaviour.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3532712&group_…
Bugs item #3532712, was opened at 2012-06-07 03:05
Message generated for change (Comment added) made by safinaskar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3532712&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: interwiki
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Askar Safin (safinaskar)
Assigned to: Nobody/Anonymous (nobody)
Summary: It is not easy to delete interwiki
Initial Comment:
I think PyWikipedia Interwiki Bot works with interwikies badly. If someone deletes interwiki, the bot adds it back (but it is not right behavior). See more details on http://en.wikipedia.org/wiki/User_talk:Avicennasis/MainArchive/2012Q2#Your_… .
P. S. I don't use the bot, so I cannot include output of "python version.py"
----------------------------------------------------------------------
>Comment By: Askar Safin (safinaskar)
Date: 2012-06-10 07:34
Message:
This bug is WONTFIX, right?
Why?
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-06-10 07:02
Message:
>As far as I know, if a human deleted not all interwikis, pywikipedia bot
>will add them again in any mode (auto. and semi-auto.). Am I right?
Right. All wrong interwiki must be removed on all projects. You may ask a
bot owner to do it for you. Otherwise the links are comming again (maybe
WikiData helps a bit in future). Another possibility is to comment out the
wrong link like
<!-- [[ru:B]] -->
If at all I guess this is a wont-fix bug
----------------------------------------------------------------------
Comment By: Askar Safin (safinaskar)
Date: 2012-06-08 11:39
Message:
I don't mean "en:A links to ru:B, and ru:B links to en:C"
I mean "en:A links to ru:B, ru:B links to en:A, but this interwikis are
wrong, so some human deleted en:A->ru:B, but some bot added it again, and
this is wrong"
Do you understand me? You can read
http://en.wikipedia.org/wiki/User_talk:Avicennasis/MainArchive/2012Q2#Your_…
for details (year, I posted this link third time) or you can see history of
page en:Thrashing_(computer_science) and all its interwikis (i already
fixed them manually)
As far as I know, if a human deleted not all interwikis, pywikipedia bot
will add them again in any mode (auto. and semi-auto.). Am I right?
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-06-08 07:26
Message:
Ok, I see. This occures, when bot owners semi-automatically fix interwiki
links only parts of the graph groups and do not run the bot for the rest.
Automatic running bots will get an interwiki conflict and leave the room.
Maybe this (sh/c)ould be solved but I guess this is not trivial. Anyway I
guess this won't be fixed since we expect WikiData which enforces the whole
behaviour must be changed.
----------------------------------------------------------------------
Comment By: Askar Safin (safinaskar)
Date: 2012-06-08 05:58
Message:
This IS wrong behavior. Consider real situation on my link:
http://en.wikipedia.org/wiki/User_talk:Avicennasis/MainArchive/2012Q2#Your_…
. There was 11 articles with interwikies to each other. But 4 of them are
unrelated with 7 other. So I had to manually remove all unnecessary
interwikies. So, I edited all this 11 articles and cleaned up all
inerwikies on them. This is very bad.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-06-07 07:40
Message:
This occures when not all wrong interwiki links are removed by hand from
the hole interwiki graph. I doesn't see any wrong behaviour.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3532712&group_…
Bugs item #3532712, was opened at 2012-06-07 03:05
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3532712&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: interwiki
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Askar Safin (safinaskar)
Assigned to: Nobody/Anonymous (nobody)
Summary: It is not easy to delete interwiki
Initial Comment:
I think PyWikipedia Interwiki Bot works with interwikies badly. If someone deletes interwiki, the bot adds it back (but it is not right behavior). See more details on http://en.wikipedia.org/wiki/User_talk:Avicennasis/MainArchive/2012Q2#Your_… .
P. S. I don't use the bot, so I cannot include output of "python version.py"
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2012-06-10 07:02
Message:
>As far as I know, if a human deleted not all interwikis, pywikipedia bot
>will add them again in any mode (auto. and semi-auto.). Am I right?
Right. All wrong interwiki must be removed on all projects. You may ask a
bot owner to do it for you. Otherwise the links are comming again (maybe
WikiData helps a bit in future). Another possibility is to comment out the
wrong link like
<!-- [[ru:B]] -->
If at all I guess this is a wont-fix bug
----------------------------------------------------------------------
Comment By: Askar Safin (safinaskar)
Date: 2012-06-08 11:39
Message:
I don't mean "en:A links to ru:B, and ru:B links to en:C"
I mean "en:A links to ru:B, ru:B links to en:A, but this interwikis are
wrong, so some human deleted en:A->ru:B, but some bot added it again, and
this is wrong"
Do you understand me? You can read
http://en.wikipedia.org/wiki/User_talk:Avicennasis/MainArchive/2012Q2#Your_…
for details (year, I posted this link third time) or you can see history of
page en:Thrashing_(computer_science) and all its interwikis (i already
fixed them manually)
As far as I know, if a human deleted not all interwikis, pywikipedia bot
will add them again in any mode (auto. and semi-auto.). Am I right?
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-06-08 07:26
Message:
Ok, I see. This occures, when bot owners semi-automatically fix interwiki
links only parts of the graph groups and do not run the bot for the rest.
Automatic running bots will get an interwiki conflict and leave the room.
Maybe this (sh/c)ould be solved but I guess this is not trivial. Anyway I
guess this won't be fixed since we expect WikiData which enforces the whole
behaviour must be changed.
----------------------------------------------------------------------
Comment By: Askar Safin (safinaskar)
Date: 2012-06-08 05:58
Message:
This IS wrong behavior. Consider real situation on my link:
http://en.wikipedia.org/wiki/User_talk:Avicennasis/MainArchive/2012Q2#Your_…
. There was 11 articles with interwikies to each other. But 4 of them are
unrelated with 7 other. So I had to manually remove all unnecessary
interwikies. So, I edited all this 11 articles and cleaned up all
inerwikies on them. This is very bad.
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2012-06-07 07:40
Message:
This occures when not all wrong interwiki links are removed by hand from
the hole interwiki graph. I doesn't see any wrong behaviour.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3532712&group_…
Feature Requests item #3533577, was opened at 2012-06-08 11:55
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3533577&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: sum_disc: all related issues
Initial Comment:
Since sum_disc.py was merged into upstream here, I think it will be most suitable to track all further feature request and issues here.
Thus I gather everything that is still open at the moment, most of them feature requests and quite old (low importance):
https://jira.toolserver.org/browse/DRTRIGON-123
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2012-06-10 06:54
Message:
maybe you should wait a bit. we discuss to move to buzilla.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603141&aid=3533577&group_…
Bugs item #1968967, was opened at 2008-05-21 10:52
Message generated for change (Settings changed) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=1968967&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Out of Date
Priority: 5
Private: No
Submitted By: David Crochet (crochet_david)
Assigned to: xqt (xqt)
Summary: no possible deletion with delete user right
Initial Comment:
my bot (Crochet.david.bot) had a Test-administrator group statut (so not the sysop group statut), but this statut have the delete rights (as the sysop group statut) in the incubator wikimedia project.
So, as you can see with the terminal output (attach file)
the bot can't delete.
user rights in incubator : http://incubator.wikimedia.org/wiki/Special:ListGroupRights
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2012-06-10 05:21
Message:
out of date
----------------------------------------------------------------------
Comment By: xqt (xqt)
Date: 2011-12-29 09:07
Message:
The behavior of the bot has been changed and user rights are read via api
call. We assume default rights but we should use the api results in
general. I guess this could be closed according out of date.
----------------------------------------------------------------------
Comment By: Doug (bewareofdoug)
Date: 2011-12-29 08:00
Message:
Is there a reason the bot checks for particular privileges in the first
place? Can't the bot simply deal with the insufficient privileges response
from the mediawiki software?
----------------------------------------------------------------------
Comment By: Doug (bewareofdoug)
Date: 2011-12-15 04:18
Message:
delete.py works fine, I've recently tested on two non-wmf wikis and could
test on a wmf wiki if we really need to. Cosoleto seems to have pointed to
the problem. Either that or user_config.py was not set up properly.
On the other hand, this points at a real and, I'm fairly certain, ongoing
problem, which is that the bot fails when the bot account has special
rights, such as delete, block, or import, under a userrights group other
than sysop.
----------------------------------------------------------------------
Comment By: Francesco Cosoleto (cosoleto)
Date: 2008-06-12 06:50
Message:
Logged In: YES
user_id=181280
Originator: NO
In wikipedia.py (_getUserData()) try to replace:
if 'sysop' in self._rights[index]:
self._rights[index].extend(['delete', 'undelete', 'block',
'protect', 'import', 'deletedhistory', 'unwatchedpages'])
with:
if 'sysop' in self._rights[index] or 'test-sysop' in
self._rights[index]:
self._rights[index].extend(['delete', 'undelete', 'block',
'protect', 'import', 'deletedhistory', 'unwatchedpages'])
----------------------------------------------------------------------
Comment By: NicDumZ — Nicolas Dumazet (nicdumz)
Date: 2008-05-22 10:35
Message:
Logged In: YES
user_id=1963242
Originator: NO
I'm told by david that wgUserGroups reads
var wgUserGroups = ["bot", "test-sysop", "*", "user", "autoconfirmed"];
on the incubator, meaning that site._rights[1] will be ["bot",
"test-sysop", "user", "autoconfirmed"]
Then, when isAllowed('delete', True), boolean checks " 'delete' in
site._rights[1] ", it returns False, and it raises a LockedPage exception.
David also tells me that his admin user rights (on wikiversity-fr) are "var
wgUserGroups = ["sysop", "*", "user", "autoconfirmed"];". This means that
even with "normal" sysop rights, "delete" is *_never_* in var
wgUserGroups.
I don't have sysop rights on any projects, so I can't really diagnose much
more on this problem, but are we sure that we are still able to delete
pages here ? Isn't somewhat broken ??
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=1968967&group_…
Bugs item #3533793, was opened at 2012-06-09 00:40
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3533793&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: reza (reza1615)
>Assigned to: xqt (xqt)
Summary: problem on nv languge with interwiki bot
Initial Comment:
Hi,
interwiki bots adds wrong namesapce from (nv.wiki) to other wikis such as
http://ak.wikipedia.org/w/index.php?title=Wikipedia&action=history
please solve it
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2012-06-09 12:46
Message:
It is the main article namespace and the bot did right in its behaviour. I
spent a __STATICREDIRECT__ to the redirect page to prevent this. You may
also comment out wrong interwiki links like
<!-- [[nv:Íiyisíí Naaltsoos]] -->
----------------------------------------------------------------------
Comment By: https://www.google.com/accounts ()
Date: 2012-06-09 02:41
Message:
Originally because [[nv:Wikiibíídiiya]] is redirect to this main page.
Actually because several bots are working in same time in same pages, ant
this one takes long time, so one bot removes it, bud second have this link
in memory and after some time adds it...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3533793&group_…
Bugs item #3533792, was opened at 2012-06-09 00:34
Message generated for change (Comment added) made by xqt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3533792&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
>Resolution: Rejected
Priority: 5
Private: No
Submitted By: David Crochet (crochet_david)
>Assigned to: xqt (xqt)
Summary: variable 'account_global'
Initial Comment:
By a "svn up" from r10306 and r10334 the program say :
WARNING: Configuration variable 'account_global' is defined but unknown. Misspelled?
----------------------------------------------------------------------
>Comment By: xqt (xqt)
Date: 2012-06-09 12:36
Message:
just remove that line from your user_config.py. There is sth like
account_global = True
That value has never been used and was removed.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3533792&group_…
Bugs item #3516410, was opened at 2012-04-10 04:26
Message generated for change (Comment added) made by multichill
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3516410&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: André Malafaya Baptista (malafaya)
Assigned to: Nobody/Anonymous (nobody)
Summary: Secure connection still uses old Wikimedia server
Initial Comment:
When setting SSL_connection = True, the bot still accesses https://secure.wikimedia.org/ instead of just changing http:// to https:// and using the correct server. For example, it shoud use https://pt.wiktionary.org/ when accessing the Portuguese Wiktionary using HTTPS.
Pywikipedia trunk/pywikipedia/ (r10103, 2012/04/10, 07:18:22)
Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)]
config-settings:
use_api = True
use_api_login = True
unicode test: ok
----------------------------------------------------------------------
>Comment By: Multichill (multichill)
Date: 2012-06-09 07:49
Message:
Most instances were already replaced. Did the last one in
http://www.mediawiki.org/wiki/Special:Code/pywikipedia/10338
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=603138&aid=3516410&group_…