feat: allow admin to set default channel

[hickey]

A MeshChat administrator now has the ability to define the default channel that a newly logged in user is placed into. This requires that the administrator set the value default_channel in the configuration file. Setting default_channel to an empty string ('') will continue using the legacy setting of 'Everything'.

Signed-off-by: Gerard Hickey hickey@kinetic-compute.com

Closes #5

[hickey]

Ideally I should be testing this tonight. Changes should be available on http://wt0f-1.local.mesh:8080/meshchat this evening.

[hickey]

Found an issue with the refactoring of the config API call. Fixed and redeployed the package to WT0F-1. Current version is v20231121-default-channel-acd2e7c.

[gerner]

Broadly this seems fine. I have some questions that mostly come down to documentation/release notes.

[gerner]

if this wasn't already in the config before, how was it used?

[hickey]

protocol_version is not used today. It is in the config file, but not in use. Never has been used from what I can tell.

The config API was only really giving the MeshChat version, node name and zone name to the front end code. I am adding more config values so that more features can be enabled on the front end code without having to hard code values into the front end. This will provide a single source of configuration for all of MeshChat.

In the relatively near future (next version or two), I expect that protocol_version will be used to insure that an old API (either an old API package or cgi-bin scripts that did not get updated correctly) is not being used and/or adapt to the older API. This will probably come into to play as the message DB synchronization is improved.

[gerner]

looks like this doesn't come up (at least not in this PR). what do you plan to do with this?

I love the idea of useful config flags to help development and support. I just want to be explicit about the purpose for these kinds of features.

[hickey]

I am not sure what you mean by it did not come up. I have been using this code for a bit and it has been working for me. I did have a problem on the Javascript side where I was defining a function and a variable with the same name that was causing problems. That has been resolved, but I have not pushed code yet as I am debugging another issue.

The debug variable in the configuration file is used to turn on debugging in the backend code (not really there) and the debugging in the Javascript console in the front end. At some point it will probably be good to also turn the front end debugging on through a parameter on the URL line so that one does not have to modify the config file (or maybe does not have access to the file). This would allow debug logs to be created and submitted with bug reports to get a little more visibility into what a MeshChat instance is doing.

[gerner]

I just meant what's the debug flag for. I didn't see that flag get used elsewhere in this PR. Thanks for the info.

I agree about turning it on without changing config. One scenario I find myself running into again and again is supporting other people's installation. In these cases I need deep info about system state, but I don't have ssh access or the admin password. It would be very nice if I could just flip a query param flag and suddenly see things.

I guess we still need to build those things to show :)

[hickey]

I think the debug function is in the commits that I have not yet pushed. I am trying to resolve a problem where the value of a Javascript variable is not being copied to another context correctly.