[Feature request] Ability to mark communites and domains as QA/draft

[olw-medcom]

Hey there,

We have adapted a structure in our test bed where we have one QA community and one real community. Like this:

And similarly for domains.

I was wondering if it's possible to have some sort of setting on a community and domain so that instead of having to manually name it [QA] the test bed would do that. It doesn't have to be [QA]. Just some sort of naming indicating that this is not meant for vendors to use i.e. draft/test/staging etc.

Furthermore the following features based on that setting would be nice:

• Marking the QA community/domain with a different color (perhaps grey) in the overview tables and a column with something like QA?

- Disabling the ability to allow self-registrations to the QA community - Disabiling the ability to create organizations in the community except the admin organization

Maybe you have more suggestions based on such a feature?

[costas80]

Hi @olw-medcom. The key point I think is this one:

Disabling the ability to allow self-registrations to the QA community

You can select which of the Test Bed's communities are presented for self-registration in the community details (note that the screen differs a bit in the latest nightly build):

Setting this option to "Not supported" means that this is not presented in the self-registration screen. Doing so there is then no question about vendors accessing it or anything similar. This means also that ...

Disabiling the ability to create organizations in the community except the admin organization

... this also is not relevant in my opinion anymore, given that only users having access to the community (your accounts, plus the ones you manually register as Test Bed or community administrator) have access to the community. In fact given that this is a QA community for internal verifications (if I get it correctly), this will only include the community's implicit admin organisation, plus organisations that you create for your own testing purposes.

Based on the above, the other feature you ask for ...

Marking the QA community/domain with a different color (perhaps grey) in the overview tables and a column with something like QA?

... becomes less relevant as it would only be perceived by the Test Bed administrator account, given that a listing of communities is only ever presented in the self-registration screen and to the Test Bed administrator (in the page you screenshotted). We could always foresee something like a tag feature for communities and/or domains if meaningful, but as this is only for the benefit of the Test Bed administrator it seems a bit niche no?

What are your thoughts based on the above?

[costas80]

Note that if you're running a recent nightly build, the option to enable/disable self-registration is as follows:

There are several new options for self-registration in the works (completed but not yet released in a stable release), including a reorganisation of the self-registration settings to make them more intuitive:

[olw-medcom]

Hey @costas80 you are correct in that it is only for the test bed administrator. It's more the fact that it feels a bit unsafe to navigate around production test suites and QA test suites. I foresee a future where accidently a test suite is uploaded incorrectly. So it's just for peace of mind, I understand if it's not something you want to support.

[costas80]

Thanks for clarifying. As this is for your own protection so to speak, then I think the most meaningful move would be to avoid using the Test Bed administrator account. Use it only to manage overall settings and to create communities/domains, but from that point on just use community admin accounts. Even for the health checks, in the next release we will also have on-login notifications for the community admins, even though they will not be able to manage system-level settings (this is part of extending health checks to also include test services registered in the domains that are relevant to specific communities rather than overall service health).

Besides this you always get confirmation popups for anything that would have any impact (also test suite updates) and I'm thinking that even with a tag at the level of the community, you may still become unaware of it depending on where you are. For example, if you're already connected to a community and are navigating its domain's specifications, you wont have a similar visual clue that this is "production" vs "QA". We could envisage a persistent reminder that e.g. "this is production" but it still seems a bit odd as a feature (this is usually the kind of thing all users would see as a persistent banner - e.g., "The system will go down for maintenance at X time" kind of thing).

[costas80]

Hmm, maybe what would be more meaningful and safe would be the ability to "lock" a specific community's configuration. As Test Bed or community administrator you could choose to lock a community, which means that no changes can be made to the community settings or the settings of the linked domain(s). The result of doing this could be:

• Adding a locked indicator next to the community and domain(s) in listings.
• Adding a locked indicator on all related community/domain screens.
• Requiring that the community is explicitly unlocked before any change takes place.

With such a feature you could have your production config locked at all times, and explicitly unlock it only when you know you want to make changes to it. It is still fairly high effort vs the expected benefit (all screens/edits would need to be protected and displayed differently depending on whether they are editable or not) but this sounds safer no?

[olw-medcom]

Huh, I quite like that idea, I do see it being a hard feature to implement as you would also have to safeguard the API requests and so on. I guess it depends on how your code is structured.
That said I do like the idea and would find it beneficial.

[costas80]

Ok - so I'll record this feature request on our backlog as such: ability to lock a community to prevent accidental updates to its settings or the settings or linked domain(s). Given this, do you still find the tagging/marking of communities meaningful (as per your initial suggestion)?

[olw-medcom]

Sounds great, thank you costas, and no with this feature I am not in need of tagging/marking communites ^^

[costas80]

Thanks for confirming! I'll let you know here when this feature is available on the nightly build.