Analysis - org level resources

[nkylstad]

Description

An organization should have some sort of organization-level repository. Similar to the datamodels-repo, but for other static resources that an organization might want to re-use accross apps.

We need to determine how we will support this.

In scope

Use codelists as initial case, and focus on how we will support this case. Is FDK an option?

Out of scope

Solve this for all org level resources at once.

Additional information

Analysis

Some notes from our first meeting discussing this:

There are many resources that could be placed on the ORG level. F.ex:

• Codelists
• Data models (already exist on org level)
• Texts
• Templates? (I.e. ready-made files of code/config that can be used to create a new app)
• Widgets (am existing concept we need to re-introduce)

These are all libraries of shareable resources/configuration. Some libraries could be shared on org level, using an org repo.

In many cases there will be a need for some metadata about the different resources. Every repo in Studio has a .altinnstudio folder which currently only contains a settings.json file that is not really used. We could use this folder to add some library config/metadata. One example is tags, which would allow the app developer to tag a specific resource for easier filtering in the future. A tag could be added f.ex. to a codelist, or to a specific text.

Codelists in particular

One consideration that must be made is that a static codelist will generally have texts that come from a text resource file. Thus, we need to consider how we "ship" a shared code list. Some options:

• Use a different format in the "org" level repo for codelists. Where each code object in the list has the value, and label property is an object with all texts inline. Ex:

  [
  {
    "value": "example-value",
    "label": {
      "nb": "example-text-nb",
      "nn": "example-text-nn",
      "en": "example-text-en",
    }
  }
  ]

• Use the app format for codelists, but save each codelist in a folder with a file containing the code list (with label as a reference to a text key) and corresponding text resource files.

In both alternatives, Studio needs to do some mapping with texts to the apps text resources to ensure that all data is available in the correct places for the app when a codelist is imported to the app.

For the first alternative, one advantage could be that we can generate the text keys based on codelist id and value for each code. This makes it a lot less likely that we will have any conflict on text keys in the apps.

Is there any need for multiple resource repos? Datamodels is a separate repo - the argument for this was to allow for separate access control to the datamodels repo. Not sure this was a real need.

Conclusion

Status: Pending

General:

• There should be a "common" repo with shared resources available to all orgs. This common repo should be maintained by Altinn and not editable for ORG.
• Each org will have one "resources/library" repo to store their org level shared resources.

General for ORG resource repo:

• Each resource repo will contain folders on root that contain the different resource types
• We start with codelists
• Each resource should be self-contained. I.e. there should not be cross-references between resources. F.ex. a codelist should have its own text resources (inline or in a separate file)
• There should be a separate workspace/area for all library resources for an org. I.e. separate from app-development workspace. This is where people from the org can maintain their libraries.
  • Any editors that are available for app-level resources should be re-used

Specifically for codelists (UP FOR DISCUSSION):

• Each codelist will be stored as a file in the codelists folder in the app repo
• Each codelist will be self-contained, with texts inline.