security.getUserName - odd behaviour

Any known issues with this function?

Works fine in Developer but Client (smart) has a different behaviour.

I store the User ID (integer) in my database. During record adds, in Developer, works fine (seeds date added, user added via data providers). I show the User Name (persisted and in the foundset) via getUserName() within a calculated field.

The Smart Client shows up differently during record adds. Modified field is populated and 0 (integer) stored to the db.

All is good in Developer.

so you arer saying that in the client the security.getUsername(id/uuid) isn’t giving you the same thing for the same value (id/uuid) as in the developer?

What if you log what you put in to the security.getUsername()?
So can you log the value? are they really exactly the same value in client and developer?

What version of servoy do you use?

Johan,

Stuff is going on in Developer as well so that might be easier to troubleshoot first. 3.5.1.

The database record contains this uuid related data:

user_added field = integer (value is 2)
user_modified field = integer (value is null)

The null is confirmed via “select * from dcm_notes where dcm_note_id = 4401 and user_modified is null” for the record in question … Postgres returns this one unique row. Sample row below is ID 4405.

My form is comprised of a parent “Notes” form and a notes detail form. 3 forms are involved (see the picture below for the 2 visible forms) .

  1. A host form which serves as a “container” - this is from the names database. Two related tab panels contain 2 visible forms: 2 and 3 (following).
  2. A parent Notes form - used to allow the user to enter a simple note (topic and the note itself)
  3. A detailed Notes form - a given Name will have more than one Note attached to it. The user clicks on the detail rows (table view of the Notes table) to select a given Note. Forms 2 and 3 invoke the same relation Names to Notes) … routine parent-child relationship (inner join).

If I add a new note, the following occurs:

  1. The user_added db row-column is properly seeded with my integer uid. (2 in this case). The user_modified row-column is properly left alone (ie - null);

  2. On the “parent” Note form (#2 form) I am using the native Servoy field and regular data provider - it properly shows the User Added field as a 2 and the User Modified as a null. See the picture below.

  3. Note how the calculated field in the table view form (form # 3) returns a value for the Last Modified field as my user name (I believe it should return a null to agree with the database at a null value). I had pressed the F6 key to save to the database at this point.

  4. The calculated field methodology (type TEXT) is: return security.getUserName(user_modified) or return security.getUserName(user_added);

Comments?

Thanks, Michael

Johan,

Here is a small sample solution (support system) to demonstrate this problem. Userid is mmooney, Password is mmooney (login needed to get a UID active). Sample solution also attached here.

Thanks

Michael

servoy_add_mod_issue.servoy (6.74 KB)

ahh ok now i get what you are seeing.

This is by default how it works, if you give nothing as an argument OR you give an argument but that argument is null to the getUserName() function then we return the logged in username.

I have to discuss if we can change that behavior so that only when you don’t give any arguments it will return the logged in user and if you put in null then nothing will be returned.

You can go around it by testing for null your self before calling getUserName

Johan,

I’m ok with a slight tweak to the doc’s so as to know to test for null to save some dev effort.

Best,

Michael

but from an api point of view this should also be fixed in servoy.
So in 3.5.2+ if you give an argument (null or something) then it will try to look it up. So null will now always return null.

No arguments will result in the current user data.

but from an api point of view this should also be fixed in servoy.
So in 3.5.2+ if you give an argument (null or something) then it will try to look it up. So null will now always return null.

No arguments will result in the current user data.

Johan,

Sounds good. Thanks,

Michael