nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Individual components subscriptions with disabled auto-subscriptions

Pierre-Nicolas Theisen

Hi,

On our StatusPage we disabled the ability for users to subscribe. Reason being that we want to gate the number of subscribers. To do so we disabled the "auto-subscription" option. The way we add subscribers is through the API.

Previously when disabling the "auto-subscription" option the "subscribe to individual components" option could still stay in the checked state, thus making it possible to create new subscribers to specific components even though "auto-subscription" was disabled. This is not the case anymore, when disabling "auto-subscription" the "subscribe to individual components" is also automatically disabled, making it impossible to manage individual components for our subscribers.

Is this the intended behavior and if so what is the rational behind tying both features together?

Thanks!

Accepted answers

Jesse Klein

Hello Pierre,

This is Jesse from the Statuspage support team. Thanks for reaching out in the community regarding subscribers and component subscriptions. I did some investigating on this and it does seem to be intended. In fact, it seems to be intended to lock down subscriptions as a whole when removing that setting, which is why they are tied together as a result. The logic behind this is that when you remove the ability to subscribe, you need to turn off the ability for users to change their component subscriptions. With that setting turned on, a user could change their subscriptions.

It does seem a bit strange that they would be tied together in this way. I can raise a feature request with the team to have them take a look at.

For now, if you keep the subscriptions turned on, you can instead remove the subscribe button by following the help guide here:

https://support.atlassian.com/statuspage/docs/css-and-javascript-snippets-for-customizations/

That would in turn, give you the same outcome you are looking to have. Hopefully that is helpful for you with not allowing users to subscribe themselves while still keeping the component subscriptions.

Regards,
Jesse

All comments

Jesse Klein

Hello Pierre,

It does seem a bit strange that they would be tied together in this way. I can raise a feature request with the team to have them take a look at.

For now, if you keep the subscriptions turned on, you can instead remove the subscribe button by following the help guide here:

https://support.atlassian.com/statuspage/docs/css-and-javascript-snippets-for-customizations/

Regards,
Jesse

Pierre-Nicolas Theisen

Hi Jesse thanks for the detailed answer.

I would go a step further with the Feature Request by asking to decouple the following three different concepts:

admin managed subscriptions
public subscriptions
component subscriptions

This would enable for an admin managed subscription use-case: admin having the ability to add subscribers and at the same time have the public subscriptions disabled. Additionally the choice of having component subscription could be used in both cases: in the case the admin is managing subscriptions and wants to create component specific subscriptions and in the case we want for every user to be able to self-serve component specific subscriptions.

We already applied the JS/CSS customization to remove the subscription options from the UI. Our concern at the time we did it is that the underlying subscription APIs were apparently still accessible. Making it possible for someone to use the APIs to subscribe even though the UI was masked. Would you be able to confirm this is still the case?

Thanks in advance!

Jesse Klein

Hi Pierre,

I'd be happy to extend off of that feature request. It might be better to discuss your use case in a support ticket itself but I was curious to learn more about it. Limiting subscriptions on a public plan does go against the spirit of the pubic page. It might be a tough ask on the development team to separate these things so I would love to understand more to add that additional context.

In regards to the underlying APIs, they technically would still be accessible but these would be undocumented APIs. Removing the button would remove any normal means of subscribing and if someone did use the API, they would be able to be unsubscribed once found.

Hopefully that information is helpful for you.

Regards,
Jesse

Pierre-Nicolas Theisen

Thanks Jesse, so I should probably open a support ticket to discuss our use-case in more detail and see if the product team would be willing to go in the direction of the feature request as explained above.

Thanks again!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

statuspage