If i link a ticket to a ticket, OTRS creates an historycomment "TicketLinkAdd" as well as delete a ticketlink.
I propose that every Link-Action (FAQ, CI...) creates an historycomment.
So you can see, who did create or delete a link.
I think it is a bad habit to write in the documentation: "to run this software you have to disable SELinux"
For a productive system it is not a good practice to disable it.
It wood be better to show up which rules are needed to run OTRS.
Another option would be to point at the permissive state for SELinux that logs all needed permissions tant can be enabled afterwards by an audit tool in a batch.
why it's so ?
for Chapter 2 i need ~10 move to NEXT clicks ?
why not all on one page ?
bad, bad
It would be good if the search field was able to search the documentation, rather than support tickets
The lack of search functionality makes browsing the documentation tedious
automatically change the owner
Documentation of Admin and ITSM in EPUB format.
Hi,
I have an ebook reader. It would be nice to have epubs and/or mobi documentation. Shouldn't be hard to convert from html. Is it planed?
Step 4 says to setup new system. Step 5 says to install new release. There is never a step to import my old database. If I'm upgrading to a new system, when do I import my old database? Should that be before step 4, and install the old OTRS system, then upgrade?
I just think the documentation needs to be clearer if building a new system instead of doing an in-place upgrade.
Thank you.
Can you please expand the backup/restore section. A step by step restore guide would include things you have to do to prepare for example - create database - create user - which template on Postgresql etc.
I just upgraded the OTRS-Framework from 3.1.2 to 3.2.5 on a SLES 11 SP2 System. Now I am not sure, if the installation and configuration was completly successful, because of warnings about mysql during installation. It looks to me that stopping mysql was wrong. I understood from point "1. Stop all relevant services" that I had to stop also mysql. In the following is my feedback from Installation from the rpm: backup ...more »
After changing database backend for attachments with the proposed command:
bin/otrs.ArticleStorageSwitch.pl -s ArticleStorageDB -d ArticleStorageFS
It's a good idea to optimize the database, mainly MySQL, connecting at MySQl and running the commands:
optimize table article_attachment;
optimize table article_plain;
optimize table ticket_history;
In the documentation, the page 'Filtering incoming messages' should explain that OTRS applies the filters in alphabetical order. So even though the GUI does not provide an intuitive way to order the filters in the list, it is possible to set the order indirectly by naming the filters adequately. For example by prefixing all filter names with numbers, like this: '001 first filter', '002 second filter', etc.
When working on a ticket with lot of articles it is often difficult to find the right article from interest - this is due to the fact that most customers do not change the subject line of their emails. Inside the article thread view all articles are listed with the same SUBJECT. Therefore I do suggest to add an additional column (HEADLINE) inside this view where agents can easily put a rough description or headline of ...more »
OTRS RPM can be installed on Centos simply by
1) download the rpm
2) yum install name-of-the-otrs-rpm.rpm
This way, there is no manual dependency resoloution. SELinux still needs to be configured (or disabled)
I suggest to enhance the notification (event) feature, so that you can define conditions when email should be send in more detail. For example send email when ticket-type has been changed from X to Y. Or when ticket has been moved from W to V queue. Or when freetext field A has been updated. At the moment you can just define for a change in general - but this will spam your inbox if you are only interested in some specific ...more »