Cygnus issueshttps://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues2017-12-20T21:35:21Zhttps://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/43Implement function "revisiondelete"2017-12-20T21:35:21ZLuke081515luke081515@tools.wmflabs.orgImplement function "revisiondelete"Write a function to use that API-functionWrite a function to use that API-functionVersion 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/41Implement massmessage2017-12-20T21:33:13ZLuke081515luke081515@tools.wmflabs.orgImplement massmessageAPI-function massmessage should be implementedAPI-function massmessage should be implementedVersion 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/39All write methods should check AllowBots2017-12-19T00:04:40ZLuke081515luke081515@tools.wmflabs.orgAll write methods should check AllowBotsWe have already `AllowBots()`, it's checking pages, if editing them. But we should also check on deleting, protecting etc.We have already `AllowBots()`, it's checking pages, if editing them. But we should also check on deleting, protecting etc.Version 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/32General handling for warnings2017-11-09T14:27:53ZLuke081515luke081515@tools.wmflabs.orgGeneral handling for warningsAs seen in #31 it would be nice if we can display or log warnings. In this case I discovered that problem only because I ran debug with the new verbose-debug mode. That is optimal, as warnings may useful as well for the developers. Additionally, if we are handling warnings better, we can make unit tests fail as well.
What's better, displaying or logging warnings? And at which place to we want to catch them? Each function or maybe httpRequest? httpRequest has the problem of different formats, if old functions are using format=php, httpRequest can't search for the json part. Or implement an extra function for that?
@freddy2001 Your thoughts?As seen in #31 it would be nice if we can display or log warnings. In this case I discovered that problem only because I ran debug with the new verbose-debug mode. That is optimal, as warnings may useful as well for the developers. Additionally, if we are handling warnings better, we can make unit tests fail as well.
What's better, displaying or logging warnings? And at which place to we want to catch them? Each function or maybe httpRequest? httpRequest has the problem of different formats, if old functions are using format=php, httpRequest can't search for the json part. Or implement an extra function for that?
@freddy2001 Your thoughts?Version 2.2FreddyFreddyhttps://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/28Generate CodeCoverage Report2018-01-10T21:30:29ZLuke081515luke081515@tools.wmflabs.orgGenerate CodeCoverage ReportIt would be nice if pipeline can generate a CodeCoverage report, phpunit supports that, but needs to be configured.It would be nice if pipeline can generate a CodeCoverage report, phpunit supports that, but needs to be configured.Version 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/15Collect return possiblitys for each function2018-01-30T12:30:34ZLuke081515luke081515@tools.wmflabs.orgCollect return possiblitys for each functionTo check 2.1 when it's finished and for #14 I need a list of every return result and a test for each method. For example:
* `checkUserExistence()`
* `return false` => User does not exist
* `return true` => User does exist
In case that there are methods which are using variable outputs, like editcount, then please write something like this:
* `checkUserEditcount()`
* `return false` => User does not exist
* `return (example) 1152` => User has the editcount 1152 (example)To check 2.1 when it's finished and for #14 I need a list of every return result and a test for each method. For example:
* `checkUserExistence()`
* `return false` => User does not exist
* `return true` => User does exist
In case that there are methods which are using variable outputs, like editcount, then please write something like this:
* `checkUserEditcount()`
* `return false` => User does not exist
* `return (example) 1152` => User has the editcount 1152 (example)Version 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/14Write automatic tests for each function2017-11-09T15:12:30ZLuke081515luke081515@tools.wmflabs.orgWrite automatic tests for each functionIt would be great if we can build a script which checks every function against each single return possiblity, and then submit this script to the pipeline for each new commit.It would be great if we can build a script which checks every function against each single return possiblity, and then submit this script to the pipeline for each new commit.Version 2.2Luke081515luke081515@tools.wmflabs.orgLuke081515luke081515@tools.wmflabs.orghttps://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/7Get a uniform format for API-Urls2017-12-19T00:04:54ZLuke081515luke081515@tools.wmflabs.orgGet a uniform format for API-UrlsWhen formatting an API URL there are several ways at the moment, one is putting all the extra rubish in one line. That's not that readable, additionally phpcs freaks out when it sees that. So we need a good way to format all these URLs. What format do you prefer?
I prefer something like:
```
$data = 'action=watch'
. '&format=json'
. '&unwatch=' . $unwatch
. '&titles=' . urlencode($title)
. '&token=' . urlencode($token)
. '&assert=' . $this->assert
. '&maxlag=' . $this->maxlag;
```
(From merge request 5)
Easy to read, but tends to get long.When formatting an API URL there are several ways at the moment, one is putting all the extra rubish in one line. That's not that readable, additionally phpcs freaks out when it sees that. So we need a good way to format all these URLs. What format do you prefer?
I prefer something like:
```
$data = 'action=watch'
. '&format=json'
. '&unwatch=' . $unwatch
. '&titles=' . urlencode($title)
. '&token=' . urlencode($token)
. '&assert=' . $this->assert
. '&maxlag=' . $this->maxlag;
```
(From merge request 5)
Easy to read, but tends to get long.Version 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/4Allow the use of the watchlist2018-01-22T11:30:29ZLuke081515luke081515@tools.wmflabs.orgAllow the use of the watchlistIn general you can track changes with the watchlist. It can be useful to use this feature. We should:
* [x] create a function that allows watching and unwatching of pages
* [x] make sure that no other functions are watching or unwatching pages
* [ ] create a function that reads out the watchlistIn general you can track changes with the watchlist. It can be useful to use this feature. We should:
* [x] create a function that allows watching and unwatching of pages
* [x] make sure that no other functions are watching or unwatching pages
* [ ] create a function that reads out the watchlistVersion 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/88Offer of reimplementation2018-03-30T22:40:05ZMGCheckerOffer of reimplementationI want to offer you the reimplementation of party of my patch from a few months ago, if you're intrerested in that:
* A clearer, more flexible setting architecture with JSON
* An Autoloading functionality for classes in combination with namespaces, maybe in combination with a CygUtility file. Personally, I think this centralized functionality is the only way to reduce duplicated code at (for instance) printing warnings and loading JSON files. Note: Autoloading is only useful if we choose a slightly more object oriented approach with at least some Exception classes.
* An improved engine for api requests with lower suspectibility to errors. This would decrease duplicate code, while increasing the simplicity of handling api requests and using Cygnus in general. The user wouldn't have to care about most api errors and should be able to to submit it's api params as array.
* Encapsulating BotCore. People shouldn't mess mit BotCore, but use it.
* Long-ranging: An object oriented handling of results of api requests instead of abusing arrays for these complex objects. This would be the first step, the goal could be to have a fully object-oriented framework with distinct frameworks for wiki communication, loggers, etc. Such a model would depend highly on Composition. An object-oriented framework would make maintenance easiser and improve flexibility. Furthermore, it puts more structure into the code, it is more like a human would group functionality. However, this is nothing you can build over the course of a few days, I think it'll take at least 80 hours of work to build the second part. (Note that the first part is coded already in many parts).
I'll split this stuff in multiple patches, making it easier to handle for everyone.
I've got some time to spare in March and I'll take some days of that and spend it to reimplement (and test) my patch, if you're interested. However, this is just an feer, you don't have to take it. I still think these are really useful improvals if done the right way, but I'm looking forward to a producitve debate what's useful for Cygnus and what isn't. I want to offer you the reimplementation of party of my patch from a few months ago, if you're intrerested in that:
* A clearer, more flexible setting architecture with JSON
* An Autoloading functionality for classes in combination with namespaces, maybe in combination with a CygUtility file. Personally, I think this centralized functionality is the only way to reduce duplicated code at (for instance) printing warnings and loading JSON files. Note: Autoloading is only useful if we choose a slightly more object oriented approach with at least some Exception classes.
* An improved engine for api requests with lower suspectibility to errors. This would decrease duplicate code, while increasing the simplicity of handling api requests and using Cygnus in general. The user wouldn't have to care about most api errors and should be able to to submit it's api params as array.
* Encapsulating BotCore. People shouldn't mess mit BotCore, but use it.
* Long-ranging: An object oriented handling of results of api requests instead of abusing arrays for these complex objects. This would be the first step, the goal could be to have a fully object-oriented framework with distinct frameworks for wiki communication, loggers, etc. Such a model would depend highly on Composition. An object-oriented framework would make maintenance easiser and improve flexibility. Furthermore, it puts more structure into the code, it is more like a human would group functionality. However, this is nothing you can build over the course of a few days, I think it'll take at least 80 hours of work to build the second part. (Note that the first part is coded already in many parts).
I'll split this stuff in multiple patches, making it easier to handle for everyone.
I've got some time to spare in March and I'll take some days of that and spend it to reimplement (and test) my patch, if you're interested. However, this is just an feer, you don't have to take it. I still think these are really useful improvals if done the right way, but I'm looking forward to a producitve debate what's useful for Cygnus and what isn't. https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/56Write tutorial for Cygnus2017-12-25T22:21:14ZFreddyWrite tutorial for CygnusA tutorial with the basic functions of Cygnus (read, edit, ...) would be helpful for someA tutorial with the basic functions of Cygnus (read, edit, ...) would be helpful for somehttps://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/33make the bot able to read/write from wikibase2018-01-30T22:29:41ZLuke081515luke081515@tools.wmflabs.orgmake the bot able to read/write from wikibaseoriginally from https://rcm-2.wmflabs.org/T905
The bot should be able to interact with wikibase. Not sure if we should insert that into BotCore or write a seperate class.originally from https://rcm-2.wmflabs.org/T905
The bot should be able to interact with wikibase. Not sure if we should insert that into BotCore or write a seperate class.FreddyFreddy