IT reporting website for every day users
-
It sounds like what he wants is a ticketing system that supports ticket merging or something. If 50 people email in to say the phone system is down... Just merge all 50 tickets and then close the "master" ticket to notify all 50 people when the ticket has been closed.
-
@coliver said in IT reporting website for every day users:
@JaredBusch said in IT reporting website for every day users:
Wiki.js
Doesn't that require MongoDB? I've never deployed it so curious. Although it can store all it's data in a git repository which is a really big draw.
The data is file system. maybe that was for the authentication? been a while since I installed it. so my memory is likely faulty.
-
@JaredBusch said in IT reporting website for every day users:
@coliver said in IT reporting website for every day users:
@JaredBusch said in IT reporting website for every day users:
Wiki.js
Doesn't that require MongoDB? I've never deployed it so curious. Although it can store all it's data in a git repository which is a really big draw.
The data is file system. maybe that was for the authentication? been a while since I installed it. so my memory is likely faulty.
I think it can do either a flat file or use mongo
-
@jmoore said in IT reporting website for every day users:
@scottalanmiller Because from the way his boss phrased it, he doesnt want people to have to learn markdown.
Wiki doesn't mean markdown, though. And a wiki in WordPress doesn't mean that markdown will be avoided.
WordPress would be a total mess and bring all the problems of a wiki, without solving any of the issues.
-
@Dashrender said in IT reporting website for every day users:
If it's easier to edit a WP page for a novice, versus a wiki page, then I'd go WP.
It's not, it is way harder. Wiki = easy. WP = still easy, but not nearly AS easy.
The PURPOSE of a wiki is for exactly what is described here. The purpose of WP is not at all this.
-
@JaredBusch said in IT reporting website for every day users:
@coliver said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
Dokuwiki is the right answer because it is so much simpler and no one that can't format should ever be allowed to give a status (it means that they are too stupid to understand the status) and no one should be formatting anything anyway when giving a status, so making it easier to screw up makes no sense
This. No requirements for a backend other then a webserver makes it portable and easy to use.
Right which is why I also recommended Wiki.js.
Wiki.js uses MongoDB for authentication. And is about to move to PostgreSQL for it. So doesn't even use the "standard" PHP + MariaDB platform that people are used to, but a more exotic (but still easy) setup. But one that soon has to migrate platforms.
-
@coliver said in IT reporting website for every day users:
@JaredBusch said in IT reporting website for every day users:
Wiki.js
Doesn't that require MongoDB? I've never deployed it so curious. Although it can store all it's data in a git repository which is a really big draw.
Correct. So it has the complications of...
- NodeJS version management (PHP is dead simple by comparison.)
- MongoDB version management (every upgrade breaks your system, ugh.)
- The upcoming MongoDB to PostgreSQL migration.
None of that is a "big" deal, but all make it more complicated than something like BookStack which is, in turn, more complicated than DokuWiki.
-
@JaredBusch said in IT reporting website for every day users:
The data is file system. maybe that was for the authentication?
Yes MongoDB is only for the authentication bit.
-
@Dashrender said in IT reporting website for every day users:
@JaredBusch said in IT reporting website for every day users:
@coliver said in IT reporting website for every day users:
@JaredBusch said in IT reporting website for every day users:
Wiki.js
Doesn't that require MongoDB? I've never deployed it so curious. Although it can store all it's data in a git repository which is a really big draw.
The data is file system. maybe that was for the authentication? been a while since I installed it. so my memory is likely faulty.
I think it can do either a flat file or use mongo
No, it cannot. It has to use both, one for the data, one for the authentication.
-
@wirestyle22 said in IT reporting website for every day users:
@stacksofplates I think an interesting project would be to create a shared directory that Ansible pulled from to create pages on the website per day and allow it to automatically organize the website. It seems like it would be possible to do. Just a thought.
If you're going to go to that much work, just have a script that checks your actual monitoring and posts human readable outputs to Grafana.
-
@coliver said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
Dokuwiki is the right answer because it is so much simpler and no one that can't format should ever be allowed to give a status (it means that they are too stupid to understand the status) and no one should be formatting anything anyway when giving a status, so making it easier to screw up makes no sense
This. No requirements for a backend other then a webserver makes it portable and easy to use.
I'd personally use Hugo or Asciidoctor for it. Just have the tool build the site and deploy it.
-
@scottalanmiller said in IT reporting website for every day users:
@wirestyle22 said in IT reporting website for every day users:
@travisdh1 We have solarwinds for IT, but this is for every day people. They can access the website to see what issues have been reported so they don't duplicate calls to the help desk.
Then a wiki with a status page would be logical because you just want IT and no one else giving a status, and you don't want history, just the current state of things.
From outside looking in, I don't understand why you wouldn't want a history here. Gives transparency and you can update the status of things later on. I'd be willing to bet there are issues that last longer than a day that could be updated. And then the resolution could be posted and tracked in the same post.
-
@stacksofplates said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
@wirestyle22 said in IT reporting website for every day users:
@travisdh1 We have solarwinds for IT, but this is for every day people. They can access the website to see what issues have been reported so they don't duplicate calls to the help desk.
Then a wiki with a status page would be logical because you just want IT and no one else giving a status, and you don't want history, just the current state of things.
From outside looking in, I don't understand why you wouldn't want a history here. Gives transparency and you can update the status of things later on. I'd be willing to bet there are issues that last longer than a day that could be updated. And then the resolution could be posted and tracked in the same post.
A history isn't bad, but for end users, it can be very confusing. A wiki can have a history of updates when research is really needed, but I think history is better for the IT department and a pure status better for the end users. If you need a history, you can easily put that on the wiki, too. But I think users would tend to misunderstand or try to read into it things that you'd prefer them not inferring.
-
@scottalanmiller said in IT reporting website for every day users:
@stacksofplates said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
@wirestyle22 said in IT reporting website for every day users:
@travisdh1 We have solarwinds for IT, but this is for every day people. They can access the website to see what issues have been reported so they don't duplicate calls to the help desk.
Then a wiki with a status page would be logical because you just want IT and no one else giving a status, and you don't want history, just the current state of things.
From outside looking in, I don't understand why you wouldn't want a history here. Gives transparency and you can update the status of things later on. I'd be willing to bet there are issues that last longer than a day that could be updated. And then the resolution could be posted and tracked in the same post.
A history isn't bad, but for end users, it can be very confusing. A wiki can have a history of updates when research is really needed, but I think history is better for the IT department and a pure status better for the end users. If you need a history, you can easily put that on the wiki, too. But I think users would tend to misunderstand or try to read into it things that you'd prefer them not inferring.
It doesn't have to be publically viewable. But I'd want everyone to be able to see it if they wanted to. There should be a section for current issues. And then when they are fixed moved to an archived area. That way there isn't any confusion for anyone if it's a current situation or not. And it's transparent.
-
@stacksofplates said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
@stacksofplates said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
@wirestyle22 said in IT reporting website for every day users:
@travisdh1 We have solarwinds for IT, but this is for every day people. They can access the website to see what issues have been reported so they don't duplicate calls to the help desk.
Then a wiki with a status page would be logical because you just want IT and no one else giving a status, and you don't want history, just the current state of things.
From outside looking in, I don't understand why you wouldn't want a history here. Gives transparency and you can update the status of things later on. I'd be willing to bet there are issues that last longer than a day that could be updated. And then the resolution could be posted and tracked in the same post.
A history isn't bad, but for end users, it can be very confusing. A wiki can have a history of updates when research is really needed, but I think history is better for the IT department and a pure status better for the end users. If you need a history, you can easily put that on the wiki, too. But I think users would tend to misunderstand or try to read into it things that you'd prefer them not inferring.
It doesn't have to be publically viewable. But I'd want everyone to be able to see it if they wanted to. There should be a section for current issues. And then when they are fixed moved to an archived area. That way there isn't any confusion for anyone if it's a current situation or not. And it's transparent.
For private for IT, then yeah, I'd want history. Could be very useful.
-
@scottalanmiller said in IT reporting website for every day users:
@stacksofplates said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
@stacksofplates said in IT reporting website for every day users:
@scottalanmiller said in IT reporting website for every day users:
@wirestyle22 said in IT reporting website for every day users:
@travisdh1 We have solarwinds for IT, but this is for every day people. They can access the website to see what issues have been reported so they don't duplicate calls to the help desk.
Then a wiki with a status page would be logical because you just want IT and no one else giving a status, and you don't want history, just the current state of things.
From outside looking in, I don't understand why you wouldn't want a history here. Gives transparency and you can update the status of things later on. I'd be willing to bet there are issues that last longer than a day that could be updated. And then the resolution could be posted and tracked in the same post.
A history isn't bad, but for end users, it can be very confusing. A wiki can have a history of updates when research is really needed, but I think history is better for the IT department and a pure status better for the end users. If you need a history, you can easily put that on the wiki, too. But I think users would tend to misunderstand or try to read into it things that you'd prefer them not inferring.
It doesn't have to be publically viewable. But I'd want everyone to be able to see it if they wanted to. There should be a section for current issues. And then when they are fixed moved to an archived area. That way there isn't any confusion for anyone if it's a current situation or not. And it's transparent.
For private for IT, then yeah, I'd want history. Could be very useful.
I'd even make it open for non IT people. But it doesnt matter at this point. It should be a function of whatever tool you're using because it has value either way.
-
Honestly, what I'm thinking is a PowerShell GUI script that has a few simple fields like server/service, status, notes... Which simply outputs it to an html page. And also a button to clear/delete entries.
Lots of options. Maybe even list all services and the status... Stored in a csv, read and manipulated by the script GUI, outputted to a web page.
-
Something like https://cachethq.io ?
-
So I'd personally use Hugo or Asciidoctor like I mentioned, that way it's version controlled and can be built with a pipeline. But if you want stupid simple, Grav would work really well. There is a git sync plugin to use git for versioning, but if you don't want to set that up it's stupid simple to back up, just back up the directory. Here's a demo I threw up in Docker.
You get the nice admin page with WYSIWYG editing. If you don't want that, you can write raw markdown also.
It's an awesome tool with plugins and some nice themes.
-
Also as a side note, if you hate Powerpoint like I do, it has a presentation plugin that doesn't look too bad.
