IT reporting website for every day users
-
@jmoore said in IT reporting website for every day users:
@scottalanmiller I agree with you however I was looking at it from his boss's viewpoint which is why I made that suggestion.
In what respect? To make WordPress do this in any kind of good way, it has to be used as a container for a wiki. WordPress will be worse for anything his boss has as a goal, other than outright sabotage. Harder for IT, harder for the end users. And WordPress is not WYSIWYG so that actually rules it out.
-
@scottalanmiller Because from the way his boss phrased it, he doesnt want people to have to learn markdown. I know thats dumb because markdown is only slightly more complicated than writing with good grammar. However Wordpress is likely what will make the most sense to his boss and it isnt an "automatic" fail. I would use a wiki also if it were my choice but it isnt. Setting up authors as needed is trivial so should not be an issue. Again, I'm looking at this from his boss's viewpoint and what will be the easiest thing to get over and what is still trivial to set up and maintain.
-
@scottalanmiller said in IT reporting website for every day users:
@jmoore said in IT reporting website for every day users:
@wirestyle22 I still think Wordpress is what you want for this. Its easy and quick enough for what your describing.
Can't be as good as a wiki. WordPress is built around blogging, not status. Blogs of status would be super weird and confusing. Wordpress can host a wiki, but all that is doing is making a really basic wiki harder than it needs to be.
DokuWiki is perfect here, no database needed.
OK I get what you're saying - but the end users don't know WP from a wiki - so ultimately that doesn't matter. If it's easier to edit a WP page for a novice, versus a wiki page, then I'd go WP.
of course, if this remains in IT's hands - then meh whatever!
-
@wirestyle22 If you're looking for automation. You can make some really cool dashboards with Grafana.
-
@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.
-
@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.
-
@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.
-
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.
