aboutsummaryrefslogtreecommitdiffstats
path: root/includes/logging/LogEntry.php
Commit message (Collapse)AuthorAgeFilesLines
* Namespace all remaining files in includes/loggingJames D. Forrester2025-03-191-0/+5
| | | | | Bug: T353458 Change-Id: Ibe1810f1c71316a9124e1dc6ae405097dafd5267
* logging: Improve documentation of log parameter handlingGergő Tisza2023-07-121-0/+3
| | | | Change-Id: Ib23a1afe2bc0b90fcf9291935b6ed019669494e8
* Reorg: Namespace the Title classJames D. Forrester2023-03-021-0/+1
| | | | | | | | | | | | | | | | | | | This is moderately messy. Process was principally: * xargs rg --files-with-matches '^use Title;' | grep 'php$' | \ xargs -P 1 -n 1 sed -i -z 's/use Title;/use MediaWiki\\Title\\Title;/1' * rg --files-without-match 'MediaWiki\\Title\\Title;' . | grep 'php$' | \ xargs rg --files-with-matches 'Title\b' | \ xargs -P 1 -n 1 sed -i -z 's/\nuse /\nuse MediaWiki\\Title\\Title;\nuse /1' * composer fix Then manual fix-ups for a few files that don't have any use statements. Bug: T166010 Follows-Up: Ia5d8cb759dc3bc9e9bbe217d0fb109e2f8c4101a Change-Id: If8fc9d0d95fc1a114021e282a706fc3e7da3524b
* Better document the type of timestamp accepted/returnedthiemowmde2022-11-021-1/+1
| | | | | | Related to I29399e7. Change-Id: Iafa1fcac95f9b7a6cbc3a8ae9d4aff825acb302d
* pager: Clean up file headers and `@ingroup`Timo Tijhof2022-09-291-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Follows similar commits to the objectcache, rdbms, filerepo, jobqueue components and other areas [1]. * Remove duplicate descriptions from file blocks in favour of class doc blocks. This reduces needless duplication and was often incorrect or outdated, and helps (ironically) to make the file header more consistently visually ignorable. * Remove `ingroup` from file blocks in class files as otherwise the file is indexed twice (e.g. in Doxygen) which makes navigation more messy. * Fix non-standard `@unstable for implementation` annotations in favour of `@stable to type` as per T257789 and <https://www.mediawiki.org/wiki/Stable_interface_policy>. While at it, fix the only other outstanding uses of `@stable for` in core as well in a handful of context/, logging/ and search/ files. [1] https://gerrit.wikimedia.org/r/q/message:ingroup+owner:Krinkle Bug: T257789 Change-Id: Ided3c5ab69e1b587b1b76a3c97a7cdb88f21e130
* Remove hard-deprecated LogEntry::getPerformerPetr Pchelko2021-06-281-7/+0
| | | | Change-Id: Ia2c4819848f5d23d5ceb74aae9c6c5920b8851ba
* Introduce LogEntry::getPerformerIdentity and deprecate ::getPerformerVadim Kovalenko2021-02-171-1/+9
| | | | | Bug: T274329 Change-Id: I3dadb20f076494f7b46f0647ea3a8bfbbdaa59da
* Stability annotations for interfaces.daniel2020-07-071-0/+1
| | | | | | | | | Per the Stable Interface Policy, PHP interfaces should not be directly implemented by extensions, unless they are marked to be safe for that purpose. Bug: T247862 Change-Id: Idd5783b70fc00c03d57f5b1a887f0e47c4d7b146
* logging: Fix typo for `getPerformer()` interface method declarationDerick Alangi2019-08-191-1/+1
| | | | | | | Not sure but the previous wording didn't make much sense or is it correct that way? Change-Id: Ia5bea91fb426bb2fe742e656e5a826b8c07d88ee
* Split logging classes to individual filesReedy2019-04-141-819/+1
| | | | Change-Id: I3eaaf23612fe1aed65e49c06a9e5e565399af9ce
* Fix misc phan errors by adjusting documentation (#8)Kunal Mehta2019-04-051-1/+1
| | | | | | | | | | | | | | | | | PhanTypeInvalidRightOperand was triggering on ApiQueryBase::showHiddenUsersAddBlockInfo() on the line `$actorQuery['tables'] + $commentQuery['tables']` (and the next one). For whatever reason, phan was unable to automatically understand that the right side was an array (though it was able to understand $actorQuery, which has nearly identical code...), so I added more specific hinting to CommentStore::getJoin() using phan's union types, which resolved the issue. And incorrect documentation on LogEntry::getDeleted() was triggering PhanTypeMismatchBitwiseBinaryOperands since you can't do bitwise operations on a string and an integer. Change-Id: I13b791e4b754ffbc340b55cfb752e2d9226f1949
* Supress ChangeTags::addTags() exceptions for ManualLogEntry objectsPiotr Miazga2019-03-261-4/+25
| | | | | | | | | | | | | | | | | | | | | | Looks like some parts of the code try to publish log event when $newId is 0 or null. This cause ChangeTags::addTags to throw an exception as at least one of rc_id, rev_id, or log_id must be specified. When ChangeTags::addTags() fails (because both $rev_id and $log_id are not present), just ignore the exception and continue with the execution. Also, if one of those is set to 0, we need to pass null instead (do not insert 0's in to DB as both log_id and rev_id are foreign keys). Additionally log all places where ManualLogEntry::publish() is called with incorrect arguments so later we can fix all occurencie and remove that try{}catch around ChangeTags::addTags() call. Bug: T218940 Change-Id: I495f79f2b7a7ef1503d229a689babdc12deb353c
* Define ManualLogEntryBeforePublish hookPiotr Miazga2019-03-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | This hook is required by extensions like MobileFrontend to tag log entries when actions are performed on the mobile web. There is a possibility to tag log entries by using 'RecentChange_save' hook, but that works only when the log entry is published to 'rc' or 'rcandudp'. This means, that tagged log will appear also on the Special:RecentChanges page which is something what extensions like 'Thanks' wants to avoid. In the future we should avoid using 'RecentChange_save' as an indirect way to tag log entries, and use the 'ManualLogEntryBeforePublish' hook instead. To cover ourselves in the future, instead of passing &$tags only, we pass the $this (the log entry object) so extensions can perform additional checks before using setTags(). Bug: T215675 Change-Id: I747eded4bc5406cd5d4676fc93b0bb55c99f9a4d
* Provide a Taggable interfacePiotr Miazga2019-03-181-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | The Taggable interface defines how to tag objects in MediaWiki. For now there are only two Taggable objects: - RecentChange - ManualLogEntries This interface should be used in places where we want to optionally tag things, for example: We want to tag all mobile web actions with 'web mobile edit'. With that interface, we will be able to expect a Taggable object, and call `addTags()` when we need to, without having a special check to verify is it RecentChange, or is it ManualLogEntry. We will only expect a Taggable object. Additionally, added @deprecated note to ManualLogEntries::setTags() as each call to this method will override all previous tags. This action can be harmfull to parts of code that conditionally add tags. If object was tagged in some way, we should preserve those tags. If there are any special cases, where we want to override all tags, we should provide `resetTags()` method. Bug: T215675 Change-Id: Ia4c019db8ca6f37ce0f86bf7d134d6f1713daf56
* LogEntry: Restore logic to add change tags on udp-only publishBrad Jorsch2019-03-121-0/+6
| | | | | | | This was unintentionally removed in I8df2fd98. Bug: T218110 Change-Id: Ie8678b4207032d6eb877d596eb8f115798c80a1e
* Merge "logging: Start using LinkTarget & UserIdentity in ManualLogEntry"jenkins-bot2019-03-121-6/+8
|\
| * logging: Start using LinkTarget & UserIdentity in ManualLogEntryThiemo Kreuz2019-01-081-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a first, very small migration step. This is entirely non-breaking, as all objects passed to these two functions already matched the interfaces that are now required. For the setTarget() method it's most obvious it really just needs a LinkTarget value object, but not the entirety of the Title class with all it's helper methods. Same for the performer. A ManualLogEntry does not need to interact with the performer, just needs to know him. This small change allows to slowly migrate away from code depending on the User and Title classes. Note this code currently does not have any test coverage, and I do not plan to change this within this patch. I just don't have the time. https://doc.wikimedia.org/cover/mediawiki-core/includes/logging/LogEntry.php.html Change-Id: Id551f066ab02d5ca14346a39a55af4e7b6e4e042
* | logging: Remove 'null' return from ManualLogEntry::getTags()Timo Tijhof2019-03-021-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The documentation already claimed it returned array, this is now actually true. Follows-up 037c06e886c63. There are two ways it could be null: * The setTags() method was never called, and the class member was implicitly null by default. * The setTags() method was called with $tags = null. This happens WikiPage::doUpdateRestrictions() among other places. That could probably be fixed, but is out of scope for this change. The getTags() method of this clss appears to have no outside callers in MediaWiki core, nor in any other project indexed by Codesearch. Change-Id: Ib89c79ef90870506187c3c3b61464c2aa788c594
* | Hygiene: use null-coalescing operator when operating on tagsPiotr Miazga2019-03-011-5/+1
|/ | | | Change-Id: I7d5b4e05ee6c010b4f9438bc4871a3369b1871a6
* ActorMigration: Remove possibility of read-bothBrad Jorsch2018-10-111-2/+2
| | | | | | | | | | | | | | | | | | When this was originally written, the plan was to read both the old and new fields during the transition period, while stopping writes to them midway through. It turns out that the WHERE conditions to do read-both correctly are generally not handled well by the database and working around that would require a lot of complicated code (see what's being removed from ApiQueryUserContribs here, for example). We can simplify things greatly by instead having it write both fields during the transition period, reading from the old for the first part and the new for the second part, as is being done for MCR. Bug: T204669 Change-Id: I4764c1c7883dc1003cb12729455c8107319f70b1 Depends-On: I845f6ae462f2539ebd35cbb5f2ca8b5714e2c1fb Depends-On: I88b31b977543fdbdf69f8c1158e77e448df94e11
* Merge "Simplify PHP by using ?? and ?:"jenkins-bot2018-07-111-1/+1
|\
| * Simplify PHP by using ?? and ?:Fomafix2018-07-101-1/+1
| | | | | | | | | | | | Also remove not necessary surrounding parentheses. Change-Id: I0eb5c9c1bdfb09a800258379cdcefb5fd4d3d21c
* | Fix PhanTypeMismatchDeclaredParamUmherirrender2018-07-071-1/+1
|/ | | | | | Auto fix MediaWiki.Commenting.FunctionComment.DefaultNullTypeParam sniff Change-Id: I865323fd0295aabd06f3e3c75e0e5043fb31069e
* Fix MediaWiki.Commenting.LicenseComment.InvalidLicenseTag errorsKunal Mehta2018-05-231-1/+1
| | | | Change-Id: I936c3f5fca1a0061f215e80469f5d882cb32ee29
* Merge "RecentChange: Use constants for the $noudp parameter of save()"jenkins-bot2018-04-301-1/+1
|\
| * RecentChange: Use constants for the $noudp parameter of save()Timo Tijhof2018-04-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is a boolean parameter that is confusing for three reasons: * It's a boolean parameter, given parameters are unnamed in PHP, these are always poor UX for call sites. * It's negated ("noudp"). save(true) means no feeds events, save(false) [default] means sending events to feeds. * To overcome this problem, typical use was to pass a free-form string that self-documents the intended behaviour, e.g. `save('pleasenoudp')`, any string casts to true. Fix this by moving the booleans to constants and use those instead. For compatiblity, keep the negation internally, although it's hidden from regular usage. Also document the string hack, deprecate it, and update callers. Change-Id: Ia57c86b38bf50cb4ec580f42a6b1ca798fcf781a
* | Better class documentationKaldari2018-04-291-2/+7
| | | | | | | | Change-Id: I25912f38bb483cd4636bff4ce219dc878a1046f3
* | Remove the feature switch for disabling autopatrol loggingAmir Sarabadani2018-04-131-7/+0
| | | | | | | | | | | | | | | | | | Per the RFC, it will now become the default and only behaviour to not log autpatrol actions. The information is already recorded via the rc_patrolled field. Bug: T184485 Change-Id: I98ae895a2b4cde4bb945f1df23be4a070b0bf9c4
* | Replace rc_patrolled values with contants, part IAmir Sarabadani2018-04-111-1/+1
|/ | | | | | This constants has been recently introduced and it's good to use them Change-Id: I8ce56dc95de3e49610dca71c00965ca1ac74bcf0
* Make autopatrol third option in rc_patrolled and use it in APIAmir Sarabadani2018-04-031-1/+1
| | | | | Bug: T184791 Change-Id: If64ba8b845b122a87f20646dddf72ef257b793cb
* Introduce DatabaseLogEntry::newFromIdMax Semenik2018-03-051-0/+24
| | | | | | It's a helper function for when you need just one log entry. Change-Id: Ic5e9db0def857d9dcecbd06bf081c8c83712c1ea
* Add `actor` table and code to start using itBrad Jorsch2018-02-231-9/+44
| | | | | | | | | | | | | Storing the user name or IP in every row in large tables like revision and logging takes up space and makes operations on these tables slower. This patch begins the process of moving those into one "actor" table which other tables can reference with a single integer field. A subsequent patch will remove the old columns. Bug: T167246 Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50 Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
* Update suppressWarning()/restoreWarning() callsReedy2018-02-101-2/+2
| | | | | Bug: T182273 Change-Id: I9e1b628fe5949ca54258424c2e45b2fb6d491d0f
* Pass $key into CommentStore methods and use MediawikiServicesaddshore2018-02-051-5/+5
| | | | | | | | | | | | | | | | | | | | | | | This allows CommentStore to be added to MediaWikiServices without the need of an aditional Factory. This change includes a compatability layer to allow the behaviour from 1.30 to continue to be used while deprecated. CommentStore::newKey has been deprecated. Keys are now passed into the public methods of CommentStore where needed. The following CommentStore methods have had their signatures changed to introduced a $key parameter, but when used in conjunction with CommentStore::newKey behaviour will remain unchanged: * CommentStore::getFields * CommentStore::getJoin * CommentStore::getComment * CommentStore::getCommentLegacy * CommentStore::insert * CommentStore::insertWithTemplate Change-Id: I3abb62a5cfb0dcd456da9f4eb35583476ae41cfb
* Replace selectFields() methods with getQueryInfo()Brad Jorsch2017-10-301-1/+1
| | | | | | | | | | | | | | Several classes have a "selectFields()" static method to tell callers which fields to select from the database. With the recent comment table change and the upcoming actor table change, this pattern has become too simplistic as a SELECT will need to join several tables to be able to retrieve all the needed fields. Thus, we deprecate the selectFields() methods in favor of getQueryInfo() methods that return tables and join conditions in addition to the fields. Change-Id: Idcfd15568489d9f03a7ba4460e96610d33bc4089
* Merge "Handle comment truncation in CommentStore"jenkins-bot2017-09-051-5/+0
|\
| * Handle comment truncation in CommentStoreBrad Jorsch2017-09-011-5/+0
| | | | | | | | | | | | | | | | Since the caller doesn't (and shouldn't) know whether CommentStore is using the old or the new schema, it should leave truncation of comments to CommentStore. Change-Id: I92954c922514271d774518d6a6c28a01f33c88c2
* | Remove reference to deprecated IDatabase->nextSequenceValue()Brad Jorsch2017-09-011-2/+0
|/ | | | | | The method was deprecated and made unnecessary in Ib308190c. Change-Id: I1729ac0b3a88270a4c2f064187a2472112aaeb1e
* Add `comment` table and code to start using itBrad Jorsch2017-08-301-7/+11
| | | | | | | A subsequent patch will remove the old columns. Bug: T166732 Change-Id: Ic3a434c061ed6e443ea072bc62dda09acbeeed7f
* Remove auto-generated "Constructor" documentation on constructorsThiemo Mättig2017-07-101-2/+0
| | | | | | | | Having such comments is worse than not having them. They add zero information. But you must read the text to understand there is nothing you don't already know from the class and the method name. Change-Id: I994d11e05f202b880390723e148d79c72cca29f0
* Fix usage of $db->nextSequenceValue()Brad Jorsch2017-05-101-1/+1
| | | | | | | | | The return value from the method is only suitable for passing to $db->insert(). To get the inserted ID, you need to call $db->insertId() even if $db->nextSequenceValue() returned non-null. Bug: T164900 Change-Id: I6beb6243ccb9425372623307ef23ae6571ce8c0d
* Move IDatabase/IMaintainableDatabase to Rdbms namespaceAaron Schulz2017-03-281-0/+2
| | | | Change-Id: If7e8a8ff574661fd827de8bcec11d2c39a687300
* Document type of LogEntry::isPatrollable propertyLeszek Manicki2016-12-141-1/+1
| | | | Change-Id: I557b92f25f15f57123af329c79ef1752025aedf3
* Avoid multiple writes to changetags table in recentchanges_save hookcenarium2016-09-271-8/+6
| | | | | | | | | | | Currently, extensions that add tags within the recentchanges_save hook directly call ChangeTags::addTags. This often results in consecutive writes to the changetags table. This provides a addTags method to RecentChange so extensions can simply use it when they want a tag added. And all the actual tagging is done once at the end. Change-Id: I8df2fd983c12632337e8d2922fa357808482338c
* Defer publish of recent change for log entriescenarium2016-09-061-31/+33
| | | | | | | | | | This defers the publish function of ManualLogEntry, which includes saving the recent change to the db, notification of feeds, auto-patrol and addition of change tags. This way, end users no longer have to wait for those actions to conclude for the request to complete. Bug: T127852 Change-Id: Ida86b7a7383d12695be28338c69b93e8e86d82c9
* Allow to pass a rev id to a log entry without making it unpatrolledcenarium2016-03-141-3/+30
| | | | | | | | | | | | | This adds new methods to ManualLogEntry that allow to specify that a log entry is patrollable. RecentChange::newLogEntry then checks this in order to allow or not unpatrolled status instead of checking if there is an associated rev id. This allows to associate a revision to a log entry without possibly making the recent change unpatrolled, and extensions can implement patrol of actions not dependent on an associated revision id. Bug: T127848 Change-Id: I98298047142819b69639e6ca9d77c5ba982a380c
* Add tags support to patrol, protect, unblock, and undeleteGeoffrey Mon2016-02-291-0/+32
| | | | | | | | | | | | - Add 'tags' parameters to appropriate API modules - Add tag-adding logic to appropriate functions that carry out relevant functions - ManualLogEntry::{set,get}Tags to handle adding tags to log entries in a cleaner fashion - Use ManualLogEntry::setTags in LocalFile::recordUpload2 Bug: T97720 Change-Id: I98c52da7985623bfdafda2dc2dae937b39b72419
* Convert all array() syntax to []Kunal Mehta2016-02-171-18/+18
| | | | | | | | | | Per wikitech-l consensus: https://lists.wikimedia.org/pipermail/wikitech-l/2016-February/084821.html Notes: * Disabled CallTimePassByReference due to false positives (T127163) Change-Id: I2c8ce713ce6600a0bb7bf67537c87044c7a45c4b
* Make it possible to tag new file uploads without messy queriesBartosz Dziewoński2016-01-251-1/+4
| | | | | | | | | | | | | | | UploadBase::performUpload() now takes a $tags parameter and passes it to LocalFile::upload() and LocalFile::recordUpload2(), which eventually adds the requested tags to the log_id, rev_id and rc_id that are created for the file upload. Previously you'd have to query the database for the latest rev_id and log_id for the page title under which the title is being uploaded, as performUpload() is unable to return them to you because it's all deferred in funny ways. Bug: T121874 Change-Id: I99a8fd67c84219d2715d3d88cc21500614431179
* LogEntry: Make associated rev id persistent (store in logging and log_search)Bartosz Dziewoński2016-01-071-3/+34
| | | | | | | | | | | | | | | | | | The implementation from 0160b410bd514681b1637ccab2b7c79158fbfb29 only stored the associated rev id in the `recentchanges` table, which was sufficient for its purpose of allowing patrol of these log entries and provided some change tagging improvements, but ephemeral. Now we also store it in `logging` and `log_search` tables, which makes it possible to find a revision for the log entry and vice versa. * For `log_search` we just add a row with 'associated_rev_id' as key, it was designed for exactly this purpose. * For `logging` we store it in log_params field in ManualLogEntry, and transparently remove it from there when building a DatabaseLogEntry. Bug: T122089 Change-Id: I559587ff77b3c94b31a6c5951287b6f9c1e167ce