ghudson_1

Issue DescriptionA customer was attempting to edit a huge domain, and when browsing through their loadbalancer or proxy the browser would hang, and when bypassing the proxy (hitting JRS directly) the browser would redirect to the login page. Analysis of the jasperserver.log showed an error from CsrfGuard: error:required token is missing from the request ResolutionThe error means that the OWASP_CSRFTOKEN is being lost from the http POST which occurs while browsing from one tab to another in the domain designer. From viewing example POSTS of other domains we can see the OWASP_CSRFTOKEN token is one of the last items added to the http POST body. Since there is no proxy or loadbalancer the primary way for the OWASP_CSRFTOKEN to be lost is due to tomcat truncating the end of the POST body due to it's maxPostSize. In Tomcat's server.xml, edit the Connector element, adding a value larger than the total POST size, for example: <Connector port="8070" protocol="HTTP/1.1" connectionTimeout="20000" maxPostSize="20000000" redirectPort="8443" />Ref. Case 01732532 /strong>

Issue DescriptionIn TIBCO JasperReports® Server 7.2, you might encounter a message in the output of certain buildomatic commands, like the command 'js-ant clean-config'. The message in the output is: "Cannot run program "git"" ResolutionThis is a harmless warning that has no impact on the execution of the command. They are maven related setup steps that would be used if doing a full build of JasperReports Server. To suppress that error you can edit buildomaticbinsetup.xml After line 629 just remove the exec xml element by removing all of this: <exec executable="git" outputproperty="git.currentBranchName" failifexecutionfails="false"> <arg value="rev-parse"/> <arg value="--abbrev-ref"/> <arg value="HEAD"/> </exec> Ref. Case 01793656

Issue DescriptionA customer encountered an error when running a report, the exception in the logs was: java.sql.SQLException: setMaxRows() out of range. 70000000 > 50000000. The stacktrace indicated that the exception was coming from a java package under com.mysql.jdbc, the customer's database was mysql. ResolutionThe exception is being thrown from the Mysql JDBC Driver. Prepared Statements are the means by which TIBCO JasperReports® Server executes sql statements. When using "Ad Hoc Dataset Row Limit" the JasperReports® Server calls the setMaxRows method of the JDBC driver to add a limit statement to the query. The customer had set 70 million as their "Ad Hoc Dataset Row Limit", unfortunately the Mysql JDBC driver has a hard-coded maximum of 50 million for their limit statement that can be appended. The workaround, if 50 million rows isn't enough, is to ensure your db connection is using the MariaDB driver. JasperReports® Server publishes the MariaDB driver by default, so this might be as easy as removing all Mysql *.jar files from the lib dir of your appserver and from the WEB-INFlib dir of JasperReports® Server. Other options include forcing your db connection to be JNDI-based in which you specify org.mariadb.jdbc.Driver as the class name for the jdbc driver of the new JNDI resource. Ref. Case 01793407

Issue DescriptionDomain Security file is uploaded to repository folder, but while editing the domain that domain security file cannot be found when browsing the folder ResolutionThese symptoms can occur if the wrong options were chosen during upload. The domain editor pop-up is only showing files from the repository folder that were uploaded as "Access Grant Schema" files. So you should choose File -> Access Grant Schema when you upload your xml file (with or without a .xml extension). Ref. Case 01777901

Issue DescriptionSeveral other wiki articles discuss ideas for putting your TIBCO JasperReports® Server instance behind a loadbalancer or reverse proxy, but this particular is targeted specifically at environments using IBM's Weblogic appserver. When using Tomcat, the http headers from the proxy to the appserver are key and that remains true in Weblogic but a few proprietary steps are required: ResolutionNote, this is an example only. We recommend you seek council from your own Weblogic and loadbalancer/proxy experts when implementing your loadbalancer or proxy environment. In a simple install using Weblogic 12.1.3 and Apache HTTPD (configured as an SSL-Offloading reverse proxy) the following weblogic-specific keys proved important: In the proxy ensure the http header WL-Proxy-SSL is being set with a value of true. In apache httpd this configuration looks like: RequestHeader set WL-Proxy-SSL true[/code]In weblogic console, choose your domain, hit the 'web applications' tab, find "WebLogic Plugin Enabled" and checkmark that checkbox, save. The "core" part of the httpd config is: ProxyRequests OffProxyPreserveHost OnProxyPass /jasperserver-pro http://infra-platforms-phase2-47-ghudson.pfa.jaspersoft.com:7001/jasperserver-proProxyPassReverse /jasperserver-pro http://infra-platforms-phase2-47-ghudson.pfa.jaspersoft.com:7001/jasperserver-proRequestHeader set X-Forwarded-Proto "https"RequestHeader set X-Forwarded-Port "443"RequestHeader set X-Forwarded-Host "greg.gh"RequestHeader set WL-Proxy-SSL true[/code]For details on the WL-Proxy-SSL header, seek Weblogic documentation. Reference: https://community.jaspersoft.com/wiki/video-reverse-proxies-can-often-cause-csrf-or-block-mixed-content-problemsRef. Case 01761136

Issue DescriptionReport labels (names) that are lengthy can get cut-off from display. ResolutionThere is a stylesheet that helps define the widths of fields on the repository listing page, it is lists.css. Stylesheets are customizable thru themes administration. For general information on themes administration you can review the admin guide here: https://community.jaspersoft.com/documentation/tibco-jasperreports-server-administrator-guide/v71/themes Some quick examples can be found in the JRS Ultimate Guide, like: https://community.jaspersoft.com/documentation/tibco-jasperreports-server-ultimate-guide/v710/changing-colors-and-fonts There is a resourceName width and a resourceDescription max-width that must add up to 100. So if you increase one, you have to decrease the other. For example, if you change the width of .list.resources .resourceName to 55%, you will need to change the max-width of the other to 45%. So, this could be used in your overrides_custom.css: .list.resources .resourceName { width: 55% } #repoSearch .list.resources .resourceDescription, #repoBrowse .list.resources .resourceDescription { max-width: 45%; }Ref. Case 01732989

Issue DescriptionThe TIBCO JasperReports® Server Ultimate Guide's "Adding Custom Export Channel", https://community.jaspersoft.com/documentation/tibco-jasperreports-server-ultimate-guide/v710/adding-custom-export-channels , covers the customization for adding a new exporter format (aka channel) for ReportViewer, REST, and actual job execution, but it lacks discussion of steps to ensure the new format can be chosen in the UI of the scheduler ResolutionFollow the steps in the guide, as indicated, in the viewReportBeans.xml and reportJobBeans.xml you'll want to basically mimic other pre-existing entries for exports. The guide doesn't specifically mention this, but you need to add your new output format entries to the availableReportJobOutputFormats in applicationContext-report-scheduling.xml. Then you need to edit and recompile a few source files. Both of these contain hard-coded values/constants: jasperserver\jasperserver-api\engine\src\main\java\com\jaspersoft\jasperserver\api\engine\scheduling\domain\ReportJob.javajasperserver\jasperserver-api\engine\src\main\java\com\jaspersoft\jasperserver\api\engine\scheduling\domain\jaxb\OutputFormatXmlAdapter.javaThe edits above will need to match the naming conventions you used in WEB-INFflowsreportJobBeans.xml, and the numeric values from applicationContext-report-scheduling.xml. In earlier version you'd need to edit some of the htm templates, .jsp or .js files but now the values are pulled from the availableReportJobOutputFormats entries, so no any presentation layer parts need to be touched. Ref. Case 01677793

Issue DescriptionA customer had a particular job with an invalid query that was hanging for long periods of time. Due misfire policy configurations and the way the job had been scheduled multiple times by users, it was hogging all of the scheduler's worker threads and continued to fire after after restarts. The customer needed a way to ensure this report stopped triggering/firing so other schedule jobs could execute ResolutionThe QRTZ_FIRED_TRIGGERS table contains jobs that are have been fired/triggered due to calendar or interval timing are pending execution once a worker thread is free to get to it. Once a job is actually picked up from the qrtz_fired_triggers for querying and filling, the only thing that would kill it is a restart of the webapp. Determine the name of the reports in that table via a query similar this: select (select label from JIREPORTJOB where id = substr(qt.job_name, 5,length(qt.job_name))) label, qt.* from QRTZ_FIRED_TRIGGERS qtFor clean-up, try to pause/disable it in the UI. Let the report finish, then you can manually delete (via sql) the record from qrtz_fired_triggers. NOTE - prior to performing any data deletion from the database, always peform a BACK-UP. If you are having trouble and the report is still running, won't finish, or is re-firing into the qrtz_fired_triggers, then do: Disable the job from UIStop the Jasper webappDelete the corresponding entries only from qrtz tables qrtz_fired_triggers, qrtz_simple_triggers, qrtz_cron_triggers, qrtz_triggers, qrtz_job_details (see below)Start the Jasper appDelete job from UI (which should cleanup jireportjob table and it's associations)Hide the report from users or instruct them not to reschedule it.For example, if your job name is job_37990: delete from qrtz_simple_triggers where trigger_name IN (select trigger_name from qrtz_triggers where job_name = 'job_37990') delete from qrtz_cron_triggers where trigger_name IN (select trigger_name from qrtz_triggers where job_name = 'job_37990') delete from qrtz_triggers where job_name = 'job_37990' delete from qrtz_job_details where job_name = 'job_37990' delete from qrtz_fired_triggers where job_name = 'job_37990'check the qrtz_fired_triggers table as well. Ref. Case 01685510

Issue DescriptionUnder certain circumstances customers have seen scheduled jobs not execute, instead the next run-time lists the current time, or some time in the future, yet the job never actually executes, the "next run" time just keeps advancing. There is a configurable default number of scheduler threads (threadCount) in WEB-INFjs.quartz.base.properties, the default it two. These two worker threads peruse the scheduler queue to pickup any "triggered/fired" jobs so they can fill and export their reports. If the two are stuck, hung or busy due to a long-running report, then it is possible that other firings could be skipped over based upon "misfire" policy. When a firing occurs, if the job isn't "picked up" within three minutes (by default, but configurable) we deem this a misfire. Following are default behaviors when a misfire occurs: For non-recurring / one-time: it will fire immediately (of course if the two threads are stuck then just remain in the queue) For simple recurring: it will skip till the next interval at which is should run For calendar recurring: it will fire immediately the most recent timed-trigger, and skip anything prior. So if the worker threads are being hung-up by a poorly performing report, this can cause misfires which effectively re-queue the "next run" time, over and over perpetually and reports never get executed and delivered until the backlog from the poorly performing report(s) clears out. If you have many poorly performing reports scheduled in a pretty tight time-frame the backlog can be large. ResolutionYou can increase the number of threads, but note that this will lead to more concurrency, which could hurt CPU/RAM and result in delays for people running reports via the UI. If your scheduler seems stuck, our recommendation is to halt the scheduling of new jobs by users, remove or disable poorly performing schedules jobs so they don't requeue. (It may be necessary to restart JRS to kill hung reports, and it may be necessary to clean out the Fired Triggers table, if so, contact support). Then limit the types of reports that can be scheduled based upon your tested limits (resources like ram/cpu factored with threadCount and misfireThreshold). Ensure you space out the timing properly, and if necessary you can always add a node into a cluster that does nothing except run the scheduler. Ref. Case 01485362 https://community.jaspersoft.com/wiki/what-are-various-quartz-misfire-policy-definitions

Issue DescriptionSomeone might want timestamp-based values from their database use a specific timezone, like the server timezone for example, but they might have report-rendering timestamps (for example a "ran on" value in a title or summary) that they'd like to show in the user's timezone. ResolutionYou can specify a timezone adjustment at an element level via this property: http://jasperreports.sourceforge.net/config.reference.html#net.sf.jasperreports.pattern.timezone If you're using JRS and wanted to specify the user's timezone defined for them during login you'd set the element to REPORT_TIME_ZONE. Select the field in your report design in Jaspersoft Studio, then in the Properties panel select Advanced > Misc > Properties. Add new property with name: net.sf.jasperreports.pattern.timezone and value: REPORT_TIME_ZONE

Issue DescriptionIt is possible to specify the export's character encoding for scheduled reports. This will over-ride the default value, UTF-8, as well as any values which are set in a properties file or via a jrxml-level property. ResolutionEdit WEB-INFapplicationContext-report-scheduling.xml and add a new bean to the file with your encoding preference, i'm using ISO8559_1 in the three-line bean addition example below: <bean id="schedulerEncodingProvider" class="com.jaspersoft.jasperserver.api.common.util.StaticCharacterEncodingProvider"> <constructor-arg value="ISO8859_1"/> </bean> Then find the pre-existing line near 119 which is: <entry key="encodingProvider" value-ref="encodingProvider"/> and edit it, changing the value-ref to match the id of the bean you just created, like my example: <entry key="encodingProvider" value-ref="schedulerEncodingProvider"/> A restart is required, and in my example all outputs from the schedule jobs would be char encoded as ISO8859_1. Ref. Case 01654457

Issue DescriptionSince 6.x a regression defect exists in JasperReports library which results in a java.lang.StackOverflowError during report fill. The problem is related to style elements that use inheritance via the isDefault attribute, like: <style isbold="true" name="abstractStyle" type="text/css">| <style name="recordStyle" isDefault="true" style="abstractStyle" fontName="Serif"/> ResolutionOne workaround is to change your styles for the reports to not use isDefault. Another workaround is to edit WEB-INF/classes/jasperreports.properties in JRS or the .properties file in your non-JRS app and add the following,: net.sf.jasperreports.styles.inherit.from.default=false Ref. Case 01714605 http://jasperreports.sourceforge.net/config.reference.html#net.sf.jasperreports.styles.inherit.from.default

Issue DescriptionCertain characters only render correctly via a particular encoding. For example source data might contains special characters, like foreign-languate accents and inverted question marks for example. When exported to CSV, the characters might be look incorrectly since the JR default encoding is UTF-8 ResolutionA property exists that lets you specify the character encoding for export: http://jasperreports.sourceforge.net/config.reference.html#net.sf.jasperreports.export.character.encoding It can be set in config file or within the JRXML individually. Example jrxml tags are: <property name="net.sf.jasperreports.export.character.encoding" value="Cp1252"/> UTF-8 is default, but you could do others, like these jasperreports.properties examples: net.sf.jasperreports.export.character.encoding=ISO-8859-1 OR net.sf.jasperreports.export.character.encoding=ASCII Note, a defect existed in 6.2.x in which this setting was ignored. So please upgrade if you're hitting this in 6.2.x and the original release of 6.3.0. Ref. Case 01654457

Issue DescriptionDepending on the export type you might want not want to show a particular element. For example in CSV you might want to show tables but no charts, or in PDF you might not want to show images ResolutionIn other wiki articles you can find information for hiding entire bands, but you can also hide things at an element level. In the report element, add a key: <reportElement key="myFavChart" .... Then to conditionally hide that element use an export filter property like the following if you want the chart hidden from PDF. The property could be globally set in your jasperreports.properties file, or at a report level in your jrxml: <property name="net.sf.jasperreports.export.pdf.exclude.key.myFavChart"/> This property is is documented in the section "Export Filters" of the JasperReports Ultimate Guide, and the config reference is here: http://jasperreports.sourceforge.net/config.reference.html#net.sf.jasperreports.export.{format}.exclude.key.{suffix} This property is is documented in the section "Export Filters" of the JasperReports Ultimate Guide, and the config reference is here: http://jasperreports.sourceforge.net/config.reference.html#net.sf.jasperreports.export.{format}.exclude.key.{suffix} Ref. Case 01424846

Issue DescriptionWhen browsing HTML export (in JRS, or otherwise), certain report designs result in a border lines or horizontal lines that expand infinitely, beyond expected width of the elements and page. This doesn't occur in other export types and it only occurs in Chrome ResolutionThis is occurring due to a bug in Chrome that has existed for many years. They haven't fixed it yet, so we cannot guess time-wise when they'll fix their bug. While waiting for the Chrome bug to be fixed, customer can try a setting which could mitigate the infinite line, but might be accompanied by a few side-efects. Set this property either globally or per report: http://jasperreports.sourceforge.net/config.reference.html#net.sf.jasperreports.export.html.border.collapse Using border-collapse as "separate" solves the infinite line problem, but the borders appear thicker, especially if they have sub-unitary thickness (hairlines and such). They also appear to double in thickness when two adjacent cells both have borders, which add up, instead of being superimposed. This can be solved by modifying the styles of cells so that borders be present only on one of the cells. There might be some mis-alignment of borders at cell corners, if a continuous line is made up of consecutive cell borders that are coming from upper cell or lower cell alternatively. Ref. Case 01393297

Issue DescriptionA customer imported their repository into an entirely new environment and found that the domain-designer no longer prompted them to choose a schema from their postgres datasource ResolutionThe customer's new environment is using postgres 10 and their jdbc driver was older, postgres 9.2. Apparently postgres has defective credentialing or authorization when using this mismatch of versions. The problem was resolved by upgrading the JDBC driver in WEB-INFlib to postgres version 9.4.1210 or higher Ref. Case 01647174

Issue DescriptionWhen using TIBCO Jaspersoft® Studio, a user upgraded their source database to Postgres 10 and found that the connection was pulling back tables for different user-schema's than expected based on the user in the connection string. Additionally this problem did not reproduce within TIBCO JasperReports® Server when pointing a new domain with the same connection string against this same database ResolutionThis can occur if you are using an old postgres Driver. It is always good practice to match your driver version with your database version and in this case the Postgres software clearly has a buggy behavior when version 10 DB is used in conjunction with older versions of their driver. Your JasperReports® Server instance probably has a newer version of the postgres JDBC driver (we ship version 9.4). You should test with a newly created new data-adapter that uses a newer version of the postgres driver that you fetch from Postgres (or use the file in JRS). You can specify the jar in "Driver Classpath", per the documentation below: https://community.jaspersoft.com/documentation/tibco-jaspersoft-studio-user-guide/v71/working-database-jdbc-connections-0 Ref. Case 01678802

Issue DescriptionAfter upgrading to TIBCO JasperReports® Server 7.1.0 a customer was attempting rest request to the queryExecutor service, like: GET http://localhost:8080/jasperserver-pro/rest_v2/queryExecutor/Domains/Stuff?... The user had read-only permissions, and this request was fine in previous versions, but in 7.1.0 they received a 403 Forbidden HTTP response. Using superuser worked fine, indicating a permission or role problem. ResolutionA config file problem exists in 7.1.0, which will be resolved in a future version. The workaround is to edit WEB-INFapplicationContext-security-pro-web.xml config file to change which roles have permissions to call REST_v2 functions Near line 45 in 7.1.0, accidentally, the pattern to allow ROLE_USER role access to call queryExecutor was removed from that bean: <security:intercept-url pattern="/rest_v2/queryexecutor/**" access="ROLE_USER,ROLE_ADMINISTRATOR"/>[/code]In order to make REST API for queryExecuter work for your role, you should manually add the above line to config file, for example after: <security:intercept-url pattern="/rest_v2/domains/**" access="ROLE_USER,ROLE_ADMINISTRATOR" />[/code]Ref. Case 01646519

Issue DescriptionCustomers are curious about anti click-jacking HTTP headers such as X-Frame-Options and Content-Security-Policy, along with other security-oriented HTTP headers ResolutionPrior to 7.1, customers can enable these headers outside of TIBCO JasperReports® Server within their web appliance layers like their application server, webserver, proxy, router and or load-balancer. There are numerous internet articles on the subject of enabling these. In 7.1.0 we've added a new filter which helps you optionally add a few specific HTTP headers like X-Content-Type-Options, X-Frame-Options, Content-Security-Policy, X-XSS-Protection, and Strict-Transport-Security (aka HSTS) . These can be enabled in WEB-INFapplicationContext-security-web.xml. A restart is required. See also the 7.1.0 > Security Improvement section in https://community.jaspersoft.com/documentation/tibco-jasperreports-server-release-notes/v790/changes-previous-versions#Version7.0.0 for details on the antiClickJacking-related properties. Official documentationAnti click-jacking features are now fully documented in section 4.7 Protecting Against Clickjacking Attacks of the latest Security Guide, see: https://docs.tibco.com/pub/js-jrs/8.0.0/doc/pdf/TIB_js-jrs_8.0.0_Security-Guide.pdf?id=3

Issue DescriptionAt least as of TIBCO JasperReports® Library 6.x the xpath2 query executer is deprecated and the 'internal' parameter XML_URL is of course deprecated since it worked in concert with the Xpath2 query executer. When running a JRXML configured for Xpath2 in the newer versions of JasperReports® Library an error will occur like: Caused by: java.lang.NoSuchMethodError: net.sf.jasperreports.engine.query.JRAbstractQueryExecuter.<init>(Lnet/sf/jasperreports/engine/JRDataset;Ljava/util/Map;)V at com.jaspersoft.jrx.query.JRXPathQueryExecuter.<init>(JRXPathQueryExecuter.java:79) at com.jaspersoft.jrx.query.JRXPathQueryExecuterFactory.createQueryExecuter(JRXPathQueryExecuterFactory.java:114) at net.sf.jasperreports.engine.util.JRQueryExecuterUtils$WrappingQueryExecuterFactory.createQueryExecuter(JRQueryExecuterUtils.java:135) at net.sf.jasperreports.engine.fill.JRFillDataset.createQueryDatasource(JRFillDataset.java:1242) ResolutionXPath as a query language is still fine and Xpath query executer is now bundled with JasperReports Library. To use it ,the 'xpath2' can be replaced with 'XPath' in the queryString language of a JRXML. So instead of <queryString language="xpath2">, you'd use <queryString language="XPath"> Since XPath is bundled with TIBCO JasperReports® Server./JasperReports Library. now, you don't need to edit jasperreports.properties to define the query executer. In earlier versions when using xpath2 an internal parameter named XML_URL could be used to define the incoming source of data for the datasource. XML_URL is now deprecated but an easy workaround exists if your reports make use it in older versions. A new parameter, 'net.sf.jasperreports.xml.source' exists that can act as the definition of the incoming source of your xml to your datasource. And you can set its value via parameter. So try the following so that net.sf.jasperreports.xml.source will be set to the same value as XML_URL in your original use-case: <parameter name="net.sf.jasperreports.xml.source" class="java.lang.String" isForPrompting="false"> <defaultValueExpression> <![CDATA[$P{XML_URL}]]> </defaultValueExpression> </parameter>Ref. Case 01524144

Issue DescriptionWhen using relative dates you might want an actual date, like 2018-05-20 rather than seeing the DateRange expression like "WEEK-1" ResolutionParameters that are type net.sf.jasperreports.types.date.DateRange can consume actual dates from a java.util.Date object or DateRange expressions, strings like "DAY-2", "MONTH+1", etc. A common syntax seen is: <parameter name="Parameter1" class="net.sf.jasperreports.types.date.DateRange"> <defaultValueExpression><![CDATA[new net.sf.jasperreports.types.date.DateRangeBuilder("WEEK-14").toDateRange()]]></defaultValueExpression> </parameter> In the typical use case like the parameter above a string expression will be inserted into the TIBCO JasperReports® Server input control dialog: Since the parameter can consume java.Util.Date objects you can have an actual date presented in the input control dialog. Your defaultValueExpression that calls can call DateRange object's getStart() or getEnd() methods below to output an actual date that corresponds to your range, like: <defaultValueExpression> <![CDATA[new net.sf.jasperreports.types.date.DateRangeBuilder("WEEK-14").toDateRange()]]> </defaultValueExpression>Or you can specify the exact actual date by using any other java expression that returns a valid java.util.Date, like: <defaultValueExpression> <![CDATA[new java.util.Date()]]> </defaultValueExpression> Reference: http://jasperreports.sourceforge.net/api/net/sf/jasperreports/types/date/DateRange.html Ref. Case 01655957

Issue DescriptionAfter upgrading to 7.1.0 a customer's TIBCO Jaspersoft® Studio connections were broken. Hitting "test connection" in the "...Access Configuration" dialog box resulted in a 404 error. Things are fine in TIBCO JasperReports® Server. Nothing changed in terms of users. ResolutionThis customer was using a custom authentication. Unbeknownst to them, their primary url which Jaspersoft® Studio attempts for authentication was always silently failing when they hit "test connection", but the attempt was silent because Jaspersoft Studio rolls to a secondary authentication attempt that makes use of SOAP based webservices. The primary attempt is like: Second attempt is like: Reviewing appserver access logs, and runtime logs it was evident the primary was erroring in 7.1.0 as well as the version prior. In the version prior however the SOAP attempt of authentication would be fine, so the customer never new the primary problem exists. In 7.1.0 SOAP webservices have been removed entirely. So the secondary attempt results in the 404. Since SOAP no longer exists the workaround is to correct the Authentication customization so that the primary attempt works. In this customer's case the workaround was to swap the AuthenticationProvider order in the AuthenticationManager bean so that the internal auth (DAO Provider) was first, but of course every customization is unique and different so should be corrected and owned by the customer's developers.

Issue DescriptionA customer wants to create a report which shows the "next run" values for Schedule jobs, but they're having trouble finding the values ResolutionThe fields prev_fire_time and next_fire_time in qrtz_triggers table are the fields which show the "previous" and "next" runs times. Note that these are EPOCH dates. For better readability you could use a derived table via a domain. You'd write a query to perform your formatting to return a string or a java.sql.Timestamp, etc from EPOCH. At runtime the query will be dumped inline into the main query that is generated by the domain layers. See: http://community.jaspersoft.com/documentation/tibco-jasperreports-server-user-guide/v640/derived-tables-tab Ref. Case 01527535

Issue DescriptionCustomer noticed the following error in their logs: "No message found under code 'null' for locale 'en_US'" ResolutionIt was determined that the error occurs during this request: shows this error occurring when you do a GET /jasperserver-pro/rest_v2/hypermedia/contentReferences?group=popular This wasn't reproducible so we asked the customer to the search their config for possible customizations that they weren't aware of. They found they had customized WEB-INFapplicationContext-rest-services.xml. They had an incomplete KEY surrounding the 'popular' content resources section. All keys need valid titles, descriptions, etc. Ref. Case 01559637

Issue DescriptionA customer's report works fine in TIBCO Jaspersoft® Studio, but an error occurs when running in TIBCO JasperReports® Server: Processor of type com.jaspersoft.jasperserver.war.cascade.handlers.converters.DataConverter for class net.sf.jasperreports.types.date.RelativeDateRange not configured The jrxml has a parameter of type net.sf.jasperreports.types.date.TimestampRange with a default value of (new net.sf.jasperreports.types.date.DateRangeBuilder("DAY-20")).toDateRange()) In the query the .getEnd() method is called on the parameter. ResolutionJasperReports® Server input control resolution requires code that doesn't occur within Studio's simple controls. In this case JasperReports Server doesn't like the use of DateRangeBuilder with TimeStampRange. To workaround this, EITHER use DateRange as your class OR use set(java.sql.Timestamp.class) in your expression, like: new net.sf.jasperreports.types.date.DateRangeBuilder("DAY").set(java.sql.Timestamp.class).toDateRange() In the first approach everything will be date only, in the second approach date-timestamp format will be used. We touch on this here: https://community.jaspersoft.com/documentation/tibco-jaspersoft-studio-user-guide/v640/using-parameters-queries Ref. Case 01567184