Management API : add a status section in device registration data

Proposal : add a status section in the device payload returned by the device registry. This section is optional and written only by the device registry implementation. It can not be updated by the user. Any data inserted in the status section by the user in a PUT request will be ignored.

This section would be a json object at the root level off the device registration data :

{
  "enabled": true,
  "defaults": { … },
  "via": [ … ],
  "viaGroups": [ … ],
  "memberOf": [ … ],
  "ext":  { … },
  "status" : {
          created: $date-time
          last-update: $date-time
          last-user: $username
   }
}

It allows to have a overview of recent management activity for the devices. Screenshot : https://marvelapp.com/5gbji22/screen/68233009

[kaniyan]

FMPOV this status should not be only added to the device registration data and it should also be available to other device registry resources such as tenant and credentials.

As the credentials are part of the device, that doesn’t make much sense me. For the tenant, I agree.

We are offering separate rest methods for the credentials. FMPOV we are already treating them as different resource. Also credentials can be updated irrespective of the devices. Hence I think its also good to have a status section for the credentials.

[fkaltner]

Hi @ctron & @jbtrystram !

I am a bit confused about this issue: the model classes in Hono, i.e. the model for a device (https://github.com/eclipse/hono/blob/master/services/device-registry-base/src/main/java/org/eclipse/hono/service/management/device/Device.java) already contain that status property. This is not yet implemented as far as I can see which is why I took a look at it, since it would be the right place for two system-internal flags required for #2053 which must not be editable by a user.

So it seems like this issue has been implemented to some extent. What was the reason to introduce that status property without a complete implementation?

Does it makes sense to complete the implementation based on what is currently on master FYPOV?