Cygnus issueshttps://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues2018-06-11T09:29:21Zhttps://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/98Ensure user is logged in2018-06-11T09:29:21ZLuke081515luke081515@tools.wmflabs.orgEnsure user is logged inEnsure that the user is still logged in, or do a relogin.Ensure that the user is still logged in, or do a relogin.Version 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/97Take assert to the password2018-06-11T09:29:31ZLuke081515luke081515@tools.wmflabs.orgTake assert to the passwordMost accounts have a botflag or not, so it would be useful to set the assert value with the account credentials in Password.phpMost accounts have a botflag or not, so it would be useful to set the assert value with the account credentials in Password.phpVersion 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/90Check if a username looks like an IP2018-02-11T12:08:01ZLuke081515luke081515@tools.wmflabs.orgCheck if a username looks like an IPSee https://gitlab.wmflabs.org/Cygnus/Cygnus/issues/11#note_854See https://gitlab.wmflabs.org/Cygnus/Cygnus/issues/11#note_854Version 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/83Add new SQL framework to Cygnus2018-02-11T14:57:31ZFreddyAdd new SQL framework to CygnusAdd new SQL framework to CygnusAdd new SQL framework to CygnusVersion 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/82Implement action=clientlogin2018-01-13T00:12:33ZLuke081515luke081515@tools.wmflabs.orgImplement action=clientloginSee #31 for the original issue. We maybe want to implement action=clientloginSee #31 for the original issue. We maybe want to implement action=clientloginVersion 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/81Ban serialized arrays as return value2018-01-12T23:53:10ZLuke081515luke081515@tools.wmflabs.orgBan serialized arrays as return valueSerialized Arrays as return value are bad. The user needs to take care of the API-Answer then. The function should do that for him instead.
Current functions using serialized Arrays:
* [ ] `movePage()`
* [ ] `getCatMembers()`
* [ ] `getPageCats()`
* [ ] `getAllEmbedings()`
* [ ] `getAllPages()`Serialized Arrays as return value are bad. The user needs to take care of the API-Answer then. The function should do that for him instead.
Current functions using serialized Arrays:
* [ ] `movePage()`
* [ ] `getCatMembers()`
* [ ] `getPageCats()`
* [ ] `getAllEmbedings()`
* [ ] `getAllPages()`Version 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/79Use similar layout for the docu2018-01-29T01:19:19ZLuke081515luke081515@tools.wmflabs.orgUse similar layout for the docuCurrently the order of @param, @author etc. is different, it would be useful to make that similar.
I'd say we can do:
```php
/** method name
* Short description
* @author Authorname
* @param $param - text here
* @param $param - [default: default value] - text
* @return type: text
*/
```Currently the order of @param, @author etc. is different, it would be useful to make that similar.
I'd say we can do:
```php
/** method name
* Short description
* @author Authorname
* @param $param - text here
* @param $param - [default: default value] - text
* @return type: text
*/
```Version 2.1Luke081515luke081515@tools.wmflabs.orgLuke081515luke081515@tools.wmflabs.orghttps://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/75Put generic API-params in a function2018-01-30T12:43:13ZLuke081515luke081515@tools.wmflabs.orgPut generic API-params in a functionEach function needs maxlag. Each function needs assert, or at least most. It would be nice if we can put this to a function that get called on each api-call.Each function needs maxlag. Each function needs assert, or at least most. It would be nice if we can put this to a function that get called on each api-call.Version 2.2Luke081515luke081515@tools.wmflabs.orgLuke081515luke081515@tools.wmflabs.orghttps://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/73Write a generic query continue2018-01-09T19:41:46ZLuke081515luke081515@tools.wmflabs.orgWrite a generic query continue!77 inspired me. What do you think of:
**A generic query continue!**
The concept itself is simple and nice, implementation may be not.
# What the function does
## Conditions for using
Query functions often have more results then the limit allows, so continue is needed. Currently the functions are doing this until all results are fetched. This may be useless if the user only needs 7000 for example.
## Calling it
Functions are reciving the continue. This continue has a name as well (if using rawcontinue, we may switch to the other continue), so the continue engine can get called, with the params `continuename `and `api-call url` at least. The function will start fetching everything then. It would be useful to implement that recursive, but PHP allows only 50 levels of recursive functions IIRC
# Nice additional features
The user can specify a limit, and the function tries to fetch as much as possible data, if [limit] > [limit of data to fetch in one request]. Then, the function will continue, until the limit is reached.
Please share your opinion on this proposal with me.!77 inspired me. What do you think of:
**A generic query continue!**
The concept itself is simple and nice, implementation may be not.
# What the function does
## Conditions for using
Query functions often have more results then the limit allows, so continue is needed. Currently the functions are doing this until all results are fetched. This may be useless if the user only needs 7000 for example.
## Calling it
Functions are reciving the continue. This continue has a name as well (if using rawcontinue, we may switch to the other continue), so the continue engine can get called, with the params `continuename `and `api-call url` at least. The function will start fetching everything then. It would be useful to implement that recursive, but PHP allows only 50 levels of recursive functions IIRC
# Nice additional features
The user can specify a limit, and the function tries to fetch as much as possible data, if [limit] > [limit of data to fetch in one request]. Then, the function will continue, until the limit is reached.
Please share your opinion on this proposal with me.Version 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/59Add functions to DBCore2018-06-11T09:29:51ZFreddyAdd functions to DBCoreSome functions for DBCoreSome functions for DBCoreVersion 2.2FreddyFreddyhttps://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/57Implement system to show API-Warnings2018-01-30T22:28:03ZLuke081515luke081515@tools.wmflabs.orgImplement system to show API-WarningsIf there are API warnings these should get shown to the user. Currently these warnings are not handeled.If there are API warnings these should get shown to the user. Currently these warnings are not handeled.Version 2.1Luke081515luke081515@tools.wmflabs.orgLuke081515luke081515@tools.wmflabs.orghttps://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/53Implement list=usercontrib2017-12-20T21:45:46ZLuke081515luke081515@tools.wmflabs.orgImplement list=usercontribVersion 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/52Implement list=logevents2017-12-20T21:44:19ZLuke081515luke081515@tools.wmflabs.orgImplement list=logeventsto read out logs etc.to read out logs etc.Version 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/51Implement list=checkuser / list=checkuserlog2017-12-20T21:43:24ZLuke081515luke081515@tools.wmflabs.orgImplement list=checkuser / list=checkuserlogVersion 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/50Implement function "list=alldeletedrevisions"2017-12-20T21:42:49ZLuke081515luke081515@tools.wmflabs.orgImplement function "list=alldeletedrevisions"For usage like: get all deleted revisions where the author is user xFor usage like: get all deleted revisions where the author is user xVersion 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/49Implement function "pro=pageviews"2017-12-20T21:41:40ZLuke081515luke081515@tools.wmflabs.orgImplement function "pro=pageviews"Version 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/48Implement function "fileusage" / "globalusage"2017-12-20T21:40:44ZLuke081515luke081515@tools.wmflabs.orgImplement function "fileusage" / "globalusage"for querying file datafor querying file dataVersion 2.2https://gitlab.wmflabs.org/Cygnus/Cygnus/-/issues/47Implement function "prop=deletedrevisions"2017-12-20T21:39:50ZLuke081515luke081515@tools.wmflabs.orgImplement function "prop=deletedrevisions"It should be possible to query deleted versionsIt should be possible to query deleted versionsVersion 2.2