Remove or Modify 'Create' button from TL Menu

[John Elnaugh]

Hello there,

I would like to remove or re-map the button located on the top level menu within JIRA.

We are using JIRA as a service desk solution, however some of our Agents are creating jobs using this button instead of through the Service Desk Portal.

This doesn't present a major logistical issue, however I would like it to be unified (and either remove that button or link it to the Service Desk Portal).

Any easy way of doing this?

image2015-11-10 10:3:2.png

[Nic Brough -Adaptavist- · Accepted solution]

And the famous answer - what does your log file say is locking it?

[Doug Wolfgram]

The log file is a ton of jibberish I can't decipher. Java is second only to Apple in obscurity of error logs.  However, I read some more threads on the subject and found that a plugin directory had permissions set to root so I changed those, deleted the .lock file and everything works now.  Had a similar problem with confluence. Resent all the permissions and voila! Question is, how did an upgrade to Centos 7.2 from 7.1 trigger these errors? Thanks for the reply... 

[Nic Brough -Adaptavist-]

Sounds like the applications were started as "root", which will create files with the wrong permissions. The logs would have led you there after a couple of steps, but I have to disagree with your comment about "obscurity of error logs". Microsoft's errors are even worse than both Java and Apple's ;-)

[Jonas Andersson]

Agree with Nic.. If anything the Jira logs are overly verbose, detailing every class called on every error. Unlike microsoft "An unexpected error occurred", or Apple's "The iPhone [device name] could not be restored. An unknown error occurred (4014)." Logs can be tuned to contain just as much info as you please using log4j property tuning: https://confluence.atlassian.com/jira/logging-and-profiling-185729617.html

[Nic Brough -Adaptavist-]

If you ever write java code, you find the logs can be quite useful, as they point to the line of code that went wrong. They do look overly verbose, but once you learn to ignore the developer part, they're quite informative - I expect yours had a stack of "IO exception" type messages which would have led us to question whether the files and directories had the correct permissions and ownerships...

[Roman]

Hi, Nic. I'm in troublr just now!)
What log u need?

:/var/atlassian/application-data/jira/log$ ls

atlassian-greenhopper.log         atlassian-jira.log.5

atlassian-jira-incoming-mail.log  atlassian-jira-outgoing-mail.log

atlassian-jira.log                atlassian-jira-outgoing-mail.log.1

atlassian-jira.log.1              atlassian-jira-security.log

atlassian-jira.log.2              atlassian-jira-security.log.1

atlassian-jira.log.3              atlassian-jira-slow-queries.log

atlassian-jira.log.4              atlassian-servicedesk.log

[Nic Brough -Adaptavist-]

atlassian-jira.log

[Nic Brough -Adaptavist-]

Could you post the actual error, rather than just bits of log from JIRA's start up.  It will happen near the end of the process

[Roman]

resolved with https://confluence.atlassian.com/jirakb/jira-shows-a-404-error-after-restart-284366187.html

[Nic Brough -Adaptavist-]

So... Reading the error in the log led you to "Sounds like the applications were started as "root", which will create files with the wrong permissions. " as already mentioned!