Missing Menu on Left

I started anew with an upgrade of RT 3.8 to 4.0 in a new directory, and got the
system up and running, however the menu in the left-hand side is not visible,
nor is the top pane that normally should say:
“Logged in as Roberto J. Hoyle | Preferences | Logout”

I can view the source of the page and see the menu in the HTML, but it is
not visible when the page loads.

Any hints as to what may be causing this? The URL for the site is
https://libdesign.dartmouth.edu/rt/index.html

thanks,

r.

I started anew with an upgrade of RT 3.8 to 4.0 in a new directory, and got the
system up and running, however the menu in the left-hand side is not visible,
nor is the top pane that normally should say:
“Logged in as Roberto J. Hoyle | Preferences | Logout”

The new 4.0 default theme is different than the 3.8 one. Take a look at
the screenshots here: Request Tracker... So much more than a help desk — Best Practical Solutions

Any hints as to what may be causing this? The URL for the site is
https://libdesign.dartmouth.edu/rt/index.html

We can’t see that since it’s behind Dartmouth’s webauth. Can you post a
screenshot and browser information?

Thomas

I started anew with an upgrade of RT 3.8 to 4.0 in a new directory,
and got the system up and running, however the menu in the left-hand
side
is not visible,
nor is the top pane that normally should say:
“Logged in as Roberto J. Hoyle | Preferences | Logout”

I can view the source of the page and see the menu in the
HTML, but it is
not visible when the page loads.

Any hints as to what may be causing this? The URL for the site is
https://libdesign.dartmouth.edu/rt/index.html

You don’t, by chance, have mod_speling enabled do you?

When I started testing 4.0.1 I had mod_speling enabled to fix capitalization, and that broke the RT menus.

James Zuelow
Systems Operations Manager
City and Borough of Juneau MIS
(907) 586-0236

I noticed that there seems to be a display issue with Internet Explorer 9, where “Web2” is the chosen display theme . Safari renders it fine, but I haven’t tried any others.

Could this be your issue?

Jo

I started anew with an upgrade of RT 3.8 to 4.0 in a new directory,
and got the system up and running, however the menu in the left-hand
side
is not visible,
nor is the top pane that normally should say:
“Logged in as Roberto J. Hoyle | Preferences | Logout”

I can view the source of the page and see the menu in the
HTML, but it is
not visible when the page loads.

Any hints as to what may be causing this? The URL for the site is
https://libdesign.dartmouth.edu/rt/index.html

You don’t, by chance, have mod_speling enabled do you?

When I started testing 4.0.1 I had mod_speling enabled to fix capitalization, and that broke the RT menus.

James Zuelow
Systems Operations Manager
City and Borough of Juneau MIS
(907) 586-0236

2011 Training: http://bestpractical.com/services/training.html

I noticed that there seems to be a display issue with Internet Explorer 9, where “Web2” is the chosen display theme . Safari renders it fine, but I haven’t tried any others.

Web2 isn’t the default theme on RT4, aileron is, but yours is the
first report I’ve seen of incompatibilities with IE9 and the web2
themes on RT4

If you’re seeing problems, please report them to the bugtracker with
screenshots.

-kevin

James Zuelow <James_Zuelow ci.juneau.ak.us> writes:

You don’t, by chance, have mod_speling enabled do you?

When I started testing 4.0.1 I had mod_speling enabled to fix capitalization,
and that broke the RT menus.

Thanks, James! That was exactly my problem. Disabling mod_speling
brought the menus out.

r.

James Zuelow <James_Zuelow ci.juneau.ak.us> writes:

You don’t, by chance, have mod_speling enabled do you?

When I started testing 4.0.1 I had mod_speling enabled to fix capitalization,
and that broke the RT menus.

Thanks, James! That was exactly my problem. Disabling mod_speling
brought the menus out.

I’d be fascinated to know what URL it is breaking so we can add a note
to the documentation.

-kevin

James Zuelow <James_Zuelow ci.juneau.ak.us> writes:

You don’t, by chance, have mod_speling enabled do you?

When I started testing 4.0.1 I had mod_speling enabled to fix
capitalization, and that broke the RT menus.

Thanks, James! That was exactly my problem. Disabling mod_speling
brought the menus out.

I’d be fascinated to know what URL it is breaking so we can add a
note to the documentation.

-kevin

I know this is stale, and I am hoping that Roberto gave you more information.

I have had just a little bit of time to play with this, and it is really odd to me.

With mod_speling turned on, none of the drop-down menus in the title field are there.

(Everything from “logged on as…” and to the left.

Same behavior with IE8 and Firefox 3.6/Firefox 5.

But if I look at the HTML source for the page, I can find the menus in the source!

There are no errors in the Apache logs. From Apache’s point of view everything was sent to the client as it should have been.

I suppose that there is something breaking in the css that is telling the browser not to display the menus.

I’m not at all a web designer though, so I have a hard time following what is going on.

If you have anything specific you would like me to try, just let me know.

James Zuelow
Systems Operations Manager
City and Borough of Juneau MIS
(907) 586-0236

----Original Message----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf
Of Kevin Falcone
Sent: Wednesday, July 20, 2011 2:51 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Missing Menu on Left

James Zuelow <James_Zuelow ci.juneau.ak.us> writes:

You don’t, by chance, have mod_speling enabled do you?

When I started testing 4.0.1 I had mod_speling enabled to fix
capitalization, and that broke the RT menus.

Thanks, James! That was exactly my problem. Disabling mod_speling
brought the menus out.

I’d be fascinated to know what URL it is breaking so we can add a
note to the documentation.

-kevin

I know this is stale, and I am hoping that Roberto gave you more information.
I have had just a little bit of time to play with this, and it is really odd to me.
With mod_speling turned on, none of the drop-down menus in the title field are there.
(Everything from “logged on as…” and to the left.
Same behavior with IE8 and Firefox 3.6/Firefox 5.
But if I look at the HTML source for the page, I can find the menus in the source!

Unfortunately, no, I haven’t received any further information.

Look at the top of your HTML source for the css and js links,
something like /NoAuth/css/*squished and /NoAuth/js/*squished
and try loading them to see what error you get

-kevin

Unfortunately, no, I haven’t received any further information.

Look at the top of your HTML source for the css and js links,
something like /NoAuth/css/*squished and /NoAuth/js/*squished
and try loading them to see what error you get

-kevin

I found one error, but unfortunately fixing it didn’t resolve the issue. With mod_speling enabled, and check spelling turned on this line in the code generates and error:

Generates this Apache error message:

Errors:

Multiple Choices
The document name you requested (/rt/NoAuth/RichText/ckeditor.js) could not be found on this server. However, we found documents with names similar to the one you requested.
Available documents:

/rt/NoAuth/RichText/ckeditor (common basename)

I went looking for ckeditor.js thinking it would be an easy fix. Editing request_tracker4/html/Elements/HeaderJavascript to correct the path (it should be /rt/NoAuth/RichText/ckeditor/ckeditor.js, at least with the Debian Wheezy package installation) doesn’t seem to fix it though.

After I fixed the path in HeaderJavascript I restarted apache, and the source code still shows the same incorrect path to ckeditor.js, and I get this Internet Explorer error:

Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; MS-RTC LM 8; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC EA 2)
Timestamp: Thu, 11 Aug 2011 16:25:23 UTC

Message: Syntax error
Line: 1
Char: 1
Code: 0
URI: http://rt.cbj.local/rt/NoAuth/RichText/ckeditor.js

Message: ‘CKEDITOR’ is undefined
Line: 128
Char: 113
Code: 0
URI: http://rt.cbj.local/rt/NoAuth/js/squished-0d827a85fc350fae22bf999015a8d153.js

At that point, I am out of my depth.

James Zuelow
Systems Operations Manager
City and Borough of Juneau MIS
(907) 586-0236

I found one error, but unfortunately fixing it didn’t resolve the issue. With mod_speling enabled, and check spelling turned on this line in the code generates and error:

Generates this Apache error message:

============================

Errors:

Multiple Choices
The document name you requested (/rt/NoAuth/RichText/ckeditor.js) could not be found on this server. However, we found documents with names similar to the one you requested.
Available documents:

/rt/NoAuth/RichText/ckeditor (common basename)

============================

I went looking for ckeditor.js thinking it would be an easy fix. Editing request_tracker4/html/Elements/HeaderJavascript to correct the path (it should be /rt/NoAuth/RichText/ckeditor/ckeditor.js, at least with the Debian Wheezy package installation) doesn’t seem to fix it though.

The path we request is actually correct.
Loading ckeditor.js directly is going to cause issues down the road.

The problem is that RT intentionally requests numerous things that
don’t exist on disk. We use HTML::Mason’s dhandler functionality to
then dynamically serve the proper thing.

It sounds like the only solution is to add a note to
web_deployment.pod and then in a future release provide configs for
turning this and mod_cache off.

Thanks for your help in researching this.

-kevin

The path we request is actually correct.
Loading ckeditor.js directly is going to cause issues down the road.

OK, I changed it back.

The problem is that RT intentionally requests numerous things that
don’t exist on disk. We use HTML::Mason’s dhandler functionality to
then dynamically serve the proper thing.

It sounds like the only solution is to add a note to
web_deployment.pod and then in a future release provide configs for
turning this and mod_cache off.

Hmm, that’s too bad. I am primarily interested in users being able to get to SelfService even if they manually type in selfservice, etc.

Most of them will follow links, but eventually someone will type it and not get the right address. Probably mod_rewrite to catch common errors is the solution here.

Thanks for your help in researching this.

No worries. Sorry it took so long!

James

Hmm, that’s too bad. I am primarily interested in users being able to get to SelfService even if they manually type in selfservice, etc.

Most of them will follow links, but eventually someone will type it and not get the right address. Probably mod_rewrite to catch common errors is the solution here.

Your Unprivileged RT users can just go to http://your.rt.server/ and
after login we’ll redirect them to /SelfService/. There’s no need for
them to remember the URL.

-kevin