WebHare community

Tollium unit test crashes on testusers

In my (Tollium) unit test I’m creating (among others) a WRD_PERSON. However, when I set testusers, it crashes out:

>  ** UNEXPECTED EXCEPTION: The field 'WHUSER_UNIT' is required
>
> /Users/wouter/projects/webhare/whtree/modules/wrd/lib/internal/setentity.whlib:44:13: Called from ONTHROWENTITYERROR
> /Users/wouter/projects/webhare/whtree/modules/wrd/lib/internal/wrdtype.whlib:2218:32: Called from WRDTYPEBASE#VALIDATESETTINGS
> /Users/wouter/projects/webhare/whtree/modules/wrd/lib/internal/wrdtype.whlib:2839:18: Called from WRDTYPEBASE#__INTERNAL_UPDENTITY
> /Users/wouter/projects/webhare/whtree/modules/wrd/lib/internal/wrdtype.whlib:2350:25: Called from WRDTYPEBASE#__DOCREATEENTITY
> /Users/wouter/projects/webhare/whtree/modules/wrd/lib/internal/wrdtype.whlib:3523:18: Called from WRDTYPE2017#CREATEENTITY
> /Users/wouter/projects/webhare/whtree/whdata/installedmodules/wvuaw/lib/api.whlib:221:49: Called from WVUAWAPI#CREATESELLINGPROCESS
> /Users/wouter/projects/webhare/whtree/whdata/installedmodules/wvuaw/tests/lib/shared.whlib:98:22: Called from TESTCREATESP
> /Users/wouter/projects/webhare/whtree/whdata/installedmodules/wvuaw/tests/backend.whscr:25:19: Called from STARTAPPLICATION
> /Users/wouter/projects/webhare/whtree/modules/system/lib/testframework.whlib:1267:13: Called from TESTFRAMEWORK#RUNSERIE

(Stripped) test code:

MACRO Setup()
{
  RECORD shared := GetTestData(testfw);
  api := shared.api;
}

ASYNC MACRO StartApplication()
{
  testfw->BeginWork();
  INTEGER spid := TestCreateSP(); // creates a WRD_PERSON
  testfw->CommitWork();
}

RunTestFramework([ PTR Setup
                 , PTR StartApplication
                 ]
                 //, [ testusers := [[ login := "sysop", grantrights := ["system:sysop"] ]
                 //                 ]
                 //  ]
                );

This doesn’t crash, but once I remove the comments, it does.

Any idea how to prevent this?

testframework:

///The ID for a testunit created if wrdauth mode is enabled. Use this for WHUSER_UNIT
PUBLIC PROPERTY testunit(__betatestunit,-);

And you may want to read the 4.27 changelog

Ah, yes, didn’t remember reading that.

whuser_unit := testfw->testunit in the CreateEntity call for WRD_PERSON did the trick.

Related question: now that the test succeeds, it’s giving me a URL:

http://localhost:8000/testportal/?overridetoken=2v4JjbqUAHXw4sVUu7qOpw&app=wvuaw%3Amain&openas=sysop%40beta.webhare.net

However, this shows a messagebox:

“You do not have enough rights to start this application.”

And although the start menu shows all applications (implying sysop rights), all applications show this messagebox when opening.

PUBLIC OBJECTTYPE RightsProblem EXTEND TolliumScreenBase
< PUBLIC MACRO Init(RECORD data)
  {
    IF (this->tolliumcontroller->debugging)
      this->RunMessageBox(".notenoughrights_spec", data.needed_rights);
    ELSE
      this->RunMessageBox(".notenoughrights");
    this->tolliumresult := "cancel";
  }
>;

try enabling tollium debugging

Not really sure what this would solve. data.needed_rights is my custom (basic) right for the application, but where would I grant this right?

In other words, where does http://localhost:8000/testportal/?overridetoken=2v4JjbqUAHXw4sVUu7qOpw&app=wvuaw%3Amain&openas=sysop%40beta.webhare.net gets the user from? Since like I said, the start menu is full of sysop-only applications so I would guess it’s a sysop-user?

Not really sure what this would solve. data.needed_rights is my custom (basic) right for the application, but where would I grant this right?

at least confirm it’s looking for the proper right

In other words, where does http://localhost:8000/testportal/?overridetoken=2v4JjbqUAHXw4sVUu7qOpw&app=wvuaw%3Amain&openas=sysop%40beta.webhare.net gets the user from? Since like I said, the start menu is full of sysop-only applications so I would guess it’s a sysop-user?

Is the sysop user still commented out the last test run you tried this url ? i see the same if I use an overridetoken with a nonexisting user as openas=. Looks like an incorrect openas= fails at some points and falls back to the overridetoken user at other points

or, it’s much simpler than that: the applicationportal webpage and its services (which implement the app menu) ignore openas= when using the overridetoken. application starts themselves don’t

Hmm, now I got everything to work I can’t reproduce it anymore… guess it had something to do with some error in the application.

I’ll get back to this post if I can trigger it again.