Admin mode rewrite + env + gitignore - #71
Conversation
|
CodeAnt AI is reviewing your PR. |
codeant-ai
Bot
added
the
size:S
Sequence DiagramShows the simplified admin-mode toggles (/on and /off) and the single admin dashboard entry (/admin /admin_dashboard). The PR centralizes admin access, updates dashboard callbacks, and ensures toggles always update the stored user adminModeOn state and the persistent admin menu reflects the current mode. sequenceDiagram
participant Admin
participant Bot
participant UserStore
Admin->>Bot: /on (enable admin-mode view)
Bot->>UserStore: set user.adminModeOn = true
Bot-->>Admin: "🔧 Admin Mode Enabled"
Admin->>Bot: /admin or press Admin Dashboard
Bot->>UserStore: get user
Bot-->>Admin: sendPersistentAdminMenu (shows Mode Toggle status: ON)
Admin->>Bot: press Mode Toggle OFF (callback)
Bot->>UserStore: set user.adminModeOn = false
Bot-->>Admin: "👤 Admin Mode Disabled"
Generated by CodeAnt AI |
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughUpdates Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| const user = getUser(ctx); | ||
| // Block if not admin, or if admin is in user-mode (/on) | ||
| if (!ADMIN_IDS.includes(Number(user.id)) || user.adminModeOn) { await ctx.answerCbQuery('Admin only.'); return; } | ||
| if (!ADMIN_IDS.includes(Number(user.id))) { await ctx.answerCbQuery('Admin only.'); return; } |
There was a problem hiding this comment.
Suggestion: The help_tab_admin handler only checks whether the user is in ADMIN_IDS, but the surrounding comments and buildHelpPages logic treat user.adminModeOn as a "user-mode (/on)" flag that should hide admin content; as a result, when an admin has toggled user-mode on, tapping the "Admin Help" button still routes through help_tab_admin and calls sendHelpMenu(ctx, user, 6), which silently falls back to the non-admin help page and makes the "Admin Help" button behave inconsistently with its label and comment. Adding a user.adminModeOn check to the guard makes this handler correctly block admin help while in user-mode, matching the rest of the admin-mode logic. [logic error]
Severity Level: Major ⚠️
- ⚠️ Admin Help button shows generic user help when user-mode.
- ⚠️ User-mode toggle semantics inconsistent for admin help navigation.| if (!ADMIN_IDS.includes(Number(user.id))) { await ctx.answerCbQuery('Admin only.'); return; } | |
| if (!ADMIN_IDS.includes(Number(user.id)) || user.adminModeOn) { | |
| await ctx.answerCbQuery('Admin only.'); | |
| return; | |
| } |
Steps of Reproduction ✅
1. Start the bot and log in as an admin whose Telegram ID is in `ADMIN_IDS` (checked in
`isAdmin(ctx)` and `requireAdmin(ctx)` in `index.js` around lines 695–706).
2. Open the Admin Panel from the main menu so that a message containing the `Admin Help`
button (`callback_data: 'help_tab_admin'`) is sent; this button is created in
`menu_admin_tab` at `index.js:4581–4592`.
3. In the same DM, run the `/on` command (`bot.command('on', ...)` at
`index.js:3212–3216`), which sets `user.adminModeOn = true` for the current admin user.
4. Tap the existing `Admin Help` inline button, which triggers
`bot.action('help_tab_admin', ...)` at `index.js:4218–4223`; because the current guard
only checks `ADMIN_IDS` and not `user.adminModeOn`, it calls `sendHelpMenu(ctx, user, 6)`,
but `buildHelpPages(user)` (around `index.js:2335+`) computes `adminUser =
ADMIN_IDS.includes(user.id) && !user.adminModeOn`, so with `adminModeOn === true` there is
no page 6 and `sendHelpMenu` silently clamps to the user help page (page 5). The button
labeled "Admin Help" thus shows the non-admin help page instead of blocking access while
in user-mode.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** index.js
**Line:** 4221:4221
**Comment:**
*Logic Error: The `help_tab_admin` handler only checks whether the user is in `ADMIN_IDS`, but the surrounding comments and `buildHelpPages` logic treat `user.adminModeOn` as a "user-mode (/on)" flag that should hide admin content; as a result, when an admin has toggled user-mode on, tapping the "Admin Help" button still routes through `help_tab_admin` and calls `sendHelpMenu(ctx, user, 6)`, which silently falls back to the non-admin help page and makes the "Admin Help" button behave inconsistently with its label and comment. Adding a `user.adminModeOn` check to the guard makes this handler correctly block admin help while in user-mode, matching the rest of the admin-mode logic.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.| const user = getUser(ctx); | ||
| // Block if not admin, or if admin is in user-mode (/on) | ||
| if (!ADMIN_IDS.includes(Number(user.id)) || user.adminModeOn) { await ctx.answerCbQuery('Admin only.'); return; } | ||
| if (!ADMIN_IDS.includes(Number(user.id))) { await ctx.answerCbQuery('Admin only.'); return; } |
There was a problem hiding this comment.
Suggestion: The menu_admin_tab callback currently blocks only non-admin users, but the comment and mode-status text treat user.adminModeOn as a "user-mode (/on)" flag that should also suppress admin controls; without checking user.adminModeOn, an admin who has turned user-mode on (via /on or the Mode Toggle buttons) can still open the full Admin Panel from any stale "Admin Panel" button, undermining the purpose of user-mode as a safe, user-view-only mode. Including user.adminModeOn in the guard ensures that when user-mode is active, the Admin Panel cannot be opened until the admin turns it off again. [logic error]
Severity Level: Major ⚠️
- ⚠️ User-mode still allows opening full Admin Panel.
- ⚠️ Admins may mistakenly think admin controls are disabled.| if (!ADMIN_IDS.includes(Number(user.id))) { await ctx.answerCbQuery('Admin only.'); return; } | |
| if (!ADMIN_IDS.includes(Number(user.id)) || user.adminModeOn) { | |
| await ctx.answerCbQuery('Admin only.'); | |
| return; | |
| } |
Steps of Reproduction ✅
1. Start the bot and log in as an admin whose ID is in `ADMIN_IDS`, then open the main
menu page 2; `mainMenuKeyboard` at `index.js:880–899` adds a `🔧 Admin Panel` button with
`callback_data: 'menu_admin_tab'` for admins.
2. Tap `🔧 Admin Panel` to trigger `bot.action('menu_admin_tab', ...)` at
`index.js:4581–4592`, confirming that the Admin Panel opens with admin controls and shows
the mode status line.
3. In the same DM, run the `/on` command defined at `index.js:3212–3216`, which sets
`user.adminModeOn = true` for this admin, putting them into "user mode" according to the
mode status string in `menu_admin_tab` and the logic in `buildHelpPages` and
`userMainMenuKeyboard` (which hide admin UI when `adminModeOn` is true).
4. Tap the existing `🔧 Admin Panel` button again; because `menu_admin_tab` currently only
checks `ADMIN_IDS` and does not consider `user.adminModeOn`, the handler still opens the
full Admin Panel (including `Admin Dashboard`, `Admin Help`, and other admin actions)
while `user.adminModeOn === true`, contradicting the user-mode design used elsewhere in
`index.js`.Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** index.js
**Line:** 4584:4584
**Comment:**
*Logic Error: The `menu_admin_tab` callback currently blocks only non-admin users, but the comment and mode-status text treat `user.adminModeOn` as a "user-mode (/on)" flag that should also suppress admin controls; without checking `user.adminModeOn`, an admin who has turned user-mode on (via `/on` or the Mode Toggle buttons) can still open the full Admin Panel from any stale "Admin Panel" button, undermining the purpose of user-mode as a safe, user-view-only mode. Including `user.adminModeOn` in the guard ensures that when user-mode is active, the Admin Panel cannot be opened until the admin turns it off again.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
|
CodeAnt AI finished reviewing your PR. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
index.js (1)
4453-4467:⚠️ Potential issue | 🟡 MinorMode-toggle actions should refresh the persistent admin menu immediately.
These handlers change state and reply, but they don’t re-render the persistent admin menu header, so ON/OFF status can remain stale until another navigation action.
🔧 Proposed fix
bot.action('admin_cmd_mode_on', async (ctx) => { if (!requireAdmin(ctx)) return; await ctx.answerCbQuery('Admin mode enabled'); const user = getUser(ctx); user.adminModeOn = true; await ctx.reply('🔧 Admin Mode Enabled'); + await sendPersistentAdminMenu(ctx, user); }); bot.action('admin_cmd_mode_off', async (ctx) => { if (!requireAdmin(ctx)) return; await ctx.answerCbQuery('Admin mode disabled'); const user = getUser(ctx); user.adminModeOn = false; await ctx.reply('👤 Admin Mode Disabled'); + await sendPersistentAdminMenu(ctx, user); });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@index.js` around lines 4453 - 4467, The admin toggle handlers ('admin_cmd_mode_on' and 'admin_cmd_mode_off') update user.adminModeOn but do not refresh the persistent admin menu header, leaving the displayed ON/OFF stale; after setting user.adminModeOn (and after await ctx.answerCbQuery / ctx.reply) call the function that re-renders the persistent admin admin menu/header (e.g., renderPersistentAdminMenu(ctx, user) or updateAdminMenuHeader(ctx, user)) so the UI reflects the new state immediately—if no such helper exists, extract the menu/header rendering logic into a function and invoke it from both handlers right after updating getUser(ctx).adminModeOn.
🧹 Nitpick comments (1)
index.js (1)
4221-4221: Inline comments are now out of sync with the guard logic.Both comments mention blocking admins in user-mode, but the conditions only check admin identity. Please update comment text to match runtime behavior.
Also applies to: 4584-4584
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@index.js` at line 4221, The inline comment near the guard that checks ADMIN_IDS and user.id is misleading (it says it blocks admins in user-mode but the runtime only checks admin identity); update the comment text adjacent to the guard using ADMIN_IDS and user.id (and the similar guard around the other occurrence) so it accurately describes that the code is denying access to non-admin users or that it only checks admin identity rather than blocking admins in user-mode; ensure both places (the guard that calls ctx.answerCbQuery('Admin only.') and the other similar check) have matching, correct comments describing the actual behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@index.js`:
- Around line 1912-1913: The /on and /off commands and their copy are
inconsistent with the admin-view gating: the commands set/announce adminModeOn =
true but visibility checks use !user.adminModeOn, so enabling behaves like
user-mode; fix by making the semantics consistent—either flip the command
behavior or (preferred) flip the predicates and copy so adminModeOn === true
means admin view is shown: update the command descriptors ("Enable admin mode
view"/"Disable admin mode view") and the announcement text where /on and /off
are handled to match that meaning, and replace occurrences of the inverted
checks (instances of !user.adminModeOn) with user.adminModeOn across the
codebase (search for the symbol adminModeOn and all places using
!user.adminModeOn) so gating, UI, and messages are aligned.
---
Outside diff comments:
In `@index.js`:
- Around line 4453-4467: The admin toggle handlers ('admin_cmd_mode_on' and
'admin_cmd_mode_off') update user.adminModeOn but do not refresh the persistent
admin menu header, leaving the displayed ON/OFF stale; after setting
user.adminModeOn (and after await ctx.answerCbQuery / ctx.reply) call the
function that re-renders the persistent admin admin menu/header (e.g.,
renderPersistentAdminMenu(ctx, user) or updateAdminMenuHeader(ctx, user)) so the
UI reflects the new state immediately—if no such helper exists, extract the
menu/header rendering logic into a function and invoke it from both handlers
right after updating getUser(ctx).adminModeOn.
---
Nitpick comments:
In `@index.js`:
- Line 4221: The inline comment near the guard that checks ADMIN_IDS and user.id
is misleading (it says it blocks admins in user-mode but the runtime only checks
admin identity); update the comment text adjacent to the guard using ADMIN_IDS
and user.id (and the similar guard around the other occurrence) so it accurately
describes that the code is denying access to non-admin users or that it only
checks admin identity rather than blocking admins in user-mode; ensure both
places (the guard that calls ctx.answerCbQuery('Admin only.') and the other
similar check) have matching, correct comments describing the actual behavior.
1 participant
User description
Motivation
/adminis the single admin entry and admin-mode toggles always behave predictably.Description
index.jsso/onsetsadminModeOn = trueand replies🔧 Admin Mode Enabled, and/offsetsadminModeOn = falseand replies👤 Admin Mode Disabled, and those toggles always work for admins./admin_help,/admin_dashboard,/adminmode, and a few legacy admin_mode handlers) and keptbot.command('admin', ...)as the single admin entry that opens the Admin Dashboard.callback_data: admin_dashboard, the persistent admin menu shows the requested sections (Users & Stats, Giveaways, Promo Tools, System Tools, Mode Toggle) and header shows ON/OFF status..gitignorefile with the requested rules to exclude.env,*.env,logs/,node_modules/, temp/cache/build dirs, and common system files, and updated repository metadata (.git/configand.git/HEAD) to set the remote togit@github.com:gamblecodezcom/Runewager.gitand default branch tomain.Testing
npm run checkand it completed successfully.npm testand all tests passed (33/33passing).BOT_TOKEN=123:TEST ADMIN_IDS=1 node index.jsand the bot started with expected runtime message..gitignoreis excluding.envand logs withgit check-ignore -v .env logs/example.logwhich returned the .gitignore matches.Note: I could not import the Android
.envfile because the provided source path was not present in this environment, so the.envfile was not copied (per your instructions it should not be committed anyway). READY FOR PUSH — You may now run:git add .
git commit -m 'Admin mode rewrite + env + gitignore'
git push origin main
Codex Task
CodeAnt-AI Description
Unify admin dashboard entry and simplify admin-mode behavior
What Changed
Impact
✅ Single admin dashboard entry in menus✅ Consistent admin-mode feedback messages✅ Admin actions available while testing in user mode💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Summary by CodeRabbit
Improvements
Removed