This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal


Jun 16, 2014, 4:22 PM
31 Posts

@DeleteField not deleteing the field in question

  • Category: Application Development
  • Platform: All Platforms
  • Release: 9.0
  • Role: Developer
  • Tags: @Formula
  • Replies: 7

I have a computed readers field on a form called WFSDraftReaders and the first line of the @Formula is:

@If(WFSStatus != "Draft";@Return(@SetField(@ThisName;@DeleteField));"");

when I run a compute with form on a selected document where WFSStatus is not equal to "Draft" I would expect this line to delete the field WFSDraftReaders, Instead it falls through and computes the rest of the code.

My @Formula is a little rusty but this sure looks like it should work.

Any ideas greatfuly accepted.

Jun 16, 2014, 5:03 PM
90 Posts
I have not seen it done that way
From what I have seen before @DeleteField is assigned to the field with the Field keyword.

Field DeleteMe := @DeleteField;

Not sure if using @setfield works or not.

Howard
Jun 16, 2014, 5:41 PM
31 Posts
SetField(FieldName;Value)

From the help for @Setfield I found this:

 

This code, when used in a view action button, deletes fields x_1 through x_20 in the selected document.

@For(i := 1; i <= 20; i := i + 1;
@SetField("x_" + @Text(i);@DeleteField));

I'm not iterating through a bunch of fields but @SetField(@ThisName;@DeleteField) would appear to be allowable code. I guess the question might be if it can be done as an @Return(@SetField(@ThisName;@DeleteField))

Also did this

@If(WFSStatus != "Draft";@Do(@SetField(WFSDraftReaders;@DeleteField);@Return(""));"");

and this

@If(WFSStatus != "Draft";@Do(FIELD WFSDraftReaders := @DeleteField ;@Return(""));"");

I wouldn't think this would be this hard!

Jun 17, 2014, 9:45 AM
107 Posts
What happens if...
...you modify the formula as follows

@If(WFSStatus != "Draft";@Return(@Unavailable);"");

This is how I usually put it in similar circumstances, and in my experience it seems to work reliably. The point here is to have the formula directly return the new field value, instead of using @SetField. Note that it should be o.k. to replace @Unavailable with @DeleteField.

Curious to know if that works for you.

[EDIT] I'm assuming that we are talking about the value formula of your computed Readers field, not about a formula that is executed somewhere outside the field.

Jun 18, 2014, 2:22 PM
10 Posts
Cannot work --> Field exists in Form --> cannot be deleted
You have a 'real' computed field: This means everytime you refresh the form the field will reappear. Also an empty Readersfield might be dangerous Instead of
        @If(WFSStatus != "Draft";@Return(@SetField(@ThisName;@DeleteField));"");
use
        @If(WFSStatus="Draft";@Username;"*");
Additionally it makes no sense to have an empty readers field --> if draft, then only this user can see it otherwhise everybody (=*). I would strongly recommend to make the field multivalue and add a role like Admin or ReadAll. This would be the right formula:
        @If(WFSStatus="Draft" ; "[Admin]":@Username ; "*");
Jun 19, 2014, 7:04 AM
10 Posts
computed field should be enough
a computed multivalue authors field with a formula like that should do it:
@If(WFSStatus="Draft" ; "[Admin]":@Username ; "*");
Jun 20, 2014, 3:50 PM
107 Posts
Partially disagree
If the Value formula of a computed field returns @Unavailable (or @DeleteField, for that matter), then the corresponding item will in fact not  be present on the on-disk document after you save the document. The same is true after running ComputeWithForm against the document -- as described in the OP's use case. So, a Readers field formula that returns @Unavailable will not leave the document unreadable.

Apart from that I totally agree with you that it is good practice to always have Readers fields contain at least a role that is reserved for admins (plus optionally one reserved for servers).
Jun 18, 2014, 7:14 PM
31 Posts
Daniel

I don't know where my head was, obviously if it exists on the form it will always appear..

I'm going to create a single Reader field and Authors field then have the something in the querySave or ??? that populates the Reader/author fields. I always have and Admin role that can read/edit all documents in the database, otherwise disaster.

 

Thanks


This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal