Lokal_Profil added a comment.
If you need a temporary workaround you can install the developers branch of pywikiboy with pip install git+https://github.com/wikimedia/pywikibot-core.git the version you should have after that is 3.0-dev.
The reason why I call it a temporary fix
Lokal_Profil added a comment.
In T150210#2783476, @gerritbot wrote:
Change 320649 had a related patch set uploaded (by Lokal Profil):
Make uncertainties in WbQuantity optional
https://gerrit.wikimedia.org/r/320649
There is a lot of extra code in here just to ensure this is compatible
Lokal_Profil added a comment.
In T142155#2783466, @Pintoch wrote:
Lokal_Profil: thanks, yes indeed that's what I did. I hope someone will be able to make a new release on PyPi soon.
At the very least a new one will be needed due to T150210 to ensure we don't add incorrect data to Wikidata
Lokal_Profil added a comment.
In T150210#2784023, @Strainu wrote:
Great job keeping the backwards compatibility! I say submit the code with the current logic and remove the extra logic later if the code becomes unmaintainable (this will eventually happen after a few more breaking changes
Lokal_Profil added a comment.
In T150210#2810877, @Strainu wrote:
Since backwards compatibility will be broken anyway, the question is if we should keep the extra code that handles older versions of Wikibase. Is there any data on the number of Wikibase installations out there?
I pinged
Lokal_Profil closed this task as "Resolved".Lokal_Profil claimed this task.Lokal_Profil added a comment.
This was fixed in https://gerrit.wikimedia.org/r/#/c/299262/TASK DETAILhttps://phabricator.wikimedia.org/T60906EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailp
Lokal_Profil added a comment.
In T151092#2820215, @Wesalius wrote:
Is my .err content related to this (solved by the patch)?
WARNING: WbQuantity now expects a 'site' parameter. This is needed to ensure correct handling of error bounds.
WARNING: WbQuantity now expects a 'site' parameter
Lokal_Profil added a comment.
Note that the patch just sidesteps the underlying issues mentioned in T112543, T112405#1637544, T112416.
It might also affect T133288.
Just as before there might be warnings in later chunks or on completion which are completely ignored if an allowed warning occurs
Lokal_Profil created this task.Lokal_Profil added a project: Pywikibot-core.Herald added subscribers: pywikibot-bugs-list, Aklapper.
TASK DESCRIPTIONCalling site.upload() with a non-zero chunk_size and an callable ignore_warnings results in the following error message when an allowed warning
Lokal_Profil added a comment.
@Wesalius The patch has now been merged so there should be no need to modify your code. If you still encounter problems please raise them at T150210TASK DETAILhttps://phabricator.wikimedia.org/T151092EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
Lokal_Profil closed this task as "Resolved".Lokal_Profil added a comment.
Many thanks @StrainuTASK DETAILhttps://phabricator.wikimedia.org/T150210EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: daniel, Magul, ChongDae, Strainu,
Lokal_Profil added a comment.
The default has now changed so that you only need the site parameter on older Wikibase installations. I.e. you don't need it on Wikidata. So running the latest version of the master branch should resolve the issue.TASK DETAILhttps://phabricator.wikimedia.org
Lokal_Profil added a comment.
In T151092#2822773, @Wesalius wrote:
But this error was raised when trying to edit wikidata.
So without the site object the function cannot determine which version of Wikibase is running. So it assumes the old version... which isn't what Wikidata runs. The followg
Lokal_Profil added a comment.
In T106121#2802405, @Magul wrote:
I Your case if You don't want to maintain Your code, You can pin to particular version/pypi release of library, and if You want to use new features You can just use virtualenvs to execute particular code with particular library's
Lokal_Profil added a comment.
@Strainu No reply on the list. I would suggest merging the patch as I've already seen a couple of questions from people running on Wikidata.TASK DETAILhttps://phabricator.wikimedia.org/T150210EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
Lokal_Profil added a comment.
@Xqt Have you had an opportunity to look at the second two parts of the set of patches?TASK DETAILhttps://phabricator.wikimedia.org/T143594EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: Xqt, Beta16, Multichill
Lokal_Profil added a comment.
If you add site.login() to your script it should log you in with the right credentials (it does for me).TASK DETAILhttps://phabricator.wikimedia.org/T150645EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc
Lokal_Profil added a comment.
OK. So the current patch was merged which allows pywikibot to go on dealing with Wikidata.
To avoid the scenario which @daniel mentions a follow-up patch can be submitted which changes _require_errors() to False instead if no site object is provided. I we put
Lokal_Profil added a subscriber: Xqt.Lokal_Profil added a comment.
@Xqt As requested I have split this up into three commits:
https://gerrit.wikimedia.org/r/319834: Expose the concept url of an ItemPage
https://gerrit.wikimedia.org/r/319835: Support adding units to WbQuantity through the entity
Lokal_Profil added a comment.
In T143594#2712657, @Multichill wrote:
Wouldn't it be easier to just except unit as an ItemPage or an entity url? No need to introduce a new "entity" variable here.
Gives it the same structure as Coordinate and makes it easier to go to/from wikibase
Lokal_Profil added a comment.
In T143594#2712037, @gerritbot wrote:
Change 315645 had a related patch set uploaded (by Lokal Profil):
[Not ready] Support adding units to WbQuantity through ItemPage or URI
https://gerrit.wikimedia.org/r/315645
@Multichill This patch should (when upstream
Lokal_Profil added a subtask: T143910: Add entity_prefix/repoConceptBaseUri to siteinfo.
TASK DETAILhttps://phabricator.wikimedia.org/T143594EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: ArthurPSmith, gerritbot, Ladsgroup, Aklapper
Lokal_Profil added a comment.
As a work around:
import time
from pywikibot import config as pwb_config
batch_size = 30
rate_limit = 65 # default limit is 30 edits per 60 seconds
max_timeout = 300
# bump timeout
old_timeout = pwb_config.socket_timeout
pwb_config.socket_timeout = max_timeout
Lokal_Profil added a project: Pywikibot-Commons.
TASK DETAILhttps://phabricator.wikimedia.org/T151562EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: jayvdb, gerritbot, Aklapper, XZise, Lokal_Profil, pywikibot-bugs-list, Th3d3v1ls, Ramalepe
Lokal_Profil added a comment.
Is there a particular reason/need to have lojban.org in the tests? If there isn't then simply removing it could make sense.
Also since I'm on mobile and can't leave this content in gerrit:
You have referenced the wrong parameter in the docstring for the decorator
Lokal_Profil added a comment.
Purge requires POST in the newest MW version. IIRC pywikibot tries GET and if it gets mustpost it tries to log in to get around it.TASK DETAILhttps://phabricator.wikimedia.org/T153093EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
Lokal_Profil added a comment.
A related question (which might already be in a separate task, if so appologies) does this now also correctly identify beta.wikidata as the wikibase repo associated with the beta Wikipedias?TASK DETAILhttps://phabricator.wikimedia.org/T151372EMAIL PREFERENCEShttps
Lokal_Profil created this task.Lokal_Profil added projects: Pywikibot-core, Pywikibot-network.Herald added subscribers: pywikibot-bugs-list, Aklapper.
TASK DESCRIPTIONA rate limit is imposed on anyone but sysops and bureaucrats when using the purge function. The default value is max 30 pages per
Lokal_Profil added a comment.
Many of the new docstrings don't include epydoc fields for their parameters.
I feel, that there is not much value in adding parameteres infromations here. I would like to add them to aseertSite and assertNoSite but all tests accept self and return None or raises
Lokal_Profil added a comment.
@Dalba: You mean having unit take either an entity url or a pywikibot.ItemPage? Rather than splitting these over two parameters? (Note that there are two patches)
My personal opinion is that the separation makes it clearer, makes it easier to convert between the two
Lokal_Profil closed this task as "Resolved".Lokal_Profil claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T151706EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: Lokal_Profil, Magul, Dalba, Aklapper, Wesalius, pywikibot
Lokal_Profil added a comment.
In T151706#2842520, @Wesalius wrote:
Now I still get the warning but I can proceed to edit wd without a problem.
True. It will still ask for it but if it can't find it it will assume that you are running on a newer Wikibase (i.e. on Wikidata).TASK DETAILhttps
Lokal_Profil added a comment.
My mistake I looked at the other commitments meNationell in this thread.TASK DETAILhttps://phabricator.wikimedia.org/T152996EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Magul, Lokal_ProfilCc: Lokal_Profil, Mpaa, Dalba, Xqt
Lokal_Profil added a comment.
I agree with @Magul that the time sink aspects should not be very pronounced with the proposed scheme of releases since we will not be trying to maintain multiple releases.
Pip install is by far the most common way of consuming python libraries. Requiring
Lokal_Profil changed the title from "Regressions of core should be rethinked or solved" to "RFC: Regressions of core should be rethinked or solved".
TASK DETAILhttps://phabricator.wikimedia.org/T151110EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/pa
Lokal_Profil added a comment.
In T106121#2863447, @Magul wrote:
@Lokal_Profil Maybe it wasn't clear in my previous comments - I'm advocating for frequent releases (like in constant interval of one month). It will provide current features in commonly used format. I'm also agruing for abandoning
Lokal_Profil added a comment.
In T152996#2884917, @Dalba wrote:
I usually recommend keeping lines below 80 characters, but only for those lines that are newly added. Older lines are usually kept unchanged which I assume helps when using git blame or searching the git log for specific change
Lokal_Profil added a comment.
Do we want to handle a change of release model/plan in this RFC or should that be a separate one with this one on hold until that is resolved?TASK DETAILhttps://phabricator.wikimedia.org/T106121EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
Lokal_Profil added a comment.
In T152996#2899565, @Magul wrote:
In T152996#2891272, @Lokal_Profil wrote:
I'm happy to merge as is. Consistently applying the 80 char limit trumps the minor aesthetic loss in this particular case.
Do I need to do something here? Or do You lose this patch from
Lokal_Profil added a comment.
In T151369#2884474, @Dalba wrote:
There is another possible solution if anyone wants to look more into it:, The API provides srqiprofile parameter which can be set to empty and hopefully that can give us deterministic results without needing to fetch the whole 1
Lokal_Profil added projects: Pywikibot-core, Pywikibot-Wikidata.Lokal_Profil edited the task description. (Show Details)Herald added a subscriber: pywikibot-bugs-list.
EDIT DETAILSIt looks like the bot adds Coordinate claims identical to already existing ones (same value and reference)Comparing
Lokal_Profil edited the task description. (Show Details)
EDIT DETAILS...An alternative (or temporary work around) would be to create a new type in __init__.py which takes a normal Page object but validates ~~that it has the `Map.JsonConfig` content-type~~* (or any other restrictions
Lokal_Profil added a comment.
I set up T161726: Suport new geoshape datatype in Pywikibot to deal with the root cause (before noticing this).TASK DETAILhttps://phabricator.wikimedia.org/T160339EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc
Lokal_Profil changed the title from "Suport new geoshape datatype in Pywikibot" to "Suport new geo-shape datatype in Pywikibot".
TASK DETAILhttps://phabricator.wikimedia.org/T161726EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Loka
Lokal_Profil created this task.Lokal_Profil added projects: Pywikibot-core, Pywikibot-Wikidata.Herald added subscribers: pywikibot-bugs-list, Aklapper.
TASK DESCRIPTIONWith T161543: Enable geoshape datatype on Wikidata there will be a new datatype around meaning pywikibot will cry whenever
Lokal_Profil closed this task as "Resolved".Lokal_Profil claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T160339EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: gerritbot, Lokal_Profil, Aklapper, pywikibot-bugs-l
Lokal_Profil claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T131624EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: gerritbot, jayvdb, Xqt, Aklapper, Lokal_Profil, pywikibot-bugs-list, Adik2382, Th3d3v1ls, Ramalepe, Liugev6
Lokal_Profil added a comment.
Note that the very same test will fail IF we implement geo-shapes but this time for Wikidata properties (since the datatype has not yet been deployed there). We might want to change the test to fail on missing data types but not on extra ones (which also shouldn't
Lokal_Profil added a comment.
In T152907#3154867, @valhallasw wrote:
I have pushed pywikibot-3.0.20170403.tar.gz to PyPI.
Thanks!!TASK DETAILhttps://phabricator.wikimedia.org/T152907EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: gerritbot
Lokal_Profil closed this task as "Resolved".Lokal_Profil assigned this task to valhallasw.Lokal_Profil added a comment.
Resolved through T152907TASK DETAILhttps://phabricator.wikimedia.org/T159280EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To:
Lokal_Profil created this task.Lokal_Profil added projects: Pywikibot-core, Pywikibot-Commons.Herald added subscribers: pywikibot-bugs-list, Aklapper.
TASK DESCRIPTIONBroken out of T161726: Support new geo-shape datatype in Pywikibot
Since Commons is now serving as both a shared image repository
Lokal_Profil claimed this task.Lokal_Profil added a comment.
I'm putting together a work around through __init__.py, got it to work just need to add tests.TASK DETAILhttps://phabricator.wikimedia.org/T161726EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
Lokal_Profil added projects: Pywikibot-tests, Pywikibot-core.Herald added a subscriber: pywikibot-bugs-list.
TASK DETAILhttps://phabricator.wikimedia.org/T162581EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: pywikibot-bugs-list, Lokal_Profil
Lokal_Profil created this task.Lokal_Profil added projects: Pywikibot-core, Pywikibot-Wikidata.Herald added subscribers: pywikibot-bugs-list, Aklapper.
TASK DESCRIPTIONSince WDQ has been shut down the various WDQ implementations in pywikibot should either be removed (or replaced with a notice
Lokal_Profil closed this task as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T161726EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: gerritbot, Aklapper, pywikibot-bugs-list, Lokal_Profil, Adik2382, Th3d3v1ls, Ramalep
Lokal_Profil added a comment.
Is the second patch replacing the first or should they be considered two alternative solutions?TASK DETAILhttps://phabricator.wikimedia.org/T162509EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: Lokal_Profil
Lokal_Profil added a comment.
For now the url is hardcoded in the family file. Once T162561: Expose geoShapeStorageFrontendUrl through siteinfo is resolved we should instead get to it through the api.TASK DETAILhttps://phabricator.wikimedia.org/T161726EMAIL PREFERENCEShttps
Lokal_Profil created this task.Lokal_Profil added projects: Pywikibot-core, Pywikibot-Wikidata, HTTPS.Herald added subscribers: pywikibot-bugs-list, Aklapper.Herald added a project: Traffic.
TASK DESCRIPTIONThe current implementation of sparql/query support for pywikibot relies on a hardcoded uri
Lokal_Profil changed the title from "Prepare pywikibot for " to "Prepare pywikibot for http -> https switch in entity uri".
TASK DETAILhttps://phabricator.wikimedia.org/T159956EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_Profil
Lokal_Profil added a comment.
I'm not sure completely removing @_retry_few_times is the way forwards. That was introduced to deal with a variety of hiccups when connecting to the sites. Yes if the site is down all will fail but that is less weird than having some builds fail and some not due
Lokal_Profil added a comment.
In T143594#3086787, @Dalba wrote:
Thanks, André!
Thank you for the patient reviewing :)TASK DETAILhttps://phabricator.wikimedia.org/T143594EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: Dalba, Xqt, Beta16
Lokal_Profil removed projects: Operations, Traffic.Herald added a project: Traffic.
TASK DETAILhttps://phabricator.wikimedia.org/T159956EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: gerritbot, Aklapper, pywikibot-bugs-list, Lokal_Profil
Lokal_Profil added subscribers: Xqt, Dalba, Lokal_Profil.Lokal_Profil added a comment.
In T153592#2885061, @gerritbot wrote:
Change 328044 had a related patch set uploaded (by Magul):
Change pageids validation to more error resilient
https://gerrit.wikimedia.org/r/328044
@Dalba @Xqt @Magul
Lokal_Profil closed this task as "Resolved".Lokal_Profil claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T167827EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: gerritbot, Aklapper, Lokal_Profil, pywikibot-bugs-lis
Lokal_Profil moved this task from Backlog to Announced on the Pywikibot-Announce board.Lokal_Profil closed this task as "Resolved".Lokal_Profil claimed this task.Lokal_Profil added a comment.
I'm marking this as announced. There has since been multiple mentions of BotPassword on the ma
Lokal_Profil added a comment.
Thanks. That strengthens my belief that they should not be included in a comparison.
What speaks for them being included though is that they are properties of the pywikibot.Claim object (which is thus an hybrid of a claim and a statement)TASK DETAILhttps
Lokal_Profil added a comment.
Now that there are equality operators for all allowed claim targets this should be easier to handle. With regards to order of qualifiers/sources and (statements in each source), per this discussion the order should not be assumed to carry any meaning. So we would
Lokal_Profil added a comment.
Apparently flake8-putty can be used to make sure pydocstyle (and other tests) is more lenient with the test files than otherwise.TASK DETAILhttps://phabricator.wikimedia.org/T166950EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
Lokal_Profil added a comment.
I'm checking in T160048#3230495 but if the implementation is identical then I could throw together support pretty quickly.
Note that it would start being hard-coded to Commons until I can make a patch to expose the site through the api.TASK DETAILhttps
Lokal_Profil added a comment.
This would also be of use for T163981: Add support for the new 'tabular-data' datatype on wikidataTASK DETAILhttps://phabricator.wikimedia.org/T162336EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: Aklapper
Lokal_Profil created this task.Lokal_Profil added projects: Pywikibot-core, Pywikibot-Wikidata.Herald added subscribers: pywikibot-bugs-list, Aklapper.
TASK DESCRIPTIONIt would be great if we had a dummy Wikibase type implemented in pywikibot. This would be used for any datatype which
Lokal_Profil added a comment.
I'm not sure the logic is right in the unbreak patch site should always be automatically provided when loading data fromWikibase.
I'll take a closer look at this and what went wrong with the original patch.TASK DETAILhttps://phabricator.wikimedia.org/T166362EMAIL
Lokal_Profil added a comment.
Fixed. @Multichill thanks for the emergency fix. Your assumption was also correct in that data_site had gotten accidentally copied in from __init__.TASK DETAILhttps://phabricator.wikimedia.org/T166362EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel
Lokal_Profil closed this task as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T165961EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Multichill, Lokal_ProfilCc: gerritbot, Addshore, Lokal_Profil, Aklapper, pywikibot-bugs-list, Multichill
Lokal_Profil closed subtask T165961: Implement WbUnknown to handle new (unknown) Wikibase data types as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T165996EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: Lokal_Profil
Lokal_Profil created this task.Lokal_Profil added projects: Pywikibot-core, Pywikibot-Wikidata.Herald added subscribers: pywikibot-bugs-list, Aklapper.
TASK DESCRIPTIONIt would be good if WbRepresentation was hashable as this would make it possible to e.g. use sets to ensure duplicate items
Lokal_Profil added a comment.
In T140516#2534726, @Stan3 wrote:
In T140516#2533511, @Lokal_Profil wrote:
That diff doesn't look like it's built on top of commons_family.py in the master branch. Are there more patches in-between?
I'm on the 2.0 branch
The branch to develop against is master
Lokal_Profil added a comment.
In T153592#3237740, @Lokal_Profil wrote:
A quick fix might be to wrap the gen = call in a try and then catch any ValueError and replace it by something more descriptive?
On the other hand then one would have to parse the original error message to get the offending
Lokal_Profil added a comment.
In T153592#3237572, @Dalba wrote:
In T153592#3073899, @Lokal_Profil wrote:
@Dalba @Xqt @Magul: Should this patch be abandoned with the merging of https://gerrit.wikimedia.org/r/337348?
Apparently that patch is pursuing another goal: "Make pageids validat
Lokal_Profil added a comment.
@Sovmogil you need to use the newest version on pip 3.0.xxxTASK DETAILhttps://phabricator.wikimedia.org/T150210EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: Sovmogil, Mike_Peel, Holger, daniel, Magul, ChongDae
Lokal_Profil moved this task from Backlog to Announced on the Pywikibot-Announce board.Lokal_Profil added a comment.
https://lists.wikimedia.org/pipermail/pywikibot/2017-December/009795.htmlTASK DETAILhttps://phabricator.wikimedia.org/T154771WORKBOARDhttps://phabricator.wikimedia.org/project/board
Lokal_Profil added a comment.
I'm not sure those last wikidata links should have been changed, per T153563. See note in https://gerrit.wikimedia.org/r/390872TASK DETAILhttps://phabricator.wikimedia.org/T102315EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
Lokal_Profil added a comment.
+1 for this idea. It will also make T76615: Claim equality operator easier to deal with.
One note though is that the the suggestion above does not match Wikibase steucture as described in https://phabricator.wikimedia.org/T76615#3464800. Importantly pywikibot.Claim
Lokal_Profil added a comment.
Expanding on my previous comment about the current and proposed pywikibot.Claim being a mixture of Wikibase's Claim and Statement. Reproducing that structure in pywikibot would be fairly easy using the below amendment to the proposal
class Claim(BaseClaim):
def
Lokal_Profil added a comment.
In T186200#4240251, @Dvorapa wrote:
I'm not familiar with Wikidata, but at least this seems to make the code cleaner, improve its readability, and reduce code-complexity on Codeclimate.
Just make sure you will solve some of the issues in #pywikibot-wikidata
Lokal_Profil added a project: WMSE-Project-leftovers.
TASK DETAILhttps://phabricator.wikimedia.org/T155238EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc: Framawiki, Xqt, pywikibot-bugs-list, Aklapper, Alicia_Fagerving_WMSE, Magul, Tbscho
Lokal_Profil added subscribers: valhallasw, Lokal_Profil.Lokal_Profil added a comment.
I picked this up again in https://gerrit.wikimedia.org/r/442168 and https://gerrit.wikimedia.org/r/442169
The first re-factors Link to introduce BaseLink the second is basically @Ricordisamoa's patch but now
Lokal_Profil added a comment.
For import order isort can be used instead. That way the linter can also automatically fix the issues so there is no real overhead for the developer. See e.g. https://gerrit.wikimedia.org/r/378741TASK DETAILhttps://phabricator.wikimedia.org/T166950EMAIL
Lokal_Profil added a comment.
In T106121#3856550, @Dalba wrote:
I'd suggest using the version number instead of timestamp.
The problem with that is that versioning is today done separately from doing a deprecating commit and to the one doing the commit the current version isn't necessarily
Lokal_Profil added a comment.
In T106121#3858860, @Dalba wrote:
... if deprecated code removal is going to be date-based only, e.g. after 1 year of deprecation as some have suggested, then a timestamp looks more appropriate.
Since regular releases was a problem in the past I would probably go
Lokal_Profil added a comment.
Quick note to self: Should be possible to add the following at about line 12421 of wmf-config/InitialiseSettings.php
# wgGrantPermissions @{
'wgGrantPermissions' => [
'sewikimedia' => [
'editpage' => [ 'editallpages' => true ], // T184981
],
Lokal_Profil removed a project: Pywikibot-core.Lokal_Profil added a comment.
Thanks @JJMC89 I'd missed that editallpages had been especially crafted for sewikimedia. I guess it can either be added to the editpage grant (or maybe the sewikimedia config might be simplified by now).TASK DETAILhttps
Lokal_Profil created this task.Lokal_Profil added a project: Pywikibot-core.Herald added subscribers: pywikibot-bugs-list, Aklapper.
TASK DESCRIPTIONWhen trying to do edits to the Projekt namespace on the wmse chapterwiki I repeatedly get a "API error protectednamespace: You do not have permi
Lokal_Profil added a project: MediaWiki-extensions-OAuth.Lokal_Profil added a comment.
Adding Oauth tag as that is the closest I can find to one for the BotPasswords functionallity (please change if wrong)TASK DETAILhttps://phabricator.wikimedia.org/T184981EMAIL PREFERENCEShttps
Lokal_Profil added a comment.
I'm encountering a similar problem trying to edit pages on https://se.wikimedia.org using the replace.py script.
The bot account has the right to edit these pages ( I can do it in the browser if I log in), the grants in BotPassword are set up to allow editing
Lokal_Profil added a comment.
In T154771#3914689, @Xqt wrote:
See also this deprecation warning from python core team
link to warningTASK DETAILhttps://phabricator.wikimedia.org/T154771EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lokal_ProfilCc
Lokal_Profil added a comment.
In T184981#3906465, @Tgr wrote:
Probably more like '+sewikimedia', although even that might replace editpage instead of merging into it (if that's the case you'd have to add it in CommonSettings.php).
I looked into the source of the extra right and found
Lokal_Profil renamed this task from "API error protectednamespace incorrectly triggered when logged in using BotPassword" to "Remove the medlem user group and the editallpages user right on se.wikimedia.org".Lokal_Profil updated the task description. (Show Deta
Lokal_Profil added a comment.
https://gerrit.wikimedia.org/r/404055 has been merged but https://gerrit.wikimedia.org/r/#/c/403404/6 is still open.TASK DETAILhttps://phabricator.wikimedia.org/T154771EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences
Lokal_Profil added a comment.
In T184981#3915760, @MarcoAurelio wrote:
Please do not forget to remove all users from that group. If you do not remove the users from the group previously, the result is that they'll still will hold the 'medlem' right in the shadows and will appear
101 - 200 of 251 matches
Mail list logo
