Extend the schema by author metadata

[fzadrazil]

HSLayers used to send metadata about the author of the map and a thumbnail when saving compositions (had been used by Status Manager). Those data are not currently contained in the schema and Layman doesn't recieve it. User is taken from the credentials instead. Shoud we extend the map compositions schema by those metadata? @jirik @raitisbe @FilipLeitner @index-git More specifically, there used to be those fields in HSLayers:

• person, organization, position, address, city, state, postal code, country, phone, email, www

I suppose those metadata should be saved in Micka then. It uses those...

Consider also saving thumbnail from HSLayers to Layman instead of generating its own, but that is more Layman issue than schema.

[jirik]

@fzadrazil I would like to see such information (person, organization, position, address, city, state, postal code, country, phone, email, www) provided by OAuth2 provider (Liferay or Wagtail). Then Layman can automatically obtain it from that server and provide such information in map composition and/or send it to Micka. If such information will be in map composition, we need to extend the schema. Anyway, it's all for discussion.

[fzadrazil]

Yes, CMS should be the primary source of those data, but user should be able to change it when saving composition. Eg. the data can have different author and the user is only publishing it.

[fzadrazil]

I have consulted the right approach for this and the conclusions are:

• if there is a CMS and it is collecting detailed user info in his profile, this should be the primary source of those metadata and clients/Layman should derive it from there
• user should be able to change metadata about author and organization when publishing data to Layman (client prefills metadata from CMS, but allows user to change it)
• if user doesn't fill in those metadata at all, at least name should be stored with the data (I think that is the current state for Layman)
• all the metadata provided must be propagated from Layman to Micka

So I propose to

• keep the current user node and its meaning
• remove groups node (used only in Status Manager which is obsolete)
• add new contact node (metadata record item 10.1)
  • person
  • organization
  • address
  • city
  • postal code
  • country
  • phone
  • email
  • www
• add new organization node (metadata record item 9.1 - organization responsible for creating and maintaining the data)
  • name
  • person (responsible contact)
  • address
  • city
  • postal code
  • country
  • phone
  • email
  • www

In case only organization is filled in, it is automatically considered to be the contact too.