Following the latest release, the Inbox disappeared from the main toolbar at the top of the Shotgun web/browser UI. I follow the Release Notes and saw the line item yesterday, so I had an idea that something was going to change. Was caught off guard though when I clicked the Inbox and was greeted by an error message stating: App Not Available.
I had to go to Apps > Manage Apps and then enable the visibility under the config tab for each permission group. That ability is fine, if you want to disable the app for certain groups…but why was that the default for the deployment? Wouldn’t it have been more appropriate to release it “visible” to all…which was the default behavior prior to release…and allow admins to disable visibility as they saw fit? Also, there were no docs (that I saw) regarding how this release was going to go. Would it be possible to have more verbose Release Notes in the future, and to include links to docs containing additional information on “how to” leverage the change being made?
We had a similar experience here, only the pref was ON for all our permission groups but random users from all permission groups (from Artist up to Admin) could still not see the Inbox.
It appears there’s something going on with the browser cache, as having our affected users log out and back in again revealed the app again for them.
Yeah, the app was Enabled…but all the permissions groups were unchecked under the Configure tab. I saw the same behavior you did. We have 2 instances here managed by 2 different teams, and when I went back through the process to show them how to get their Inbox back…all the permissions were checked (even though I’d only checked certain permissions at that point).
It’s unfortunate that it’s this buggy, given how important the Inbox is to how users communicate within the system.
We had a round with support, and learned this was a bug in yesterday’s deployment.
I think the issue they raised afterwards on the status page was related to this.
Thanks for your patience during this incident. While I can’t specifically address @brandon.bartlett comments on the Inbox App itself, I wanted share our incident postmortem with you.
@khosrow would you (SG) be able to provide any additional transparency into what the new process is that will protect against these kinds of issues moving forward? I see things like this cited in post mortems and release notes, and I’m curious what that means.
For instance, just related to Shotgun 8.23:
1 Release that states: Improvements to Shotgun testing for releasing more reliable updates.
3 Releases that state: Improvements to Shotgun team processes
3 Releases that state: Improvements to infrastructure to better and more reliably update Shotgun
In the case of this incident, the improvements are inside our CD pipeline and the order certain operations are performed prior to and during a deploy. I’m not sure I can be more specific without actually going into details about the code involved, unfortunately.
A Shotgun release can have two types of changes:
user facing code changes
non-user facing changes (they’re typically changes to test suites, or other infrastructure tooling)
Since we release Shotgun everyday, there are cases where a release doesn’t include a user-facing code change (like the ones you mentioned). And we decided to publish release notes regardless of type of change in a release. But we chose not to go into technical details for some cases.
Hope this provides the added detail you were looking for.
Just to add some additional context here- the change was intended to take place “quietly”, in other words, no changes to the functionality should have been noticeable unless you went and looked for it in the manage apps or permissions section.
The intent here was to give additional controls to remove the Inbox (and My Tasks, and the Media app) for those who wanted them (and went and configured those accordingly), but to not visibly change anything otherwise. As Khosrow posted above there was an issue with the development of the functionality that meant some of the code went live prematurely. I apologise for the disruption here, as I say the intention was for there to be no disruption whatsoever.
@khosrow, yeah that’s helpful. Thank you. Even something as simple as that is appreciated. The release notes lately have felt vague, and the copy/paste-descriptions haven’t helped with transparency. Given the issues with some of the recent releases, I’m sure others would appreciate (at least) that level or verbosity in the Release Notes and the Post Mortems.
@jack, totally get it. Best laid plans of mice and men…and all that. I can understand that, and had this been an isolated thing…I probably wouldn’t have posted anything. This, combined with the Notes issue a couple weeks ago, raised some concerns.
I’d also brought up issues with Release Notes in a support ticket, that @Beth fielded a little while back, citing concerns with having to search out info rather than being fed info. The current setup with a page per point release is nice…until the point value increases (8.22 to 8.23, for example)…then we have to search out, and follow, another page to get the regular info we used to be fed via mailing lists.
This community and this platform are terrific. Providing users with the opportunity and the tools to help people help themselves and others, and building a wealth of public knowledge…it’s open-sourcing support, and I’m all in favor of that. Just feels like, while we gained a lot when the Community was brought online, we lost something somewhere along the way…
I don’t want to belabor this. An update was released, it was broken, and it’s been fixed. Though, I’ve not found any docs related to this change. Are there docs available? If so, can a link be provided as an in-line reply to this thread to close the loop on this?
Thanks for this Brandon. What I can tell you is in this case there wouldn’t have been an associated release note because the change wasn’t supposed to have gone out (until today, actually, see here: 8.23 Release Notes - #12 by lampronf).
Generally speaking we’re trying to move away from features tied to specific point releases (for various reasons, but a big one is so that we can immediately roll back changes when we have to, as was done in both the instances you mentioned). We’re aware that makes it difficult to stay on top of what’s new, but what we’ve started doing to try and make up for that are a few things:
Targeted in-app messages to highlight new feature releases
Activating larger new features with specific timings (so we might deploy the code in an earlier version but not actually enable them right away) and then having some communications in advance of that
Ensuring that the release notes for each new point release also capture anything significant that went out in the previous release cycle (see here for example)
That’s not to suggest this is a perfect system of course, thanks for keeping us honest, and we do appreciate any further feedback or suggestions you might have to make this better. Ultimately we want to provide updates that help you do your jobs both in a timely and non-disruptive way, and we want you to know about them!
