The Report Server is localizable. However, its viewer is not.

The viewer cannot be customized either. For example, if you want to make the default View mode PrintPreview.

The above require changes in the CSHTML template of the Preview, which would be reset upon the Report Server upgrade.

It would be great if the customization and localization of the Report Server Viewers became part of the configuration, allowing them to be preserved between upgrades.

The Report Server is localizable. However, its viewer is not.

The localization of the viewer requires adding a new JavaScript file with the translation and referencing it in the CSHTML template of the Preview, which would be reset upon the Report Server upgrade.

It would be great if the localization of the Report Server Viewers became part of the configuration, allowing them to be preserved between upgrades.

For example, the 'Activity' and 'items per page' in the Scheduled Tasks are not available in the 'sr.js' file:

This doesn't let us translate the whole Report Server.

We have a scenario where some groups need to have reporting info that is not visible to other users on the Report Server instance.  I can assign permission limiting access to report categories and data connections, but I don't see a way to limit shared data sources. 

Imagine, for example, a scenario where payroll wants to include an ADP data feed in their reports and they want to save it as SDSX to use in multiple places.  As far as I can tell, all other report editors on the server can now load and use that SDS.

I should be able to determine what SDSX files each user can access in the same way that I can for specific reports.

The Report Server mail templates have a variable named "link" which should provide a link to the exported document for the email receiver.

However, this link does not use the Report Server's public address set through IIS, instead, the link uses the "http://localhost:83" as a base URL for the link.

Please correct the behavior and/or allow for changing the links' base URL.

Currently, the POST api/reportserver/v2/documents endpoint is available only for the standard version of the Report Server.

Consider adding it to Report Server for .NET as well.

The assemblyReferences, typeReferences, and typeValidation configuration elements are not respected from the TelerikReporting.config files of Report Server Manager and ServiceAgent.

The same settings are respected when set in the corresponding Web.config and Telerik.ReportServer.ServiceAgent.exe.config.

When I try to use the Report Server for .NET 2025 Q1 in a Docker container, I get the following error in the logs:

"An error occurred while checking the licenseResult: The value cannot be an empty string. (Parameter 'path')."

The error does not seem to prevent the Report Server Manager from remaining functional.

Hi Team,

Currently when Report Server has whitelabeling enabled, the browser tab will still show "Page | Telerik Report Server". This request is to allow us to set a value for the 2nd half of the page title.

I see this is applied by using the @ViewBag.Title, my request is to have a field in the Whitelabeling settings page for a brand name in the title. This could be combined with the page name to have a customized title. For example "Page Name | Whitelabeled Name".

Here's a visual example to explain further

Thank you,

Rick

We need to send emails to specific people only when Errors occur in scheduled reports. They shouldn't receive the scheduled reports when there are no errors.

For example, there may be a new user role added for this purpose.

Hi Team,

This feature request is to ask that a capability be added to Report Server that restricts certain administrative functionality to only be allowed on predefined subnets (e.g. adding new users, data sources, etc.).

Thank you,

Amish

Currently the Report Server appears to keep the execution history of scheduled report tasks indefinitely.  The task execution history is a very useful feature but there appears to be no way to limit the history to a certain amount of time.  For our use case it is unlikely that we will need to go further back then 1 or two months in the history and as we get months an even years of history (which includes the execution and related documents) the time needed to backup and restore the Report Server increases.  We only have about 30 scheduled reports that run each day but over a year that is 10,000+ executions that are stored and anything over a month or so old has little value to us.  I am not sure if these also have an impact on the overall performance of the Report Server or at least the Scheduler portion of the UI but that would be another reason to limit the retention.

Currently the only method to delete the executions is to either (a) do it manually via the UI (screenshot below) or (b) to write an application that deletes executions outside our retention window using the API to query and then delete them.  Method (a) is too time consuming for a person to do and (b) will require writing the application but then also monitoring it's status and keeping up with any changes in the API over time.

I would propose adding some method of allowing users to set a "retention period" for scheduled task executions.

• The retention period would ideally be able to be set globally and overridden for a particular task
• The retention period would be specified in days
• To actually remove the old executions you could create a task that runs once a day and is executed by the windows service that exists -OR- each time the task executes to run the report it can also look to see which historical executions are older then the retention period and delete them.
• The removal of the historical tasks should also delete any associated documents

Implementing this would allow for much quicker upgrades, backups, and restores of the Report Server.