pdanyliuk

Try the following: 1. Create a folder in Public, e.g. Public > Reports for Organization 1 2. Create a role in Organization 1, e.g. ROLE_ORGANIZATION1 3. Add all users from Organization 1 and its suborganizations to ROLE_ORGANIZATION1 (right there on Manage Roles page in the right pane) 4. For your folder Public > Reports for Organization 1, assign the following permissions: - ROLE_USER: No access - ROLE_ORGANIZATION1: Read + Write + Delete Now the users with ROLE_ORGANIZATION1 will see this folder and be able to put reports there, and users without that role won't have access to the folder. As a bonus, you can revoke access for some users or a specific suborg by unsetting the role from them.

Hello, Do you mean placing the XML file in repository? Because REST services that a PHP client is operating through is capable only of what REST services are capable of. If you need to place an XML file in deployment directory, there's no way to do this using the client.

Hello, Unfortunately, there's no way to share a report between organizations without using public folder. What you can do is assign all users that you want to share your report with a specific role, place the report in public folder (or a subfolder of a public folder), and then allow access only for users with that role.

Hello. Can you please be more specific with how you try to get the report and then display it?

csharbel_1, With regard to a lot of scripts loaded — there was RequireJS modularization in one of the previous releases. This is a known issue and is being addressed.

You can create reports using only JRS but with very limited possibilities (Ad Hoc reports, which are just tables, crosstabs or charts (one per report), and lack input controls). To create rich, branded reports you'll have to use Jaspersoft Studio (a standalone report designer) or iReport (another standalone report designer, older than the Studio).

There are a few things to know about PATCH: - to patch a resource, you have to provide the field "version", which has to be current (it's an optimistic locking mechanism that prevents from overwriting someone else's changes that were made while you were operating on it). The same for updating via PUT, so to say. - IIRC you cannot patch inner resources from outer resources. So if you want to patch a data source of report, you have to patch it directly by its URI (regardless if local or external). - you don't have to send all sub-resources in a PUT request when updating only the base resource - just provide the references how you GET'ed them, so if that was your concern about PUT vs PATCH - there is no such problem, and you don't have to use PATCH. While I agree that the documentation might be not very clear and obvious to follow, it should contain all information about the service (I personally checked that nothing was missing or inaccurate in a working draft doc - not sure how much of it made it to the final doc). The only complexity comes from variety of resources, but the principles are simple and the same for this service and most of the rest of RESTv2 API. Also if you are using Java or PHP, check out the official clients: https://github.com/Jaspersoft PHP client is not stable yet, having some issues with composite resources that will be fixed soon, but for everything else you can use it.

Out of curiosity, what was that?

With your report link, try this for illustrative purposes GET http://172.16.4.66:8080/jasperserver/rest_v2/resources/reports/CustomersReport Accept: application/repository.reportUnit+json or +xml should return report unit descriptor with all dependencies (JRXML, Data Source etc) returned as references. In obtained data change label and description and send it in PUT request to the same URL with the following mandatory header: Content-Type: application/repository.reportUnit+json or +xml Accept: the same as previously, or simply application/json or /xml Creating a resource can be done with the same descriptor either by PUTting it at arbitrary URI (e.g. PUT http://172.16.4.66:8080/jasperserver/rest_v2/resources/reports/MyNewReport) or POSTing to a parent folder (e.g. POST http://172.16.4.66:8080/jasperserver/rest_v2/resources/reports) - in this case resource ID will be generated out of its label. You can also try to GET your report with parameter expanded=true: GET http://172.16.4.66:8080/jasperserver/rest_v2/resources/reports/CustomersReport?expanded=true in this case it will resolve all referenced resources recursively. If this works for you, I encourage you to learn RESTv2/Repository service to grasp the concepts behind it. Report Unit is a composite resource (contains own metadata PLUS references to other local or external resources), so for learning you can start with something simpler like JDBC Data Source.

Hello tonyy, I'm not very familiar with REST v1, so I cannot provide much help there. But FYI, REST v1 services (/rest/*) are discontinued and replaced with newer and better REST v2 services (/rest_v2/*). If you have JRS 5.5 or later, then you can use REST v2 Repository service to create/edit your report units — that should be easier, and besides both XML and JSON are supported. You can find information on that in JRS Web Services guide here: http://community.jaspersoft.com/documentation/jasperreports-server-web-services-guide/v550/v2resources-service Please let me know if you can use RESTv2 and if you have any troubles using it. With best regards, Paul Danyliuk

And yet another official JasperServer client: https://github.com/Jaspersoft/jrs-rest-php-client, currently under development but you may give it a try.

I am working with REST API all the time and I haven't, but that's an interesting observation. What JRS version are you using?

Oh... I never worked with invisible input controls and don't know their purpose, but just an idea — you can try schedule a job using REST v2 API and submit such parameter and see what happens. Although if you need to introduce some sort of security (e.g. fetch different data for Administrator and Staff), you probably shouldn't rely on invisible input controls. In reports there is a way to obtain the user who launched them — I'm not sure how, but in sample report Sales By Month I saw such functionality.

If you are seeking the possibility to create reports from SQL queries 'on the go' — sorry, but this is not what JRS can do. To create reports you need a tool to author jrxml files: Jaspersoft Studio or iReport. Professional version of JRS also has Ad Hoc Editor, where one can create simple table, chart and crosstab views from domains and topics. But the point of JasperReports Server is to serve as a repository for already created reports, generate them on specified schedules, and provide access control. The furthest that JRS API can do is creating a ReportUnit resource with required dependencies and running its export as html/pdf/rtf/etc. But for that you need to have your jrxml file prepared. With regards to PHP clients, the next big thing is https://github.com/Jaspersoft/jrs-rest-php-client. It is still in development and testing, but it's a new client that uses the new (v2) JRS REST API.

Hello. I don't think it's possible in JRS at all, regardless if using PHP client, any JRS API or UI. The concept of report in JRS is that you already have a particular query tied to the data source this report is based on, and then you optionally specify parameters that you can pass; e.g. "select * from department as dep where dep.department_id=$P{department}". Then you create input controls for this report tied to each parameter, and when running this report, you specify parameter values (either type in or select an option from the list retrieved from DB — dependent on how you created your IC), and they get inserted in the query. If you could pass a query, not only you would have made it very error-prone (as the user needs to know what fields with what names and types to return), but you also would have exposed your server to SQL injection attacks. There is a possibility to override query in jrxml with query in report — if you have editing rights, you can set arbitrary query in Edit Report -> Query page. Maybe you find it helpful if you need to quickly override the query on the server for all users.