ShortCut Depth Limits?

PointsWell

I've got a two deep selection going on and it is giving me shortcut errors.

I have three objects - Category, MilestoneType and ContractMilestone
Category-<Milestone Type-<Contract Milestone
Where 1-<m

On the ContractMilestone I have a shortcut to the Milestone Type to pull in MIlestoneType.Name
I have a second shortcut that is supposed to pull in the Category Name on the Contract Milestone via:
ContractMilestone.ps_MilestoneType.ob_Category.Name

When I try to use it though it is only returning
ContractMilestone.ps_MilestoneType.Name instead.

When I look on the database table it is all correctly referenced. If I try to use the Category Name as a Grouping in a query it displays:

MilestoneType:nnnnn@Attribute

where nnnnn=the ID of the MilestoneType record and Attribute is the value of the Name shortcut.

Is there a limit to how far up the chain a shortcut can go?

customaware

There is no limit that I am aware of Sean.

However, from your explanation below... that you are receiving ContractMilestone.ps_MilestoneType.Name rather than ContractMilestone.ps_MilestoneType.ob_Category.Name would have me looking
at the Reference between MilestoneType and Category. Are you sure Multiple is NOT checked. It looks like the issue is with that link.

PointsWell

Hi Mark

I've checked the multiples are correct and I've run the check integrity and have tested with new data and I'm still getting the same problem.

I'm stumped.

customaware

Send me the bsv Sean if you like and I'll have a look

PointsWell

I'll Skype you this evening, it's too involved to replicate the issue with just the BSV (deep into the business process)

PointsWell

I have worked out what was going wrong here.

I have a rule that essentially does:

IF BO.ps_Attribute1 WAS CHANGED TO 'A Value' THEN
BO.ps_Attribute2 = BO.Attribute1.ob_RefToAnotherBO
READ PROTECT BO.Attribute2 FROM ALL EXCEPT SYSTEM

From painful experience READ PROTECT is obnoxious when used with any other action.

In this case it was setting the READ PROTECT and then trying to update the field. It was then reporting in the logs that the field was protected and it was reverting to previous value.

JonP

I wonder if that's for transaction reasons so that all business logic is performed before anything is actually saved, making rollback just a matter of garbage collection from memory.

PointsWell

Couldn’t comment on the why.

It’s just confusing when the actions were in the same rule but being executed in an order that isn’t sequential.

JonP

It's possible that the actions are sequential if they are being conducted purely in memory first, then committed to storage once they are confirmed not to have errors.