Different private and public labels/names on the statuspage

[codeagencybe]

⚠️ Please verify that this feature request has NOT been suggested before.

• I checked and didn't find similar feature request

🏷️ Feature Request Type

UI Feature

🔖 Feature description

Add a seperate field for internal or public name for a test on the statuspage.
Sometimes one wants to add a test and visible on the public status page, but we don't want to show the same internal name we give to eg the server.
Or the server has internally a name convention I don't want to expose to public.

✔️ Solution

Having a seperate name or public label or something that is used for the statuspage would be nice.
When adding a new test, the "statuspage name/label" is optional.
If you don't use it, it uses the same value as the test name.
If you do use it, the status page will show that specific value.

❓ Alternatives

No response

📝 Additional Context

No response

[CommanderStorm]

Why would you not like to expose the naming convention to the status page?
I don't quite understand why this is something that would be valuable.

Rationale: Public Status pages should only be a subset of all monitors, most likely the ones which are relevant for the end-users

[josxha]

@CommanderStorm Here are more reasons to have this feature:

1. if a software is used multiple times, such as multiple database instances, the name displayed on the public status page should be as simple and understandable as possible. For example, just say "Database" on it. Further information, such as "Database Service XYZ" is unnecessary for the public viewer.

2. If different environments are used, like Production and Staging, it would be possible to add an explicit "Production" to the internal name, which could be hidden on the public dashboard.

3. information about which software is used for a service should not be displayed publicly, as it does not bring anything to the end user and could confuse them. For example, if I use nginx as a reverse proxy solution or for the website I use wordpress and name my monitor that way, it should not be mandatory to show this to the end user.
4. it may happen that different versions of a service are running (API v1, API v2). In this case, only the latest one should be displayed on the dashboard, but support should still be maintained for the older one. In this case, the versioning on the public status page could be removed.

Some of the use cases could be realized by using monitor tags. However, they are not always practical. As I understand it, tags are meant to be used in multiple monitors. If additional information is to be added to only one monitor, it does not make sense to create tags only for this one monitor.

[CommanderStorm]

Sounds reasonable.
PRs adding such functionality should add it to this modal:

which currently holds this content:

Here is our contribution guide: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md