Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

Since version 24.2 of the AppWorks platform, we have a new functionality available with the solid feature name “Ability to mark a record as read or unread”. Interesting functionality, but after exploration with a colleague and asking questions about a specific property ReadBy on the ‘Tracking’ BB, I can conclude the update post on 24.2 isn’t covering the full functionality…The question was: When does this ReadBy property get a value applied? The answer is more obvious than we initially thought…

Let get right into it…

Time to rediscover the ‘Tracking’ building block on my already available ‘Case’ entity (with just one case_name property). As you see in the 24.2 update post there is a checkmark ‘Enable read or unread status’ on the ‘Tracking’ BB and there is a checkmark on the ‘List’ BB with the name ‘Highlight unread items’.

I mark them both (the other one is not in the screenshot) and after publication we can use the functionality directly in runtime:

…

Right, so where did we miss something as the introduction tells us? Well, I (and my colleague) exposed the ‘Web service’ BB on our entity with the ‘Read’ operation exposed (incl. the creation of a related ‘Application Server’ service container the manage the request…comment me if you don’t have clue!), but we didn’t get any results on the ‘ReadBy’ tracking details!?

Our request:

1
2
3
4
5
6
7
8
9

<SOAP:Envelope>
  <SOAP:Body>
    <Readcase>
      <ns0:case-id>
        <ns0:ItemId>080027f2140da1ef89c3c3fb8f7013dc.1</ns0:ItemId>
      </ns0:case-id>
    </Readcase>
  </SOAP:Body>
</SOAP:Envelope>

With the response:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

<data>
  <wstxns1:ReadcaseResponse>
    <wstxns2:case>
      <case-id>
        <Id>1</Id>
        <ItemId>080027f2140da1ef89c3c3fb8f7013dc.1</ItemId>
      </case-id>
      <case_name>test001</case_name>
      <wstxns3:Title>
        <Value>case-1</Value>
      </wstxns3:Title>
      <wstxns4:Tracking>
        <LastModifiedDate>2024-06-10T10:04:18Z</LastModifiedDate>
        <CreatedDate>2024-06-10T09:57:16Z</CreatedDate>
        <CreatedBy>
          <wstxns5:Identity-id>
            <Id>3</Id>
            <ItemId>F8B156E1037111E6E9CB0FBF3334FBBF.3</ItemId>
          </wstxns5:Identity-id>
        </CreatedBy>
        <LastModifiedBy>
          <wstxns6:Identity-id>
            <Id>3</Id>
            <ItemId>F8B156E1037111E6E9CB0FBF3334FBBF.3</ItemId>
          </wstxns6:Identity-id>
        </LastModifiedBy>
      </wstxns4:Tracking>
    </wstxns2:case>
  </wstxns1:ReadcaseResponse>
</data>

Did we do something wrong here? Did we set it as “Read” by the user? Did we miss something like the exposing of the access events via the ‘History’ BB? Well, NOPE; It has nothing to do with the ‘History’ BB, and we did all the “set as read” things! So, what do we do wrong here?

Our next move is to update the ‘Create’ screen of the ‘Case’ entity and add the ‘Read By’ tracking grid…WHAT? Yes, have a look:

I changed it to a grid type, added 3 related properties, and deselected all the available actions (like ‘Open’, ‘Clear’, etc…)

After publication, we have a vision:

So, it does work…Only not via the ‘Readcase’ webservice; #SUPPORT? I also did a double-check on the typed ReST layer of the platform (the one via ‘/app/admin’), but that response (in JSON) is also missing the ‘ReadBy’ information!?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

{
  "Identity": {
    "Id": "1",
    "ItemStatus": 1
  },
  "Properties": {
    "case_name": "test001"
  },
  "Title": {
    "Title": "case-1"
  },
  "Tracking": {
    "LastModifiedDate": "2024-06-10T10:16:18Z",
    "CreatedDate": "2024-06-10T09:57:16Z"
  },
  "_links": {
    "self": {
      "href": "/aw_tipsprj_generic/entities/case/items/1"
    },
    "curies": [
      {
        "name": "OpenTextEntityIdentityComponents-relationship",
        "href": "http://node1:8080/home/appworks_tips/app/entityservice/OpenTextEntityIdentityComponents"
      }
    ],
    "OpenTextEntityIdentityComponents-relationship:CreatedBy": {
      "href": "/OpenTextEntityIdentityComponents/entities/User/items/3"
    },
    "OpenTextEntityIdentityComponents-relationship:LastModifiedBy": {
      "href": "/OpenTextEntityIdentityComponents/entities/User/items/3"
    }
  }
}

Again #SUPPORT; That’s not a very consistent implementation!? But we can always improve!

…

I’m curious and wondered where this user “readby” information gets a save in the database? Well, that’s a simple answer; I took a quick look in my PostgreSQL database via HeidiSQL, and this is the outcome (where user_id 3 is my awdev account and 5 is my awadmin account!):

So, that’s a simple relation table between case_id and user_id!

FYI: This table is directly available once you apply the ‘Tracking’ BB (even without selecting the required checkmarks for readability!)

A nice “DONE”, we found the answer to our own question. Sometimes things are easy found and easy shared via a quick post. Keep asking your questions, keep commenting on the posts as it starts the creative thinking process of creating new posts, shares, and any other snackable content on the interwebs. Have a good weekend and I CU next week.

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?