And now a solution for your problem. So as Johan says the changedBy and owner attributes are system attributes and not accessible for you in a Datagrid. So if you want to show 'created by' and 'changed by' information in a datagrid, the object in the datagrid should have 2 (1-0) relations to the system$user table. The user of relation instead of attributes are recommended because of the username can change during time.

For example: You hava a datagrid that shows the invoice object. If you want to now who have created the invoice and who have last changed the invoice you have to add two 1-0 relations from invoice to system$user table. One relation to store the 'created by' information (let we call it createdby relation), and one relation to store the 'changed by' information (let's say the changedby relation).

To set the relation you have to add 2 events on the (in this example) invoice object. One 'after-create' event that set the createdby relation and one 'after-commit' event that set the changedby relation.

So use relations, not attributes.

The "owner" and "changedBy" system associations cannot be shown directly in a data grid. However, as a workaround, you could create a calculated attribute (an attribute whose value is calculated by a microflow) of type String, and in the microflow retrieve the owner of the object and return his/her name. To retrieve the owner of an object, you need to select the 'From database' option in the retrieve action dialog, and use the following XPath constraint:

[id = $object/System.owner]

The answer benny suggests isn't a verry good one. If there are a few thousend objects it has to calculate (find the user) for each row. This takes a lot of time. Besides that, the user wont be able to sort on the column where the user name is shown.

The best option is the one suggested by Herbert, add 2 associations to the user object. This way the XAS does not have to execute a query for each seperate row.

What Jaap suggest is a good solution but much more complex.

You really should try to avoid two things,
1: Calculated attributes, these attributes are really heavy operations and take a lot of time(compared to normal database actions) and they are not really usable since you can't sort nor search on them. 2: Copy values from referenced objects. If you copy the username or fullname from the employee, which had created the object, it should be faster since the XAS doesn't have to retrieve the user. BUT what it the username or completename changes. Than all copied values must be updated to keep al data consistent.

Therefor the best solution is the one that herbert suggested.

You could create a micro flow that is executed once that copies all existing relations to the new relations. I use this kind of 'manually-convert' microflows a lot to convert the data to the new database structure.

While the created by (Owner) and changed by fields are internal system attributes it is not possible to show them in a DataGrid.

Furthermore, How would you deal with existing data in the database?

A(n) (dirty?) alternative is to create an object that inherits from System.User and set two relations to the object you wish to monitor (object X). One that gets filled whenever an object is committed for the first time (creation, you check this in a split by using the isNew function [microflow]) and one that gets updated on ever subsequent commit (last changed). This way you can retrieve both usernames through the referenced object in a datagrid of object X.

Default the XAS don't save that information. So if you want to show 'created by' and 'changed by' information in a datagrid, the object in the datagrid should have 2 (1-0) relations to the system$user table.

For example: You hava a datagrid that shows the invoice object. If you want to now who have created the invoice and who have last changed the invoice you have to add two 1-0 relations from invoice to system$user table. One relation to store the 'created by' information (let we call it createdby relation), and one relation to store the 'changed by' information (let's say the changedby relation).

To set the relation you have to add 2 events on the (in this example) invoice object. One 'after-create' event that set the createdby relation and one 'after-commit' event that set the changedby relation.

I think it is more simple (OK and a little bit dirty) to add 2 attributes in the object: ChangedDate and CreatebyUser. Then add a "after create event" which sets this attribute with the username of the current user and a "before commit event" which sets the current date time.

Browse the fields from the object, you'll see an expandable 'owner' and 'changedBy' field. Open these and they'll give you access to a 'User' object, you can select what you'd like to show from these users (for example: Name)