After the previous Lumos Reparo cleanup, two real-world Undernet issues showed up during production-style testing.

They were small on paper, but important in practice:

1. Mixed-case channels could be treated as unknown by chanset.
2. userinfo was documented as admin-level but still required Master in code.

Both are now fixed, tested, and aligned with the current behavior expected by Mediabot v3.

---

🐛 Bug 1 — Mixed-case channel names in chanset

The issue appeared on an Undernet channel named:

#WatchDog.Test

Running:

m chanset +UrlTitle

from inside that channel returned:

Unknown channel #WatchDog.Test

The channel existed in the database, the bot was on it, and the user was properly authenticated.

So the problem was not the database.
It was not auth.
It was not Acura.
It was channel name resolution.

---

🔍 Root cause

channelSet_ctx() resolved the target channel with a lowercase key only:

my $k = lc($target_channel);
unless (exists $self->{channels}{$k} && $self->{channels}{$k}) {
    botNotice($self, $nick, "Unknown channel $target_channel");
    return;
}

That works fine when every channel is lowercase.

But for a channel cached as:

#WatchDog.Test

the code looked for:

#watchdog.test

and failed.

Classic case bug. Very IRC. Very annoying.

---

✅ Fix 1 — Accept exact-case first, lowercase fallback second

chanset now resolves the channel more safely:

my $k = lc($target_channel);
my $channel = $self->{channels}{$target_channel} || $self->{channels}{$k};

That means both cache styles work:

#WatchDog.Test
#watchdog.test

No schema change.
No database migration.
No behavior change for lowercase channels.

Just a proper fix for mixed-case IRC channel names.

---

🧪 Test added

A regression test was added:

343_chanset_mixed_case_channel.t

It checks that:

channelSet_ctx accepts the exact-case channel key
channelSet_ctx still keeps the lowercase fallback
channelSet_ctx no longer requires lowercase-only cache keys

This protects #WatchDog.Test and any future mixed-case channel from regressing.

---

🐛 Bug 2 — userinfo was documented as admin but required Master

The help table already said:

userinfo|userinfo <nick>|admin|Show information about a user.

But the implementation still had:

$ctx->require_level('Master') or return;

So a real global Administrator could be authenticated and still get:

Your level does not allow you to use this command.

That was inconsistent.

If the command is documented as admin-level, the code should enforce admin-level.

---

✅ Fix 2 — userinfo is now global Administrator+

userInfo_ctx() now requires:

$ctx->require_level('Administrator') or return;

This matches the internal help table and the expected operational model:

Owner       allowed
Master      allowed
Administrator allowed
lower levels denied

This is a global-level check, not a channel-specific privilege check.

---

🧪 Test added

A second regression test was added:

344_userinfo_admin_level.t

It checks that:

userInfo_ctx requires Administrator
userInfo_ctx no longer requires Master
the internal help table documents userinfo as admin-level

So the documentation and the code now stay aligned.

---

🔒 What was not changed

This patch intentionally does not change DCC CHAT access rules.

The logs also showed:

DCC CHAT from acura: insufficient level (Administrator=2) - ignored

That is a separate security policy.

For now, DCC access remains stricter.
This patch only fixes the confirmed inconsistency in userinfo.

---

✅ Result

This patch improves real-world admin usability without touching the database:

mixed-case channels no longer break chanset
userinfo matches its documented admin-level access
new regression tests protect both fixes
no schema change
no migration

---

🪄 Spell of the day

Lumos Reparo II!

A little more light on two annoying shadows:

#WatchDog.Test now behaves like a real channel
Administrator users can use the admin command they were promised

Mischief managed — again. 🧙‍♂️✨

My pleasure ;)