[17:24:13] Should centralauth-merge be an assignable right in ManageWiki or is that a bug? [17:32:05] I can't see an issue with that [17:49:27] RhinosF1: I see, it's just strange to see a CentralAuth-level permission be assignable in ManageWiki. But thanks :) [18:19:03] @rhinof1 everytime i am trying to upload a image to movipedia it redirects to famepedia and i removed any links that could be causing it [18:19:08] @RhinosF1 [18:19:25] ah never mind i fixed it [18:26:33] Cocopuff2018: lol, why would it redirect to famepedia 😂 [18:27:22] because i screwed up a share image thing, and it didnt work out right it redirected it to famepedia so just had to fix it @Joseph [18:27:33] it was suppose to share images but did not work out [18:28:28] Shared images can only come from Commons not famepedia, I think that's why it didn't work. [18:29:14] wel i think its possible but not sure [18:31:17] Okay. [18:34:49] @Agent, The issue is that that user right has high potential for users to auto-add users to their wiki, and there's no procedural basis to delegate it locally [18:35:06] oh wait [18:35:13] that's `centralauth-local` [18:35:21] you asked about `centralauth-merge` [18:35:34] I believe that's because it's needed if globally merging users [18:36:07] but in any case, it's useless without centralauth- rights, so no one can do anything with it even if you assign it to `user` [18:37:12] dmehus: centralauth-merge allows you to merge an unattached local account to your global one [18:37:24] It's quite frankly useless for us [18:37:29] RhinosF1, ah, right [18:37:49] dmehus: it's there for when wikimedia did the SUL migration [18:38:25] RhinosF1, true. Yeah, I forgot about that. Other than SUL, it's not really needed. So it's basically harmless. Sorry I thought it was related to `usermerge` in some way [18:39:16] since we don't really have any cases of unattached local accounts...if a steward was globally merging an account, they'd be sure to attach any unattached accounts (hopefully) [18:43:48] I'd be very worried if you had any unattached local accounts, as (afaik) you've used CA from the start [18:45:47] majavah, yeah. It's happened in some cases where we've done global renames that got stuck and didn't properly fix the global rename. Also, I've seen it with the system user bots whereby we made a global account, and MediaWiki isn't programmed, I assume, to auto-attach those local accounts globally [18:46:59] [[Special:CentralAuth/FuzzyBot]] possibly [18:46:59] https://meta.miraheze.org/wiki/Special:CentralAuth/FuzzyBot [18:47:00] [url] Global account information for FuzzyBot - Miraheze Meta | meta.miraheze.org [18:47:32] Interestingly, in that case, it doesn't list all the wikis that use the Translate extension [18:51:58] oh, system accounts are a mess, true [18:53:02] heh yeah [18:53:12] renames creating unattached users should definitely treated as CA bugs, although I don't think those have really been happening since the actor migration [18:53:23] Is there a long outstanding Phab ticket about that, majavah? [18:53:58] it's only from 2019, https://phabricator.wikimedia.org/T214722 [18:53:59] [url] ⚓ T214722 Introduce global system users | phabricator.wikimedia.org [18:54:16] The rename doesn't create any unattached users, but if it's stuck, the unattached accounts are left unattached to a non-existent global user is what I mean [18:54:17] oh [18:54:19] interesting [18:54:27] I should subscribe to that. Thanks! :) [18:55:41] it's on my really long list of "things to look at some day", but I don't think I'll get to it any time soon [18:56:28] majavah, is that why the AbuseFilter system user shows up in CU results sometimes? [18:56:40] I see the comment about the AbuseFilter in there [18:56:58] no clue, I haven't worked with AF or CU really [18:57:06] ah [18:57:08] ok [18:57:46] AF's system user is translatable (=really annoying from CA perspective), which is why it's mentioned there [18:58:45] majavah, ah, yes I just noticed that also actually! [18:59:25] I thought it was a real user, until I look at its logs and say " blocked autopromotion for " etc. [20:32:38] dmehus: abuse filter showing up in CU logs doesn't make sense [20:32:42] With what data [22:47:49] I noticed that when commenting with Extension CommentStreams, i can't see buttons for formatting. Like bold or italic. [22:48:35] There are formatting on the editboxes of commentStreams? [22:52:34] I'm not certain. [22:53:04] You could maybe file a Phabricator task? Worse case it would be determined to be desired functionality and closed as invalid? [22:53:28] Phabricator task where? [22:53:56] I can't see it mentioned here: https://m.mediawiki.org/wiki/Extension:CommentStreams [22:53:56] [url] Extension:CommentStreams - MediaWiki | m.mediawiki.org [22:54:30] The edit box is plain. [22:54:57] The phabricator of Wikimedia foundation? [22:55:15] example? [23:00:15] Avengium, Miraheze Phabricator or Wikimedia Phabricator, but yeah Wikimedia might be better [23:00:27] https://phabricator.miraheze.org/T5183#109661 Avengium [23:00:28] [url] ⚓ T5183 Extension:CommentStreams | phabricator.miraheze.org [23:00:29] or what Hispano76 said [23:03:50] What example are you requesting Hispano? [23:09:43] The wiki where i use it is this. I didn't see the formatting last time i tested it Hispano76 https://avengium.miraheze.org/wiki/P%C3%A1gina_nueva [23:09:44] [url] Página nueva - Avengium | avengium.miraheze.org [23:12:36] I don't understand. What did hispano76 said? [23:21:34] Faltan crear los códigos de Mediawiki:Commons.js y Mediawiki:Commons.css y otras cosas que necestaría revisar [23:25:31] dmehus, [23:42:39] Ah. Interesante. No lo sabía [23:43:16] No me pareció leer en la página de ayuda que hubiera que escribir manualmente texto en css y js