In the standalone designer, it would be helpful if you could drag and drop the column headers to reorder.  At present you have to add a new column and delete the old one, remembering to copy all properties.

Currently, the Native Angular Report Viewer does not support NodeJS 22. It is restricted to v16-21 of NodeJS and I would have to downgrade to use it.

We have reports that contain a table of images. This seems to work great in the designer and when generated to a PDF without accessibility turned on. However, with accessibility turned on and rendering to a PDF, it throws an exception:

System.NullReferenceException: Object reference not set to an instance of an object.
   at Telerik.Reporting.Pdf.PdfAccessibilityElementWriter.TryAttachToParentNode(ProcessingInstanceIdentifier id, PdfOrderedReference element, Int32 rowIndex, Int32 columnIndex)
   at Telerik.Reporting.Pdf.PdfAccessibilityElementWriter.TryAttachToParentNode(IProcessingElement processingElement, IProcessingElement parentProcessingElement, PdfOrderedReference taggedElementReference)
   at Telerik.Reporting.Pdf.PdfAccessibilityElementWriter.AttachNonLeafNode(LayoutElement element, PdfOrderedReference taggedElementReference)
   at Telerik.Reporting.Pdf.PdfAccessibilityElementWriter.InitTaggedElement(AccessibilityPdfElement pdfElementType)
   at Telerik.Reporting.Pdf.PdfAccessibilityElementWriter.AddFigureElement(ITableCell element)
   at Telerik.Reporting.Processing.ProcessingElementVisitor.Visit(LayoutElement element)
   at Telerik.Reporting.Writing.AccessibilityElementWriter.StartWrite(ReportItemBase element, Int32& index)
   at Telerik.Reporting.Writing.VisualElementWriter`1.StartWriteAccessibilityItem(ReportItemBase item, ElementPageInfo pageInfo, DocumentWriter writer)
   at Telerik.Reporting.Writing.VisualElementWriter`1.WriteClientFocusableItems(T element, ElementPageInfo pageInfo, DocumentWriter writer)
   at Telerik.Reporting.Writing.ReportItemBaseWriter`1.StartWrite(T element, ElementPageInfo pageInfo, DocumentWriter writer)
   at Telerik.Reporting.Writing.ElementWriter`1.Telerik.Reporting.Writing.IElementWriter.StartWrite(LayoutElement element, ElementPageInfo pageInfo, DocumentWriter writer)
   at Telerik.Reporting.Writing.WriteOperationsDispatcher.Visit(PictureBox pictureBox)
   at Telerik.Reporting.Processing.ProcessingElementVisitor.Visit(LayoutElement element)
   at Telerik.Reporting.Writing.DocumentWriter.Telerik.Reporting.BaseRendering.IWriter.WriteStartElement(LayoutElement element, ElementPageInfo pageInfo)
   at Telerik.Reporting.Paging.PageElementsLayer.OutputToPage(IPageHandler handler)
   at Telerik.Reporting.Paging.PageContent.Output(IPageHandler handler)
   at Telerik.Reporting.Paging.PageCompositionBase.OutputPageContent(Stopwatch stopwatchOutputContent, PageContent pageContent)
   at Telerik.Reporting.Paging.PageCompositionBase.<>c__DisplayClass124_0.<CreatePageContentOutputTask>b__0()

At the moment it's only possible to have your reports in old-fashioned projects.

It should be possible to add/design reports to SDK-style projects. That should work no matter what target framework is (.NET Core, .NET Standard or .NET Framework).

Is there a way to have the linear gauge display a value above the indicator?

The Web Report Designer does not entirely comply with CSP standards, necessitating the use of the 'unsafe-eval' directive in our CSP policies to enable its functionality.

This directive poses significant security risks and undermines the purpose of implementing CSP in the first place. Please remove this requirement.

I have been forcing my webservice data source into a workable solution for making GraphQL requests. Right now in order for us to use GraphQL, we have to build out the request manually with a string such as the following:

{"query: "query GetSomeResult($input: Int!) {result {id name}}",
"variables": "{"input": @parameter}"
}

While this is a normal way to hand craft a GraphQL request, the issue I have is that it shouldn't need to be that hard. Also I get no intellisense or suggestion in regards to the data returning. This means that when I try to bind data to a text box, I have to visually validate that the [=Fields....] is actually correct by looking at the GraphQL query and at the code base. I would love to see the ability to to just say have a set of standard api technologies we could implement from such as GraphQL queries, GRPc queries, or any other contract style request. I would expect that the data source logic would be smart enough to parse the query (at least for GQL) and be able to provide reccomendations.

Also a major issue we have had is in being able to pass that data source to subReports, or dealing with any nested objects such as a user.address.addressLine1 would not be able to be found if address is a nested values like the following

user: {
  address: {
    addressLine1
  }
}

If I use an HTML5-based Report Viewer with the default CONTINUOUS_SCROLL page mode and I start scrolling to the next page, the Get Document Page request is made multiple times for the same page.

If I move to the next page via the toolbar buttons or if I use the SINGLE_PAGE page mode, then problem is not reproduced.

Telerik.Reporting.nupkg has a dependency on ResXResourceReader.NetStandard.

Our 3rd party security audit has found the missing Digital Signature of this DLL. A digital signature would aid in verifying its authenticity and integrity.