Feature request

• [x] I confirm that this is a feature request rather than a question.

What problem does this feature solve?

The use of Docker greatly simplifies the process of deploying and updating web applications. Having an official Docker image would allow people to seamlessly integrate Statusfy into their software stack.

What does the proposed API look like?

N/A

How should this be implemented in your opinion?

I think it would be best if you set up automated builds so that you don't have to manually push the Docker image every time you make a change.

Are you willing to work on this yourself?**

Yes.

Feature request

Create a section in the documentation how to best run in a Docker Container Environment.

What problem does this feature solve?

Container will be the "only" way to run applications in the future. It seems the current statusfy commands are however not suited for this:

At least to my current knowledge, i would implement containerizing by mounting the "content" folder with the incidents to the host. So I can simply create and modify the files/incidents via a script or manually. So I would not be using the "new-incident" command (as this command is not available outside the container). This would however then require "npx statusfy build & npx statusfuy start" , in other words a reloading in the contianer. But this very hard to implement properly and leads to downtimes. Currently there is no "reloading" command (that could be triggered via a cronjob or that does the reloading itself).

I am a newbie with nuxt/vue: One solution for automatic reloading seems to run the app with "npx statusfy dev" in the container. What security implications and leakages does this have? Can someone please comment on this if this is the way to go and also include a short paragraph about best practices in the documentation about containerized usage. Thanks! And thanks for statusfy, really love it!

• [x] I confirm that this is a issue rather than a question.

Bug report

Version

0.3.0-alpha.4

Steps to reproduce

1. Create an incident with the date 2019-02-25T20:00:00.000Z on a server with timezone UTC.
2. View the Statusfy page on a computer with the timezone set to GMT+5 or greater (e.g. Pacific/Auckland)

What is expected?

The incident showing up under the Feb 26, 2019 heading.

What is actually happening?

The incident showing up under the Feb 25, 2019 heading.

Other relevant information

Note that the date itself of the incident is correctly shown in the current timezone, just not the location of the incident under the headings.

• Your OS: macOS 10.14.3
• Node.js version: 8.10.0
• Browser version: Version 72.0.3626.109 (Official Build) (64-bit)
• Browser timezone: Pacific/Auckland
• Server timezone: UTC
• Is this a global or local install? Local
• Which package manager did you use for the install? NPM

Feature request

I finally managed to update to 0.2.1 (had to force the version on npm) and added a couple of scheduled maintenance items for testing. I have the following comments:

• [x] I confirm that this is a feature request rather than a question.

How should this be implemented in your opinion?

1 - Adding a scheduled maintenance item is quick and simple, good work 2 - As previously mentioned, I'd rather have the "Scheduled maintenance" section displayed above the current status section. Reason is simple: as soon as you have more than a few systems listed, the "Scheduled maintenance" section requires scrolling and will be missed by many

3 - The Date/Time at which the Scheduled maintenance will happen is not visible enough. It should be made very large/visible, at least as much as the maintenance title 4 - I added some text to the event but that text is not visible anywhere:

---
title: Server upgrade
date: '2018-12-13T14:34:46.338Z'
scheduled: '2018-12-15T12:00:00.000Z'
duration: 30
severity: under-maintenance
affectedsystems:
  - site
  - helpdesk
  - documentation
resolved: false
---

Our hosting company has required that our main server is rebooted for software updates.

::: update under-maintenance | 2018-12-13T14:45:46.338Z
We have been informed that the expected duration of the maintenance is now 60mn.
:::

<!--- language code: en -->

The text "Our hosting company..." and the update text are not visible anywhere. You can't even click through to get to the details of the event like on regular incidents - although I would not want that either, that's not very handy. See point #5 below

5 - I would suggest each incident, whether standard or scheduled maintenance, displays the title, then the first 2or 3 lines of description and then a button can be clicked to expand in place (don't go to another page) to view the full text content of the incident including description and any subsequent update.

Looking forward to your comments, thanks for the update.

Best regards

Are you willing to work on this yourself?**

Feature request

• [x] I confirm that this is a feature request rather than a question.

What problem does this feature solve?

• You don't have to delete the incident file for each language manually. Currently you have to delete every file for each language by hand. This is pretty annoying and confusing if you use more than one language.

• You don't have to edit the incident file for each language manually. Small example: You create a new incident and you are using 4 languages (which means you have 4 files). Now you want to change the value of 'resolved' because the incident was solved. Currently you have to open and edit every file for each language and change the value by hand.

(The new commands are especially useful if you use more than one language!)

What does the proposed API look like?

How should this be implemented in your opinion?

Add 2 new commands:

npm run delete-incident # OR yarn delete-incident

and

npm run edit-incident # OR yarn edit-incident

-- After running one of those commands you will be asked a few questions. Examples: delete-incident:

• Please select the incident. (enter id?) Or select an incident from this list: (list of available incidents)
• Do you really want to delete this incident? (yes/no)

edit-incident:

• Please select the incident. (enter id?) Or select an incident from this list: (list of available incidents)
• Which value do you want to change?
• ...

Are you willing to work on this yourself?**

No.

The devDependency eslint-plugin-jest was updated from 22.5.1 to 22.6.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

eslint-plugin-jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot :palm_tree:

• [x] I confirm that this is a issue rather than a question.

Bug report

When installed in a subfolder (ie https://status/example.com/company1), several things break as links to assets or other pages do not expect this.

Version

0.3.0.beta1 (also with previous 0.2.x)

Steps to reproduce

Install in a subfolder

What is expected?

All links work normally.

What is actually happening?

• Logo is a 404, it links to /static/img/xxxx.png instead of /subfolder/static/img/xxxx.png or use a fully qualified link
• Link to History is a 404

They all link to /xxxx instead of /subfolder/xxxx.

Other relevant information

1. I'd suggest the baseURL is used to prefix all those links. Best would be to automatically determine the subfolder by separating the domain from the baseUrl. Or else a secondary config option can be added, ie baseURL = https://status.example.com + baseFolder = /company_A/department_1

2. Using a subfolder is common when hosting pages on Gitlab

• Your OS: N/A
• Node.js version: N/A
• Browser version: N/A
• Is this a global or local install? N/A
• Which package manager did you use for the install? N/A

Feature request

• [x] I confirm that this is a feature request rather than a question.

Scheduled maintenance: I'm just giving a test run to your project. That went fine but I could not find any way to handle scheduled maintenance, ie have "incidents" be in the future but still be listed in some way, independently from the past incidents history.

Likewise, there's no way to easily display one or more messages to visitors, although it's not a requirement as scheduled maintenance is.

What problem does this feature solve?

A status page cannot really be used if you can't announce upcoming maintenance windows, their expected start time duration and update them when maintenance is happening.

What does the proposed API look like?

How should this be implemented in your opinion?

Are you willing to work on this yourself?**

The dependency consola was updated from 1.4.4 to 2.0.0.

This version is not covered by your current version range.

If you don’t accept this pull request, your project will work just like it did before. However, you might be missing out on a bunch of new features, fixes and/or performance improvements from the dependency update.

Your Greenkeeper bot :palm_tree:

Bug report

The official docker image is pretty much useless because it builds the site resources as part of the docker build process instead of doing it whenever the container runs. Because of this, anything added to the config file via a bind-mount will not take effect since statusfy will simply use the pages it generated during the docker build phase, resulting in things like site name, site local translations, etc not applying.

Version

0.4.1

Steps to reproduce

Use a docker-compose file that looks something like:

version: '2'
services:
  statusfy:
    image: bazzite/statusfy:v0.4.1
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - "/opt/statusfy/data/config.toml:/usr/src/app/config.toml"
      - "/opt/statusfy/data/content:/usr/src/app/content"
      - "/opt/statusfy/data/locales:/usr/src/app/locales"
    restart: unless-stopped

What is expected?

My status page shows up normally.

What is actually happening?

My status page shows up using the default configuration settings. Nothing is translated.

Other relevant information

• Your OS: Alpine Linux
• Node.js version: 8
• Browser version: Chrome 75.0.3770.100
• Is this a global or local install? global
• Which package manager did you use for the install? docker/npm

• [x] I confirm that this is a issue rather than a question.

Bug report

Version

^0.2.1

Steps to reproduce

1. Download the following repository https://github.com/gruselhaus/status.gruselhaus.com
2. npm install
3. npm start

What is expected?

Server should start.

What is actually happening?

The script hangs on ℹ Reading configuration from config.js.

Other relevant information

• Repository: https://github.com/gruselhaus/status.gruselhaus.com
• Your OS: macOS 10.14.3
• Node.js version: 11.10.0
• Browser version: -
• Is this a global or local install? Both failed
• Which package manager did you use for the install? [email protected]

Summary

What kind of change does this PR introduce? (check at least one)

• [ ] Bugfix
• [ ] Feature
• [ ] Code style update
• [ ] Refactor
• [ ] Docs
• [ ] Build-related changes
• [ ] Other, please describe:

If changing the UI of default theme, please provide the before/after screenshot:

Does this PR introduce a breaking change? (check one)

• [ ] Yes
• [ ] No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• [ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)

You have tested in the following browsers: (Providing a detailed version will be better.)

• [ ] Chrome
• [ ] Firefox
• [ ] Safari
• [ ] Edge
• [ ] IE

If adding a new feature, the PR's description includes:

• [ ] A convincing reason for adding this feature
• [ ] Related documents have been updated
• [ ] Related tests have been updated

To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.

Other information:

Hey there!

I belong to an open source security research community, and a member (@xiaofen9) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

Summary Text mistranslation on docs: https://docs.statusfy.co/guide/i18n/#configuration

Where is written "ADVERTENCIA" should be WARNING.

What kind of change does this PR introduce? (check at least one)

• [ ] Bugfix
• [ ] Feature
• [ ] Code style update
• [ ] Refactor
• [X] Docs
• [ ] Build-related changes
• [ ] Other, please describe:

If changing the UI of default theme, please provide the before/after screenshot:

Does this PR introduce a breaking change? (check one)

• [ ] Yes
• [X] No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• [ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)

You have tested in the following browsers: (Providing a detailed version will be better.)

• [ ] Chrome
• [ ] Firefox
• [ ] Safari
• [ ] Edge
• [ ] IE

If adding a new feature, the PR's description includes:

• [ ] A convincing reason for adding this feature
• [ ] Related documents have been updated
• [ ] Related tests have been updated

To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.

Other information:

Summary

What kind of change does this PR introduce? (check at least one)

• [ ] Bugfix
• [ ] Feature
• [ ] Code style update
• [ ] Refactor
• [x] Docs
• [ ] Build-related changes
• [ ] Other, please describe:

If changing the UI of default theme, please provide the before/after screenshot:

Does this PR introduce a breaking change? (check one)

• [ ] Yes
• [x] No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• [ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)

You have tested in the following browsers: (Providing a detailed version will be better.)

• [ ] Chrome
• [ ] Firefox
• [ ] Safari
• [ ] Edge
• [ ] IE

If adding a new feature, the PR's description includes:

• [ ] A convincing reason for adding this feature
• [ ] Related documents have been updated
• [ ] Related tests have been updated

To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.

Other information:

Cloudflare pages lets you deploy frontend apps to Cloudflare' edge network. It's similar to Github Pages and Netlify. It's a great option especially if you're already on Cloudflare's ecosystem.

Feature request

What problem does this feature solve?

Our international and local customers are sometimes bugged by having a UTC time on incidents and other messages. which shouldn't be a problem In order to make it clear for everyone an (optional) display of a JS powered UTC and local-clock would solve close to weekly discussions about "wrong time on statuspage", "why're you reporting earlier / later ..." and the like.

What does the proposed API look like?

How should this be implemented in your opinion?

• [ ] new Date().toUTCString() and new Date() formatted to the default of statusfy.

Are you willing to work on this yourself?**

We'll add it to our Backlog. If anyone wants to tackle this one before we do - please go ahed.

Feature request

• [x] I confirm that this is a feature request rather than a question.

What problem does this feature solve?

We have numerous inbound customer requests on Email-Notifications. Setting up a serverside Email-Connection is out of scope of the project (from my PoV). Adding a Link to feedrabbit - a free RSS mail subscription service - would solve the problem to our needs.

What does the proposed UI-Change look like?

or a dedicated Mail-section:

How should this be implemented in your opinion?

Integrating either a tab-section or a link below the "Feeds"-Subscriptions using the Link to the RSS-Feed of statusfy e.g https://feedrabbit.com/subscriptions/new?url=https%3A%2F%2Fstatus.fiskaly.com%2Ffeeds%2Fincidents.en.xml

Are you willing to work on this yourself?**

We'll add it to our Backlog. If anyone wants to tackle this one before we do - please go ahed.

we're not affiliated to feedrabbit, it was just on of the first services popping up on a quick google search; feel free to opt for others if they've a mail-integration