sorry-app/status-bar

Display your Sorry™ status updates on your website and helpdesk.

status-bar's Issues

Consolidate API calls

At the moment we make two separate API calls to grab both the notices and the brand. This however isn't required anymore as we have a single API point which gives us all the data we need.

We should consolidate these two requests into a single one.

Add jQuery.noConflict()

Consider making sure the jQuery a user might add doesn't bork any potential other instances of jQuery on the page or anything else using the $ namespace.

https://api.jquery.com/jquery.noconflict/

Is displayed behind other website content.

Latest build 4.0 seems to have a bad z-index on it and it's hidden behind the other content.

Add browser compatibility to README / Docs

We should display browser compat for the status bar as part of the README/Docs as at the moment we don't really list any quirks.

Before we do this we need to do some extensive QA cross-browser to get a feeling for what does/doesn't work in the latest build, we can then look at fixing any issues.

To make testing easier I opened a gh-pages branch on the project so we can access the test setup and see the bar publicly whenever we want.

http://sorry-app.github.io/status-bar/

Switch JSON source away from API and over to /index.json

We now provide a JSON version of the status page data for every status page direct from the pages root url. Such as the one at http://status.sorryapp.com/index.json

This is served up through out Static Assets CDN so it much, much more performant than hitting the dynamic API.

We should switch the plugin to use this new datasource as it'll be far more performant and scale a great deal better.

Momentary flash of unstyled content.

For a brief moment the bar seems to load without any styles applied before kicking in,

My guess is the call to get the CSS script is asynchronous and and we should put some mech in place to watch for when the file is actually added to the DOM and loaded before we progress forward.

No cache-control headers set

Hi,

I am getting a F rating in webpagetest.org because of the following:

FAILED - (No max-age or expires) - https://code.sorryapp.com/status-bar/4.latest/status-bar.min.js
FAILED - (No max-age or expires) - https://code.sorryapp.com/status-bar/4.latest/status-bar.min.css

can you guys please fix this?

GZIP Assets

One thing I've been meaning to do for a while is to have the grunt/release process GZIP the files before uploading them to AWS. The JS in its current form (with big fat jQuery) is around 100Kb which is far too large.

We should look at dropping in grunt-contrib-compress to zip the assets and then configure the aws_s3 task to set the correct headers and rename the files upon upload so the only available builds through the CDN are the gzipped ones.

Status bar requires `unsafe-inline` content-security-policy

We are enabling content-security-policy header on our web app, and SorryApp's status bar is not displayed. We see this CSP error in the console:

Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script

We don't want to enable script-src unsafe-eval in our policy, so for now we'll simply remove the status bar from our app.

But it would be nice if the status bar did not require unsafe-eval to work...

Correct version

Browsing http://code.sorryapp.com/status-bar/4.4.1/status-bar.min.js states

/* status-bar v4.4.0 | (c) 2018 SorryApp Ltd. |

Is this correct?

Add option to unable to delete

I want the status-bar to be shown fixed whenever there is a maintenance planned or ongoing without users being able to dismiss it (by clicking )

Would you be able to add this?
ps. I know I could probably overwrite this with CSS to display-block:none but I'm not sure that is the proper way.

Missing timezone reference in status-bar

This is confusing:

Im pretty sure I scheduled a maintenance at 7:45pm PDT, see

However my bar is saying:

June 4th 4:45am ... then I noticed this is probably showing my local time zone which is great actually, but it should state CEST to be more clear

Error: Uncaught (in promise): Cancel

When I open a random modal on my website and cancel it by using the ESC button I get the following message presented by status-bar.js:

ERROR Error: Uncaught (in promise): Cancel
    at resolvePromise (zone.js:814)
    at resolvePromise (zone.js:771)
    at zone.js:873
    at ZoneDelegate.webpackJsonp../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:421)
    at Object.onInvokeTask (core.js:4751)
    at ZoneDelegate.webpackJsonp../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:420)
    at Zone.webpackJsonp../node_modules/zone.js/dist/zone.js.Zone.runTask (zone.js:188)
    at drainMicroTaskQueue (zone.js:595)
    at ZoneTask.webpackJsonp../node_modules/zone.js/dist/zone.js.ZoneTask.invokeTask [as invoke] (zone.js:500)
    at invokeTask (zone.js:1540)
    at HTMLButtonElement.globalZoneAwareCallback (zone.js:1566)
    at HTMLButtonElement.d (status-bar.js:40656)

Any clue?

Allow customising of Content

As part of the core product, we allow people to personalise the content on their status page, either by switching language or by using the "content" section from within the UI.

I'd like to add similar functionality to the plugin. However, I need to give some consideration as to the best approach for this.

My current thoughts are around a few different options:

1. Provide data- attributes on the plugin definition which allow users to ad-hoc their own content.
2. Provide locale.json files for the plugin with a bunch of supported languages.
3. Provide a JS object configuration option similar to data-which allows you to add or personalize languages.
4. Pull language/content settings down through the API (not yet supported)

All of these have pros and cons, if anyone has any thoughts or opinions let me know.

truncate message on mobile

Please truncate the message on mobile like we do on desktop too:

Initialisation fails when Page ID is numeric

Contacted by a customer today who was receiving an error when installing the plugin on to their site.

Uncaught TypeError: t.split is not a function
at Function.s.fn.statusBar.setup (status-bar.js:29250)
at status-bar.js:29278
at dispatch (status-bar.js:11007)
at g.handle (status-bar.js:10815)
at e (status-bar.js:21662)

Digging into the error in the initial conversation, it seems that by random bad luck their Page ID is 100% numeric, with no letters in it. This results in pages.split() erroring, as it's an integer and not a string.

Include subject line in the displayed message.

A customer has mentioned that it'd add some clarity if the plugin displayed the subject line of the notice along with the synopsis content, as without it the message can lack context and be a little confusing.

README jQuery no longer required

The README, and also the docs site both state that jQuery is required for the plugin, but this is no longer true as we bundle it ourselves into the package using Browserify so it can safely be dropped as an external dependency.

Support url missing target blank property

This has nothing to do with the status-bar really but I wanted to post this anyway:

I have the following code on my maintenance page, however the support link does not have a target="_blank" property so my browser is blocking it for not allowing it to load insecure content. (I know it should be behind https but the service does not provide this option yet)

<li class="support-link-url">
    <!-- Conditionally append mailto: and tel: for appropriate actions. -->
    <a href="http://support.mydomain.com">http://support.mydomain.com</a>
</li>

Could you guys add a target blank to these links? Thanks!

Add Raven-JS Dependancy

At the moment we load Raven using a little JS hook within the plugin, this is an old approach before we added Browserify and the ability to bundle dependencies safely into the package.

We should look to move Raven-JS into the package using NPM and Browserify.

Notices not display in < IE10

All IE versions prior to IE10 are not displaying the notices.

I believe that this is probably related to their lack of support for cross-domain AJAX requests, which means the call to get the notices is failing.

We do include a JS Monkey-Patch to try and work our way around this however it doesn't appear to be solving the problem.

Icons not loading in IE 10/11

Recent round of browser testing after the style changes show that the icons aren't loading properly in Internet Explorer 10/11 and instead we get the underlying content char.

Ellipsis '...' omission on truncated text not working

We've had a customer suggest that when truncating the message text we should use a '...' omission at the end, to better indicate that there is more to read.

Utilise the new API filter/search options

We recently published some improvements to the API which allows the filtering of notices, so we can have the server only return the notices we want, rather than returning them all and filtering within the JS client.

This should be more performance, and also drop the amount of Bandwidth required.

Allow easy change of the API endpoint for dev/staging

We often find ourselves wanting to connect the status-bar plugin to the development or staging environments rather than hitting the production endpoint.

I think we need to consider adding an additional data attribute which allows developers to quickly switch endpoints without having to touch the source code.

<div class="sorry-status-bar" data-status-bar-for="" data-status-bar-endpoint="https://..."></div>

By default the status bar would use the production endpoint should one not be provided as a data attribute.

Add multi-language support

We've had lots of requests from customers to make the plugin support multiple languages, picking up that used by the status page itself.

Add support for 'planned' notices.

We recently launched planned maintenance as a feature into the product and with it a new option on the API to allow us to determine the type of notice which is being returned.

As it stands the plugin only displays unplanned notices, as it filters the notices to display only those with the open state, which doesn't apply to planned notices which use underway.

In the simplest form, we need to change the state filter so that both planned and unplanned notices are handled by the plugin, displaying both upcoming and current notices.

Update README Version

At the moment the README is using an outdated version number, we should update this to bring it back into line. Perhaps we should consider publishing just latest.js which doesn't even lock down to the latest major number? That would make the upgrade path for customers likely a little easier?

The 'more' button drops onto a second line.

I've also seen this on the MIS.

Using custom location doesn't work

For some reason when using the custom location snippet, rather than having the application automatically inject the DOM container the script doesn't pick up the page ID correctly, and the AJAX request gives a 404.

I have a hunch that this is to do with the way we're adding the data/options to the div when injecting it, and when it's hard-coded they're not present.

Add support for additional states

We've got some new notice states coming to the service soon, and we'll want to add support to the status bar plugin for these.

• Investigating
• Identified (Replaces Open)
• Recovering

There are also new states for closed/resolved notices, but the plugin doesn't currently support those so we'd need not worry about it.

Creates space at the top of the page

We have had a report from a customer to say that they have an issue with the latest build whereby it creates a small gap at the top of the browser window even when no notices are being displayed.

I've attached a redacted screenshot which they were kind enough to send over. We need to try and repo this ourselves and then patch it.

Doesn't work in Edge

Seems the status-bar won't show in Edge (87.0.664.66, Chromium-based). Could be a CORS issue.

Add Subresource Integrity to the readme

SRI is a new W3C specification that allows web developers to ensure that resources hosted on third-party servers have not been tampered with. Use of SRI is recommended as a best-practice, whenever libraries are loaded from a third-party source.

It would be great to provide the sha256 hashes for each version in the readme

Add support for filtering / targeting specific components.

We've had a few customers request that they'd like to configure the component to only display notices for specific components, rather than all notices.

Initial thoughts on this are that we want to add data attributes to the tag which accepts the component names of IDs, something like data-only-components="1,4,6" for instance.

These IDs would then be applied to the notice collection, only displaying notices which apply to these components directly.

Doesn't load when page opened locally using file://

Because we use schemaless URLs on both the Javascript include and API requests it tries to use the file:// schema, which obviously doesn't work.

We need to amend both the docs for installation to recommend using the https:// schema for the JS include and also update the source so it uses https:// for the endpoint.

Breaks when used with Hello Bar.

When used on a site such as our own along with HelloBar it does not appear, and instead is displayed hidden behind the HelloBar.

We need to consider if there is anything we can do to help prevent this from happening.