nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Refresh derived properties 2

medini_1060108009

Hi,

Following on from the previous post (https://medini.freshdesk.com/support/discussions/topics/1000106585#reply-to-post) I would like to confirm whether it is possible to refresh derived properties via scripting. This is because there are a few derived values that I'd like to ensure that they have been refreshed before generating the report, as it is easy for users to forget to refresh those values.

Thanks!

Maisy

Find more posts tagged with

medini

medini legacy

Accepted answers

All comments

medini_1024169437

Hi Maisy,

are you talking about custom (your own) derived properties or internal like failure rate or probability?

Custom properties should be AFAIK refreshed before reporting anyway.

Jan

medini_1060067341

Hi Jan,

I have been facing the same issue. Custom derived properties are printed out as "undefined" unless I go into the collection to which I am getting the property from, and refreshing it manually with F5.

For example, if I have a custom derived property (such as a Threat object), referenced by a Vulnerability, then the Treat column will be printed out as "undefined" for all Vulnerabilities unless I go into my Vulnerabilities Collection and refresh it manually.

Any ideas of what the issue could be here? I am using OCL datasets by the way.

Thanks,

Lucas

medini_1024169437

Hi Lucas,

this is ... unusual. strange. Do you have a minimal project or profile script to reproduce? The mentioned extension to Thread and maybe the report piece?

IMHO it doe snot matter whether the property is scripted in OLC or JS, should be the same.

Are you using other scripted properties *inside* scripted properties? So bascically chaining derived properties?

Happy Scripting

Jan

medini_1060067341

Hi Jan,

I had some time to play around and was finally able to reproduce the issue in the project attached.

The issue only happens (with the user_threat custom derived property in the Attack metaclass) when I call the script from an external JS file using:

load(custom_script.js);
returnAttacks(self);

If I do whatever is into custom_script.js inside the derived property script editor itself, e.g., self.mediniGetOpposites("user_attack"), then reporting works fine.

Have you ever come across this issue before?

medini_1024169437

Thanks Lucas for this finding, I did not hear that problem before,

So what you say is that, if the script of a derived property is put into a separate file and loaded via load() function, it is not evaluated correctly before reporting unless the user enforces it by e.g. opening a table editor?

Jan

medini_1060067341

Hi Jan.

Exactly. Just to add, opening the table editor is not enough. I have to refresh it via F5 before generating the report otherwise the derived properties are printed out as "undefined" in the report.

Thanks!

Lucas

medini_1024169437

Strange. Is there anything special in that library? Are you using any pragma to get them working?

Or is it the contrary: just moving any code into a file and execute it via laod() eveals the issue?

Jan

medini_1060067341

Hi Jan.

Not at all AFAIK.

I attached a version of the project I shared yesterday, where reporting is working fine.

In order to fix the issue, all I did was, instead of calling load() like in the example I shared yesterday, move the code from the external JS file, into the derived property itself.

Thanks,

Lucas

medini_1024169437

Hi Lucas,

we finally were able to reproduce this issue thanks to your samples. It seems that this is indeed a defect.

When loading a script file the code needs to resolve it compared to the scripted object (the Attack in your case) but somehow strangely the object passed into the engine is not of the expected type, I assume its a BIRT JS issues.

Anyhow, a fix is feaisble and we are going to apply one for next release.

Regards

Jan

medini_1040289819

Hi Lucas,

a fix for this issue is now available in the released 2022 R1.1 SP.

Regards

Olaf.