[Feature Request] Webadmin module that shows user logs [$130] #729

New Issue

2026-10-05T04:41:15+02:00

adam commented

2026-10-05 04:41:15 +02:00

As the title says, a module that shows logs on the web interface. Obviously users can only view their own logs on their own networks. Users will have the option to enable this module or disable it for themselves.

Bounty

As the title says, a module that shows logs on the web interface. Obviously users can **only** view their own logs on their **own** networks. Users will have the option to enable this module or disable it for themselves. [Bounty](https://www.bountysource.com/issues/38593604-feature-request-webadmin-module-that-shows-user-logs)

adam commented

2026-10-05 04:41:16 +02:00

Part of the request kinda sounds like #325

Part of the request kinda sounds like #325

adam commented

2026-10-05 04:41:17 +02:00

Yes, but that module is not secure. Any user can see any of the logs. (I know this because I've tried it)

Yes, but that module is not secure. Any user can see any of the logs. (I know this because I've tried it)

adam commented

2026-10-05 04:41:17 +02:00

Big 👎 from me for admins being able to see any user's logs, especially queries. I currently have an nginx setup to browse my own text files, and would welcome a way to do it through znc's webadmin—👍 for the main idea—but as the admin I don't even want the ability to view users' log files from a root shell, let alone in a push-button interface.

Big :-1: from me for admins being able to see any user's logs, especially queries. I currently have an nginx setup to browse my own text files, and would welcome a way to do it through znc's webadmin—:+1: for the main idea—but as the admin I don't even want the ability to view users' log files from a root shell, let alone in a push-button interface.

adam commented

2026-10-05 04:41:18 +02:00

but as the admin I don't even want the ability to view users' log files from a root shell, let alone in a push-button interface

On second thought, I agree. I will edit the request to remove that

> but as the admin I don't even want the ability to view users' log files from a root shell, let alone in a push-button interface On second thought, I agree. I will edit the request to remove that

adam commented

2026-10-05 04:41:19 +02:00

I added another $100 to the bounty, bringing the bounty total to $130 and changed the title to reflect that.

I added another $100 to the bounty, bringing the bounty total to $130 and changed the title to reflect that.

adam commented

2026-10-05 04:41:19 +02:00

Is this still available to work on for the bounty?

Is this still available to work on for the bounty?

adam commented

2026-10-05 04:41:20 +02:00

Is this still available to work on for the bounty?

Yes it is. The current bounty is $130

> > > Is this still available to work on for the bounty? Yes it is. The current bounty is $130

adam commented

2026-10-05 04:41:21 +02:00

Great. I've developed a prototype that seems to do the job though it still needs refinement in the look and feel of the template.

Great. I've developed a prototype that seems to do the job though it still needs refinement in the look and feel of the template.

adam commented

2026-10-05 04:41:21 +02:00

I spun up a VPS to test the new module. Works great already. All that's needed are those look refinements. Also, maybe the option to change the timestamp format? Hide certain channels from the logs, like the *status user? Or separate the channels from the PMs? Something to think about

I spun up a VPS to test the new module. Works great already. All that's needed are those look refinements. Also, maybe the option to change the timestamp format? Hide certain channels from the logs, like the *status user? Or separate the channels from the PMs? Something to think about

adam commented

2026-10-05 04:41:22 +02:00

Changing the timestamp format would require modifying the lines being read and I don't believe that is pragmatic since the user is able to define their own formatting already as the logs are written. I don't see a practical way to deal with this situation. If the timestamp format was fixed in the logs then I could see a way to do so since it would be the same every time but as it is I don't see a reliable method of conversion from already written log files.

As for hiding or separating log types I see a similar problem. The user is able to define their own log paths so they could rearrange them however they so choose. The only viable option I saw to deal with every possible situation was to create a file browser for going through the directory hierarchy and viewing any logs that have been written under their user or network specific log directories. This means that organizing them beyond directories and files is impractical but it at least covers every conceivable user setup. Given how configurable ZNC is I felt this was the best compromise I could reach within reason.

As for the aesthetics I will try to clean it up a bit but this is not my specialty. It may be better done by someone more familiar with ZNC's CSS.

Changing the timestamp format would require modifying the lines being read and I don't believe that is pragmatic since the user is able to define their own formatting already as the logs are written. I don't see a practical way to deal with this situation. If the timestamp format was fixed in the logs then I could see a way to do so since it would be the same every time but as it is I don't see a reliable method of conversion from already written log files. As for hiding or separating log types I see a similar problem. The user is able to define their own log paths so they could rearrange them however they so choose. The only viable option I saw to deal with every possible situation was to create a file browser for going through the directory hierarchy and viewing any logs that have been written under their user or network specific log directories. This means that organizing them beyond directories and files is impractical but it at least covers every conceivable user setup. Given how configurable ZNC is I felt this was the best compromise I could reach within reason. As for the aesthetics I will try to clean it up a bit but this is not my specialty. It may be better done by someone more familiar with ZNC's CSS.

adam commented

2026-10-05 04:41:23 +02:00

Changing the timestamp format would require modifying the lines being read and I don't believe that is pragmatic since the user is able to define their own formatting already as the logs are written.

I understand. It's been so long since I actually used the log module that I forgot that users could specify their own timestamp formats under settings. My bad.

As for hiding or separating log types I see a similar problem. [....] This means that organizing them beyond directories and files is impractical but it at least covers every conceivable user setup.

This is fine as well. I'd rather have security first, then usability, then looking "pretty" last.

> Changing the timestamp format would require modifying the lines being read and I don't believe that is pragmatic since the user is able to define their own formatting already as the logs are written. I understand. It's been so long since I actually used the log module that I forgot that users could specify their own timestamp formats under settings. My bad. > As for hiding or separating log types I see a similar problem. [....] This means that organizing them beyond directories and files is impractical but it at least covers every conceivable user setup. This is fine as well. I'd rather have security first, then usability, then looking "pretty" last.

adam commented

2026-10-05 04:41:23 +02:00

Ok. It's now better organized. The only other thing I could think to add to the aesthetics is some kind of indicator as to whether the items in the file browser section are directories or files but that can largely be deduced from the names themselves so I don't know if this would be a valuable addition. Plus I'm not sure how I would go about implementing that. The usual method is to use icons but there do not appear to be any existing ones I can reuse from within ZNC itself.

Ok. It's now better organized. The only other thing I could think to add to the aesthetics is some kind of indicator as to whether the items in the file browser section are directories or files but that can largely be deduced from the names themselves so I don't know if this would be a valuable addition. Plus I'm not sure how I would go about implementing that. The usual method is to use icons but there do not appear to be any existing ones I can reuse from within ZNC itself.

adam commented

2026-10-05 04:41:24 +02:00

Could probably add a background-image and margin to fit it in using CSS, embedding the image itself as base64-encoded SVG in the stylesheet. Surely there's a free-licensed icon library one could pull from for such basic icons.

But it's been a long time since I touched any ZNC code, so take that suggestion with a grain of salt! It's just the first idea that comes to mind.

Could probably add a background-image and margin to fit it in using CSS, embedding the image itself as base64-encoded SVG in the stylesheet. Surely there's a free-licensed icon library one could pull from for such basic icons. But it's been a long time since I touched any ZNC code, so take that suggestion with a grain of salt! It's just the first idea that comes to mind.

adam commented

2026-10-05 04:41:25 +02:00

@dgw I'll look into it if it is asked for but I was planning to leave it be otherwise.

@dgw I'll look into it if it is asked for but I was planning to leave it be otherwise.

adam commented

2026-10-05 04:41:25 +02:00

@dgw it's easy enough to serve files from /files/ directory, no need for hacks like base64 in CSS

@dgw it's easy enough to serve files from /files/ directory, no need for hacks like base64 in CSS

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#729