In T434878#12218438, @Yazn_albalawi wrote:

And if someone wants to empty their old account, a request page for emptying old accounts could be created.

Hi @Praffq, Are you still working on this task?

I removed the selected_wordmark feature, and now arzwiki relies solely on local_wordmark.

In T426539#11928899, @Novem_Linguae wrote:

@Gerges. Please log out and back in to reset your token. It is dangerous to post your token in screenshots since it can be used to impersonate you.

Thanks @Praffq.

How do I give myself or someone else this badge? Oh, I think it's only for administrators, you can do that, right?

Thanks @sanjaisid, and sorry for the delay.

Hi @Praffq, Are you still planning to submit a new pull request instead of reopening the closed one?

Hi @Aklapper, thanks for the thoughtful feedback.
The goal of Arabic-Sites is to make it easier to track tasks that directly impact Arabic Wikimedia projects, as they are currently scattered and hard to follow (e.g., UI issues, RTL bugs, localization gaps, editing experience issues).
This tag will help contributors discover relevant issues, follow ongoing work, and coordinate efforts more effectively.
For now, I will take responsibility for adding the tag to relevant tasks. In the near future, we also plan to attract more Arabic-speaking volunteers to watch and maintain these tasks.

@Praffq, You can use via Toolforge: wikitech:Help:Toolforge/Redis
It’s a better fit because it provides a shared, persistent queue, supports list operations, and works well if we scale to multiple servers. It also handles reconnections more reliably using Last-Event-ID.
Additionally, this task is mainly about reducing load on the JVM container, and moving the event buffer to Redis helps offload memory and connection pressure from the application itself.

@Praffq, What will you do about that?

Architectural Note: Since the server currently maintains a single global EventSource connection to Wikimedia and broadcasts to all SseEmitter clients, handling individual client catch-ups requires either caching recent events in memory/Redis or allowing clients to fetch missed events via a separate REST endpoint before joining the live stream again.

@Praffq, Thanks :)

@Nemoralis, You can proceed with it, and thank you. If any assistance is needed, please feel free to ping me in the channel #wikimedia-operations on IRC (my nick is _Gerges).

Yes, I noticed this; see pull 44.

Hi! 👋
Thanks for your contribution — I've reviewed your pull request and approved it. Great work!

Thank you for tagging this task with good first task for Wikimedia newcomers!

Hi @Praffq, I cannot grant you rollback permissions, but I added a variable REQUIRE_ROLLBACK_RIGHT, set its value to false, to bypass the validation check.

I have submitted a pull request:
https://github.com/wiki-connect/wikimonitor/pull/42

This is an example:

In T420850#11758561, @Praffq wrote:

Hey @Gerges , When I try to log in to WikiMonitor locally, the OAuth flow with Wikimedia completes successfully, but the app then rejects my login with a "no_rollback_rights" error. This happens because AuthController.java (line 52) calls mediaWikiService.checkAnyRollbackRights(username) which queries the Wikimedia API to verify the user is a rollbacker or sysop on at least one wiki, and my account (Praffq) doesn't have those rights. As a temporary workaround I've commented out the rollback rights check, but I wanted to ask, is there a recommended way to test locally without rollback rights, or a sandbox wiki where these rights can be obtained for development?

After thinking about it, I believe storing a user’s access token is extremely risky. It is better to store the refresh token on the user side for 30 days.

Hi @Praffq, Currently, there is no way to do this without rollback permission (See also: test2.wikipedia.org and test.wikidata.org). You can open a ticket explaining the problem in general terms so we can work on it in the future.