You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Current »

To be able to save user-specific data, such as settings for the NetworkMap (customization options) or the dashboard, the data-provider (Data-Provider) should be extended.


Goal:

  • Provide a function to GET settings data by username
  • Provide a function to POST / (PUT / PATCH?) settings data for a specific user
  • Provide a function to DELETE settings data of a specific user
  • no clear payload data structure definition to keep it as flexible as possible => what is written, can be requested

Characteristics:

  • user gets identified by token (basicAuth or JWT)
  • Additional API in bundle data-provider
  • Create a settings entry in the database if none exists
  • Delivers back all settings of a user
  • Updates the settings of a user 
  • Can delete (reset) settings of a user
  • model is using camelCase for properties
  • subItems have to be also JSONObjects, not Arrays or simple types.

 Open Questions:

  • when should the initial settings entry of a user be created? When settings are updated / saved for the first time?
    • UI is responsible for data-structure → so initial data is writting by UI
    • empty data on server will return empty json object: "{}"
  • Use PUT or PATCH for updating entries? (settings may grow over time, eg. dashboard, networkmap, ...) Should the entire settings object be send or only a partial one?
    • PUT!
    • partial will be implemented
  • If we use PUT, do we need POST?
    • no
  • Should settings be queryable by section? ( eg. dashboard, networkmap, ...)
    • filter only for root element key


Default values for deployment

It is now possible to deploy a default userdata file ($ODL_HOME/etc/userdata-defaults.json) into the SDNC container which delivers a merge of its values and the DB entry of the userdata.

Extension of data-provider

OperationExpected result
GET /userdataGets all the settings of a specified user
GET /userdata/{key}Gets the subsettings of a spefic user for rootElem[key]
PUT /userdataCreates/Updates settings entry of a user
PUT /userdata/{key}Creates/Updates settings entry of a user for rootElem[key]
DELETE /userdataDeletes settings entry of a user
DELETE /userdata/{key}Deletes settings entry of a user for rootElem[key]

In fact that jetty servlets can also handle camelCase URLs it is easily possible to filter for the correct property.

Examples

Read settings data of a user

GET /userdata

{
    "networkMap":{
        "startupPosition": {"lat": 52.5095, "lon":13.3290, "zoom": 10},
        "tileOpacity": 90,
        "styling":{
            "theme": "light"
        }
    },
	"networkMapThemes":{
		"themes": [
    		{"key": "light", "site": "#11b4da", "selectedSite": "#116bda", "fiberLink": "#1154d9", "microwaveLink": "#039903"}
		]
	},
    "dashboard":{
        "color":"#F00"
    }
}


GET /userdata/networkMap

{
    "startupPosition": {"lat": 52.5095, "lon":13.3290, "zoom": 10},
    "tileOpacity": 90,
    "styling":{
        "theme": "light"
    }
}

Write settings data of a user

PUT /userdata

{
    "networkMap":{
        "startupPosition": {"lat": 52.5095, "lon":13.3290, "zoom": 10},
        "tileOpacity": 90,
        "styling":{
            "theme": "light"
        }
    },
    "dashboard":{
        "color":"#F00"
    }
}

Write partial settings data of a user

PUT /userdata/networkMap

{
    "startupPosition": {"lat": 52.5095, "lon":13.3290, "zoom": 10},
    "tileOpacity": 90,
    "styling":{
        "theme": "light"
    }
}


  • No labels