Dashboard not Saving

Have you changed the public URL of the Jazz Team Server? This is one of the consequences if you have changed it.

If you're using 3.0.1 there is a workaround described in comment 18 of this work item:

https://jazz.net/jazz/web/projects/Jazz%20Foundation#action=com.ibm.team.workitem.viewWorkItem&itemId=_NhPlgDU0EeCCStJkkcb_ew

None of my dashboards are saving. I gave the user permissions to do everything. I've tried using Auto Save and also explicitly clicking save. But every time when i return to the dashboard all customizations are gone.

I created a new personal dashboard - saved - then navigated away and back - it said no personal dashboards exist

Is there some setting i've missed ?

Hi Morten,

Since there are no customized dashboards on this server, the best option is to just delete the dashboard storage areas and start clean. This should flush out any problems that may have been caused by a public URL change.

Just to be clear, this will permanently delete all dashboards on this JTS and its applications, so it is important to do a backup as a precaution.

1. Shut down JTS
2. Perform JTS DB backup.
3. repotools-jts -deleteJFSResources storageAreaURL=storage/com.ibm.team.dashboard.nohistory force
4. repotools-jts -deleteJFSResources storageAreaURL=storage/com.ibm.team.dashboard force
5. repotools-jts -reindex
6. Restart JTS

None of my dashboards are saving. I gave the user permissions to do everything. I've tried using Auto Save and also explicitly clicking save. But every time when i return to the dashboard all customizations are gone.

I created a new personal dashboard - saved - then navigated away and back - it said no personal dashboards exist

Is there some setting i've missed ?

Hi,

if you would not have the permission to save I would expect an error on save. What environment are you running on (versions)? Do you see an error in any of the logs? If running 3.x any indicators in the server diagnostics in the server administration?

I'm running on 3.0.1 - although i believe the original jts was on v2 and got upgraded - in which case the public url likely changed from /ccm to /jazz

During the upgrade, you get to specify whether to keep the original
/jazz tag, or use the new /ccm tag. The upgrade encourages you to keep
the original tag if you are upgrading an existing repository, to avoid
this kind of problem.

Cheers,
Geoff

On 8/15/2011 1:53 PM, andy.lapping wrote:

I'm running on 3.0.1 - although i believe the original jts was on v2
and got upgraded - in which case the public url likely changed from
/ccm to /jazz

Hi Andy,

Did changing it back to the original resolve the problem? Changing the context path constitutes a change in public URL, which is not supported. In 3.0.1 there are additional guards in place to prevent this type of problem. Dashboard is particularly sensitive to this due to the fact that it's based on the newer Jazz Foundation Services storage, but there would likely be other problems as well.

Thanks

Hi Andy,

Did changing it back to the original resolve the problem? Changing the context path constitutes a change in public URL, which is not supported. In 3.0.1 there are additional guards in place to prevent this type of problem. Dashboard is particularly sensitive to this due to the fact that it's based on the newer Jazz Foundation Services storage, but there would likely be other problems as well.

Thanks

I havent tried it yet - I'll probably ditch the Image and make a new one - especially since there may be other problems too - this could be why i'm getting the OAuth Timestamp issue

Hi, I also experience the problem with dashboards not saving. It originally occurred on a RTC 3.0 (not ifix01) install, and now after the upgrade to RTC 3.0.1.1 the dashboard issue is still there.

AFAIK the server URL has not changed ever.

I will try to run -rebuildIndices to see if this fixes it (mentioned in the Defect linked in this thread) but I doubt it.

I found this curious stack trace in my ccm.log:

2011-11-03 11:14:34,014 ERROR net.jazz.ajax.servlets.LoaderServlet - POST https://midev01.mi.local:9443/ccm/web/_loader
HEADER: accept = */*
HEADER: accept-language = da
HEADER: referer = https://midev01.mi.local:9443/ccm/web/projects/BodyMD%20Development
HEADER: x-requested-with = XMLHttpRequest
HEADER: content-type = application/x-www-form-urlencoded
HEADER: accept-encoding = gzip, deflate
HEADER: user-agent = Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; GTB6; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 1.1.4322; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; InfoPath.2; .NET4.0E; .NET4.0C; MSN Optimized;US)
HEADER: host = midev01.mi.local:9443
HEADER: content-length = 444
HEADER: connection = Keep-Alive
HEADER: cache-control = no-cache
HEADER: cookie = SaveStateCookie=undefined%2Ccom.ibm.team.dashboard.category%2Ccom.ibm.team.dashboard.category~%23_~%23com.ibm.team.dashboard.server.saveProjectDashboard%2Ccom.ibm.team.dashboard.category~%23_~%23com.ibm.team.dashboard.server.savePersonalDashboard%2Ccom.ibm.team.dashboard.category~%23_~%23com.ibm.team.dashboard.server.saveTeamDashboard%2Ccom.ibm.team.workitem.category%2Ccom.ibm.team.workitem.category~%23_~%23com.ibm.team.workitem.server.saveAttachment%2Ccom.ibm.team.workitem.category~%23_~%23com.ibm.team.workitem.operation.workItemSave%2Ccom.ibm.team.workitem.category~%23_~%23com.ibm.team.workitem.operation.workItemSave~%23_~%23create%2Ccom.ibm.team.scm.category; net-jazz-ajax-cookie-rememberUserId=ratladmin; JSESSIONID=BE0...2E3; JazzFormAuth=Form; highlight=false; JSESSIONIDSSO=A54...6DB
Parameter: _proxyURL =
Parameter: debug =
Parameter: resources =
Parameter: excluding =

java.lang.NullPointerException
at net.jazz.ajax.servlets.LoaderServlet.doPost(LoaderServlet.java:38)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at net.jazz.ajax.servlets.LoggingHttpServlet.service(LoggingHttpServlet.java:34)
at org.eclipse.equinox.http.servlet.internal.ServletRegistration.handleRequest(ServletRegistration.java:90)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:111)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:59)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.eclipse.equinox.servletbridge.BridgeServlet.service(BridgeServlet.java:120)
at com.ibm.team.repository.server.servletbridge.JazzServlet.service(JazzServlet.java:76)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:563)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:420)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:879)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:811)

Currently the only known cause of this problem is public URL changes to the JTS. Sometimes these changes can occur early on, e.g. while the server is being set up and tested. In 3.0 there was not sufficient protection to warn users not to do this and that public URL changes aren't supported (this now happens in later versions).

Have dashboards ever saved correctly on this server, i.e. has this been happening since the server was set up or did it start happening one day after having been used for some time?

Have dashboards ever saved correctly on this server, i.e. has this been happening since the server was set up or did it start happening one day after having been used for some time?

Hi, thanks for your answer.

Actually I cannot tell, but there exists no customized dashboards, only the default ones. But I think it has "always" been like that. At least since the first time they tried to change a dashboard.