Hi Binod,

Correct me if you think I'm wrong but this seems more like a process issue.  What is separating the DW/BI team from the Application team?  Does the Application team know what they are impacting when they change the data model?

Internally we have a similar issue to yours when it comes to making schema changes (such as exposing a column in a Rule- class).  A basic example for us if we want to add a property to a class and have it exposed in the database, we create a user story for another team who will then work with us to make sure the correct scripts are generated and guide us on getting it applied to our dev system.  It's not exactly the same case you're encountering but some kind of process like this could help with tracking these types of changes that impact others.

Mike

This is something we've been investigating for awhile and still working out all the requirements so we can meet them when we do have a solution.  I don't know when it would be introduced though since priorities are always changing.  I have forwarded along your feedback though to try to further drive it along.

We have a solution that works with FusionCharts (which is what we're using for Report Definitions) but for a catch-all, you could take a look at http://stackoverflow.com/questions/14552112/html-to-pdf-with-node-js but it wouldn't be an easy implementation.

I'm not seeing this same issue for list views/summary views (I checked on 7.1.9).  You might want to open up a Support Request so someone can investigate your use case more deeply though.

Have you tried using the Chart Control?  With it, you could source the grid and the chart by the same pagelist so they only execute the report once.  

Having the data source being a table in the dom is interesting.  I'm not sure it's something we'll implement though since it has limited use.

Hi, John!

On the client, be sure to use the right controls for your inputs.  Pega's out-of-the-box controls offer configurable client side validation so that the user can be prevented from entering or at least notified of invalid input before the data reaches the server.

However, not all validation should be done on the client.  While client-side validation will improve user experience, you should still re-validate the input on the server both as a security precaution and to avoid processing the invalid input and introducing a performance issue.  For example, a malicious user could attempt to submit data for a form outside of the browser.  If the form data is not appropriately validated on the server or processing is not halted after validation failure, the server could execute costly processes based on the bad input.

On the server, we recommend using a Validate rule to validate the page holding the form information, and existing Edit Validate rules to validate the format of those values where applicable.  If the form is not contained by a flow action, you may need to invoke your Validate rule manually in an Activity using the Obj-Validate Activity method.

Hi Rajeev,

It is possible and I see your open Support Request for the issue.  I took a look and believe I found the issue.  The code was forked when the Customized Property list was added and so the original hotfix delivered to you only fixed the case when the Association class property's weren't custom so it only caught half the use cases.  I've talked to the Engineer currently working on your issue (he sits 5 feet from me) and he will be working on getting it packaged up once it passes through our testing/approval process.

Assuming you're talking about the Data Explorer, we show different versions for a developer and manager because at the time the thought process was some developers did use the Report Editor to create reports and that they would want the full list of properties.  If we were to go back, I'm not so sure we would make the same decision. 

For 7.2.2 you can overwrite this behavior by saving a copy of pyReport_ShowCustomProperties and have it return true always.

When a grid is sourced by a data page and it doesn't know what the data page is sourced by.  So when the data page executes the report definition, it ends up executing it with paging disabled.  Is this causing you any issues?

Hi Vimal,

Welcome to the Product Support Community and thank you for posting your query! This discussion is on Reporting and I see that your question is on installation of Pega Marketing. In order to get your question more visibility, we have created a new post for you - Is it mandatory to install VM for installing Pega Marketing?

Please update the new post to continue the discussion!

Thank you,

Hi Nishant,

We don't really know enough to give you a concrete answer on what you can do to log successful logins without enabling the other options.  I saw your other post in Product Support tagged with Security and I think that will be the best place to get some help at the moment.

There isn't a property that has that information in the Index OOTB.  You will need to add a property to the Index to store that information and add it as a filter to your report.

Optimizing the properties would probably be one of the best ways to improve performance.  Are you filtering on any unoptimized properties?  Optimizing those would be the higher priority if you're worried about exposing all of them.  You can also create a database index for any properties/columns you're filtering on to improve the performance.