cbarlow3

We have a client who has somehow managed to create two FOLDERS under /organizations and is now unable to delete these folders. If Jaspersoft Studio or JRS is used to attempt to delete them as though they were normal folders, it runs into an issue where because they are directly below /organizations/, Jaspersoft treats them similar to actual organizations and does not allow deletion. But if you go into Manage | Organizations in JRS, they're not listed of course, because they are not actual organizations--just folders that were created in the same place in the repository tree where an actual organization would be created. I believe the client was trying to create organizations and somehow in Jaspersoft Studio just created folders instead (in Jaspersoft Studio 7.1, I no longer see an option for "New" when you right click on /organizations, so I'm not even 100% sure how they did it--Jaspersoft Studio 5.6 still allows "New" at this level but then gave an exception when I tried to duplicate the problem by creating a folder at that level in a sandbox environment). Any ideas on how I can get rid of them safely? So far my only thought is to (after first backing up the Jaspersoft database) try the following command as a user who has read/write access to that database: DELETE FROM JSPRSRVR.JIRESOURCEFOLDER AS JIRESOURCEFOLDER WHERE JIRESOURCEFOLDER.URI='/organizations/fakeorg1' OR JIRESOURCEFOLDER.URI='/organizations/fakeorg2' But I have no way of knowing for sure that this is the only reference to those folders/resources in the Jaspersoft database, and I certainly don't want to end up with an inconsistency that comes back to bite me later.

That link is now broken, and I am having a hard time finding the solution for where to configure this at the server level. @hozawa, do you know the exact path and filename of the configuration file(s) involved (or have an up-to-date link for this)? I couldn't find anything here on the community page, nor in the JRS Admin Guide or JRS User Guide so far. Thanks!

The only thing more amazing than the fact that these questions and answers are still available nine years later is that many of these solutions still work! :)

We are in the process of upgrading our clients from JRS 5.6 to 7.1, and they are noticing a problem with new (non-legacy) dashboards filling only a tiny section of the screen during runtime. In the legacy dashboard designer, there was an "Options" button that controlled a dropdown menu that had one option called "Guide" that let you pick the usual screen resolution you were designing for (the five standard options were 1280 x 1024, 1280 x 768, 1152 x 64, 1024 x 768, and 800 x 600). There was also an option to select "Fixed Size" or "Proportional Size", and I believe this controlled whether or not the dashboard was dynamically resized during runtime (the "Proportional Size" selection had no effect during design itself). The v5.6 JRS User Guide recommended designing dashboards with "Fixed Size" selected (and presumably choosing the most common screen resolution amongst the anticipated users of the dashboard), and then changing it to "Proportional Size" right before saving. Starting with the new dashboard designer introduced in v6, I can't find similar options mentioned in the JRS User Guide, nor can I find them within the UI. I do see a Dashlet specific Property called "Scale to Fit", where the possible choices are "None", "Width", "Height", and "Dashlet" (what exactly does it mean to scale a dashlet to the size of the dashlet?), but I don't think this accomplishes the same thing. Does anyone know where to find the equivalent of the Options | Guide setting and the Options | Fixed/Proportional Size setting? If not, does anyone know the best way to resolve the problem of new dashboards not scaling properly at runtime?

We recently started having our clients upgrade from JRS 5.6 to JRS 7.1, and some of them are reporting the same thing. I seem to be able to have multiple JRS tabs working just fine in Firefox 68.0.2 (most of our client use Firefox, although we don't control exactly what version they're on), nor on Chrome Version 76.0.3809.132. I know your original question is from nearly two years ago. Did you ever resolve the issue?

By the way, the CR.Jaspersoft.getResourceParams in the above code retruns a JavaScript object with properties that represent each parameter, e.g.: { KeyStone_userName: 'admin', KeyStone_branchName: 'Point Loma', // etc.}

When we were using JRS 5.6, our application was able to use visualizer.js to run a JRS dashboard, and it was able to pass some environmental parameters (user, branch, etc.) to the dashbaord, which it in turn would pass to the consituent reports (now "dashlets"). That way the reports could be written to filter results based on the passed parameters rather than having to prompt for this information. We have recently been testing JRS 7.1, and it appears that the parameters we pass to the (new, non-legacy) dashboards are not being passed on to the dashlet reports. Has anyone else run into this, and does anyone know the correct way to pass parameters to a dashboard now that will still trickle down to the reports? Here's an example of how we launch a dashboard from within our application: v.dashboard({ resource: args.dashboard, container: '#container', params: CR.Jaspersoft.getResourceParams(), success: function() { CR.Jaspersoft.log('CR.Jaspersoft.displayDashboard success', args.dashboard); }, error: function(e) { if (e.errorCode === 'invalid.resource.type' && CR.Jaspersoft.redirectURL) { CR.Jaspersoft.warn('CR.Jaspersoft.displayDashboard redirecting legacy dashboard', args.dashboard); window.location = CR.Jaspersoft.redirectURL; } else { args.failure(e); CR.Jaspersoft.messageKeyStone({ message: 'Dashboard Error:' + args.dashboard, error: e }); } } });[/code]

Using preview successfully in JasperSoft Studio, but I need to know more about any disk files that are created when previews are created: 1. Are there any disk files, or is the preview in memory only? If there are disk files, where are they located on Windows 10? 2. Does the answer depend on what preview mode (Java, HTML, PDF, etc.) you are using? It looks like when I preview in PDF, a temporary pdf file is created in C:UsersmyUserNameAppDataLocalTemp. 3. If disk files are created, are they automatically deleted upon exiting JasperSoft Studio or upon running another query or closing the preview pane, or...? Is there a setting for cleaning up any temp files? I see a "Delete Temporary Files On Exit" checkbox under Preferences | Jaspersoft Studio | Report Execution, and it's checked (a default upon installation, I suspect), but I have some preview formats mapped to external programs (Excel, Adobe Acrobat Reader DC, Word, etc.), and the temporary files I'm seeing so far that I've found when an external viewer is used don't seem to be deleted when I exit the external program, the preview pane, or even Jaspersoft Studio, so I don't think this checkbox is doing everything I had hoped. The reason I'm asking is because when we are designing and testing reports, they sometimes include personal information from a database that does not reside on our individual workstations, and I want to make sure the personal information doesn't still exist on the workstation when we are finished working in JasperSoft Studio. It may be that a temporary solution is to insist that our developers only preview in Java/internal format, but there are times when we need to test Excel, etc. if we know that is the intent of the end user.

Glad that worked for you! On a related note, one thing that's very different about Jaspersoft Studio 5.6 vs. when I used to use iReport 3.7 is the publishing feature (the button that lets you publish the report to JasperReports Server). It took me a little getting used to for some reason as compared to the right click | create method in the repository navigator. One tip for when you are publishing a report where one or more of your input controls are supposed to be links to existing input controls instead of local resources: when the list of input controls comes up in the publishing wizard with checkboxes checked, right click on one that is supposed to be a link instead and the choose the option that says you want to create a link to an existing input control, and it will prompt you to drill down and select that resource from the repository (so make sure you've created it BEFORE you try to publish your report). Repeat for any other input controls that should use links.

Martin, I think your two problems (can only select a single item and getting an error back that you are using a String where you want an array or collection) are related, and you're REALLY close to the functionality you're looking for. My original post was from when I was using iReport 3.7. Now I'm using Jaspersoft Studio 5.6. In the repository explorer, find the input control that you created, double click it to bring up the Resource Editor, make sure you're looking at the "Input Control" pane, and set the "Type" dropdown to read "Multi Select Query" (I'm guessing that yours is currently set to "Single Select Query", which is also useful, but it returns a single string rather than a collection/list). Then save the change and test. The multi-select experience for the end user is different than it used to be back in 3.7. Now you just use a normal left click to turn on or off selections one at a time. You used to have to use CTRL to select individual items that weren't next to each other. Play around with that, but I think if you just change that type field on the input control definition, it will allow you to select more than one item and will also return the data type that the parameter is expecting and then work in the $X{} part of your WHERE condition. Please post whether you get it working or not.

Thanks for the update. My use case doesn't really have anything to do with importing a single data adapter for a specific report. My situation is that I have a large list of data adapters that I have defined in my Jaspersoft Studio environment, and I just wanted a coworker to be able to have all those same ones defined without tediously creating them one at a time. Similar to how I can in some (all?) browsers select a lot of my bookmarks, export them to a single file, and then send that to a new coworker to import so they have all the ten most useful bookmarks for getting things done around the office.

Thanks, hozawa. We were pretty sure we had opted out of the heartbeat, but just to make sure, we did modify the file you mentioned, bring down the instance of Tomcat and brought it back up (without our workarounds in place), and it again took 19 minutes to come up. I think the js.config.properties file configures the instance to prompt or not prompt for the opt-in and also to set the default value, but the actual opt-in information for each operating system user (AIX user in our case) is STORED in the user's home directory in a subdirectoy called .jaspserserver in a file with a long hex name (the one we have on our system we're testing with happens to be a filename of 89D4743F9A031BD26014D513992AE4DB, for example). Our file looks like this: #heartbeat local ID file #Wed Sep 17 13:58:40 CDT 2014 version=5.6.0 heartbeat.id=4595214 permission.granted=false So I think there must be some other nefarious connection at work besides the heartbeat.

If you still have a user "superuser" (we work with multi-tenancy, so we find such a user who has access across multiple "organizations" useful), you could log on as that user, and you should have the ability to Manage | Users, then select user "jasperadmin", Edit, then fill in "Password" and "Confirm Password" fields, and then click "Save". Of course, I'm guessing if only one person knew the password for user "jasperadmin", then probably that same person is the only one who knew the password for "superuser", but I thought I'd mention it just in case either someone there knows it or in case it was never changed from the default password of "superuser". Carl

We were experiencing really strange performance issues with JSR 5.6 on AIX/DB2 with Tomcat (like the Tomcat instance taking about 19 minutes to start up vs. around 50 seconds we were used to in other installs), and after looking through the Tomcat logs, we discovered a couple of mysterious problems that we can work around, but that we would rather find out more info on if possible, as they look like pretty serious security issues: 1. Apparently JRS is contacting some server(s) on the internet during the startup process. Since this particular install has a firewall configuration that doesn't allow that, it eventually times out and continues with the startup. We know we opted out of the heartbeat message already. Is there some other outgoing message that we need to configure, and if so, what is it, what is it for, and how do we opt out of it as well? Our workaround is an environment variable setting that limits host name resolution, which prevents it from wasting time trying to connect to any internet servers. 2. Additionally, JRS is now "listening" on two different socket ports. One of them (10990) is documented in the JRS guide as the default diagnostic port, and is configurable so that we can turn it off. But we have not found any mention of the other one. The other port does not seem to be fixed at a specific port number--while the 19 minute startup is happening, we saw tha tit tried listening on a bunch of ports in succession (like 42556, then 42557, and so on). Wehn it finally comes up after 19 minutes, it has settled on a port, but it is a different one every time. It appears to be related to issue #1, because when we put in place the workaround for #1, the Tomcat instance does NOT end up listening on an extra port. It is almost as if JRS is trying to contact an outside internet server, as well as trying to listen on a port so that the outside internet server can initiate a connection back to Tomcat. Just about any firewall setup won't allow this to occur, so we're not sure what JRS is trying to accomplish, but it sounds like a pretty scary security concern. Does anyone know any details on what these attempted external communications are and what the correct way is to disable them? Thanks. Carl Barlow

I highlighted 17 Data Adapters that I use and selected "Export To File". Annoyingly, it created 17 separate files (there should be an option to create a single file, since the documentation for Jaspersoft Studio claims that you can import multiple adapters from a single file), but I pasted them together into a single xml file and sent a copy to a coworker, who copied that xml file into his Jaspersoft Studio workspace. Then he went into Repository Explorer, right clicked on "Data Adapters" and selected "Import From Workspace". Nothing happened. No error. No dialog to search for the xml file in the workspace. Nothing. Even though I created the xml file and therefore don't really need to import them, I tried at least selecting that same option to see if I also got the same results--I did. It never comes up with a dialog for you to select the import file(s). Has anyone successfully used this feature in Jaspersoft Studio 5.6 or is this a known bug?