Overriding a calculated field : Portal

A

Aditya DUBEY

started a topic about 1 year ago

Table Details :

One table/entity with two columns 'EndDate' and 'Status'.

Expected Scenario:

When a user, with appropriate privileges, updates the 'EndDate' field then 'Status' field should get updated automatically and its previous value should be overriden.

Configuration:

Added a semql enricher with case logic to calculate the value of 'Status' field.

Used this enricher in the form step (on data change).

A survivorship rule for the field 'Status' has been created where override strategy is set to "Override until next user Changes"

Current Behavior:

User updates 'EndDate' field from UI.

The 'Status' field is getting re-calculated in the UI(new value being shown).

However, once the user submits the changes, only 'EndDate' is getting persisted in GD table and 'Status' is not.

On Analysis it was found that override flag for 'Status' field is not being re-set in SF_* table.

How can we update the 'Status' based on direct authoring of 'EndDate'?

Please suggest.

Best Answer

A

Alexia SIMOND said 11 months ago

Hello Aditya,

I think that an answer was provided over ticket, but I'm putting back here the answer if it can help someone else.

Putting both involved attributes (EndDate and Status) in the same survivorship rule should help propagate the Status update when the EndDate is edited.

Because attributes under the same survivorship rule are considered as a group. The group is considered as one and so if one of those attributes is updated then the group's value is considered as changed. Therefore the override is removed (according to the override policy), allowing the update to propagate to GD.

A

Alexia SIMOND

said 11 months ago

Answer

Hello Aditya,

I think that an answer was provided over ticket, but I'm putting back here the answer if it can help someone else.

Putting both involved attributes (EndDate and Status) in the same survivorship rule should help propagate the Status update when the EndDate is edited.

Because attributes under the same survivorship rule are considered as a group. The group is considered as one and so if one of those attributes is updated then the group's value is considered as changed. Therefore the override is removed (according to the override policy), allowing the update to propagate to GD.

N

Naveena MANDAVA

said about 24 hours ago

HI Alexia,

We have similar behavior with isInvestment and InvestmentCode fields.. Both are part of different survivorship rukes because we have skip nulls on InvestmentCode field Survivorship Rule.. In UI User changes IsInvestment field from No to Yes, the InvestmentCode is automatically calculated..

Please let me know how this can be handled..