Issue description
It should be easier to transfer functionality from one store to another. The unit of resuse should be a module, which bundles 0-n topic types and services, called parts. It can be imported into other stores. After the import all artefacts contained become local and can be modified. On update local changes might be overwritten. Ideally there is a warning.
If the module has no parts, ALL topic types, services, user groups, and user classes are inlcuded, thus the complete store without instance data can be packed and reused. Currently this needs to be achieved by copying the store and removing the instance data. Updates in the origin store cannot be replicated in the copy.
A module is defined by stating a name, optionally a description, possiblly a formal name and its parts, which can be topic types and services. The contents of a module is the set of pieces. A piece is a part or anything that a piece needs to function properly, e.g. occurrence types, constraints, item triggers, etc, but also files, source code files or Topincs files. When a module is released its contents is packed into an archive. This archive, a zip file, is called 'library'. The library contains all topic pieces (that are not system topics) in a single topic map. All files are placed at their respective location in the archive as well.
Developer comments
If you collect just instance topics in a module, you have the problem of missing the schema. This came up when a client needed to copy a couple of dozen files from one store to another, so rather stick to schematic topics since their schema, the meta schema, is present and identical in all stores.
There should be no strict hierachy. Any store can provide a module. Importing it should just cut down on the repetetive click work and coding, e.g. a PayPal transaction import.
The library of a module is an archive independent of the compression format. It holds the topic map at location "module.jtm". If the module contains services or triggers their source code is included in the library under the respective location. If the module contains files, the files are included in the library.
This is big enough for a new major version: Topincs 10.
Given a module M provided by store S1 and used in store S2. In S2 the admin freezes module topic T1. An update of M should not change T1 in S2. Only when the admin specifies that.
Instances of topic types of a module should only be contained if the respective flag is checked on the topic type. Currently this occurrence type is called *Instances included in application*. This should be renamed in *Instances included in module*.
When an admin creates a *release* for a module, the following things happen:
* The version, a positive integer, is increased by 1.
* A change history entry is created, consisting of date, version number, commit message and the library created. This could be a sheet adjunct, if the file would be rendered as very small.
If you import a module into its origin store, nothing should happen.
It might make sense, that user groups may also be module parts, since then you could transfer more of the user interface, main menu, topic menus and index configuration.
Use cases
A single topic type _Country_ with the instances and names in different languages plus the two letter and three letter iso code.
A single topic type _Day_ with the 7 instances.
An abstract topic type _Receipt_ with several sub classes, like _Invoice_ and _Credit note_ and some services.
|
Work sessions50
Start |
2024-06-17T09:00:00
|
End |
2024-06-17T13:56:43
|
Participant |
Robert Cerny
|
Start |
2024-06-17T15:30:11
|
End |
2024-06-17T17:01:35
|
Participant |
Robert Cerny
|
Start |
2024-06-17T20:05:19
|
End |
2024-06-17T20:35:56
|
Participant |
Robert Cerny
|
Start |
2024-06-18T08:40:52
|
End |
2024-06-18T12:13:18
|
Participant |
Robert Cerny
|
Start |
2024-06-18T12:41:38
|
End |
2024-06-18T13:20:00
|
Participant |
Robert Cerny
|
Start |
2024-06-18T17:24:12
|
End |
2024-06-18T18:33:18
|
Participant |
Robert Cerny
|
Start |
2024-06-18T19:04:19
|
End |
2024-06-18T20:04:26
|
Participant |
Robert Cerny
|
Start |
2024-06-18T22:01:50
|
End |
2024-06-18T23:02:00
|
Participant |
Robert Cerny
|
Start |
2024-06-19T11:14:31
|
End |
2024-06-19T13:27:29
|
Participant |
Robert Cerny
|
Start |
2024-06-19T15:00:00
|
End |
2024-06-19T17:54:41
|
Participant |
Robert Cerny
|
Start |
2024-06-19T08:00:00
|
End |
2024-06-19T21:29:04
|
Participant |
Robert Cerny
|
Start |
2024-06-20T13:00:00
|
End |
2024-06-20T13:45:10
|
Participant |
Robert Cerny
|
Start |
2024-06-21T20:00:00
|
End |
2024-06-21T21:01:03
|
Participant |
Robert Cerny
|
Start |
2024-06-22T11:00:00
|
End |
2024-06-22T13:04:25
|
Participant |
Robert Cerny
|
Start |
2024-06-22T14:19:23
|
End |
2024-06-22T17:20:20
|
Participant |
Robert Cerny
|
Start |
2024-06-22T19:50:33
|
End |
2024-06-22T21:25:17
|
Participant |
Robert Cerny
|
Start |
2024-06-23T09:00:00
|
End |
2024-06-23T10:37:19
|
Participant |
Robert Cerny
|
Start |
2024-06-23T11:59:54
|
End |
2024-06-23T14:00:00
|
Participant |
Robert Cerny
|
Start |
2024-06-23T19:00:00
|
End |
2024-06-23T20:05:27
|
Participant |
Robert Cerny
|
Start |
2024-06-24T15:00:00
|
End |
2024-06-24T16:59:38
|
Participant |
Robert Cerny
|
Start |
2024-06-25T20:00:35
|
End |
2024-06-25T21:35:04
|
Participant |
Robert Cerny
|
Start |
2024-06-26T06:03:41
|
End |
2024-06-26T09:00:46
|
Participant |
Robert Cerny
|
Start |
2024-06-28T12:56:19
|
End |
2024-06-28T14:30:28
|
Participant |
Robert Cerny
|
Start |
2024-06-28T17:25:09
|
End |
2024-06-28T17:50:34
|
Participant |
Robert Cerny
|
Start |
2024-06-28T19:25:19
|
End |
2024-06-28T20:52:48
|
Participant |
Robert Cerny
|
Start |
2024-06-28T21:27:44
|
End |
2024-06-28T22:49:30
|
Participant |
Robert Cerny
|
Start |
2024-06-29T14:32:25
|
End |
2024-06-29T16:55:26
|
Participant |
Robert Cerny
|
Start |
2024-06-29T19:00:00
|
End |
2024-06-29T19:38:23
|
Participant |
Robert Cerny
|
Start |
2024-06-30T08:26:48
|
End |
2024-06-30T10:01:26
|
Participant |
Robert Cerny
|
Start |
2024-06-30T12:03:52
|
End |
2024-06-30T14:59:08
|
Participant |
Robert Cerny
|
Start |
2024-07-01T12:27:48
|
End |
2024-07-01T13:21:13
|
Participant |
Robert Cerny
|
Start |
2024-07-01T20:11:35
|
End |
2024-07-01T21:00:00
|
Participant |
Robert Cerny
|
Start |
2024-07-02T07:40:00
|
End |
2024-07-02T11:29:48
|
Participant |
Robert Cerny
|
Start |
2024-07-02T13:20:23
|
End |
2024-07-02T14:08:03
|
Participant |
Robert Cerny
|
Start |
2024-07-17T08:31:00
|
End |
2024-07-17T11:01:04
|
Participant |
Robert Cerny
|
Start |
2024-07-26T13:30:00
|
End |
2024-07-26T16:31:48
|
Participant |
Robert Cerny
|
Start |
2024-08-07T08:48:51
|
End |
2024-08-07T10:36:33
|
Participant |
Robert Cerny
|
Start |
2024-08-07T15:20:13
|
End |
2024-08-07T17:07:27
|
Participant |
Robert Cerny
|
Start |
2024-08-08T09:27:09
|
End |
2024-08-08T14:25:31
|
Participant |
Robert Cerny
|
Start |
2024-08-09T11:21:04
|
End |
2024-08-09T12:52:16
|
Participant |
Robert Cerny
|
Start |
2024-08-14T18:47:52
|
End |
2024-08-14T19:09:23
|
Participant |
Robert Cerny
|
Start |
2024-08-15T08:21:59
|
End |
2024-08-15T15:13:32
|
Participant |
Robert Cerny
|
Start |
2024-08-15T15:50:46
|
End |
2024-08-15T17:05:41
|
Participant |
Robert Cerny
|
Start |
2024-08-15T18:15:00
|
End |
2024-08-15T19:15:35
|
Participant |
Robert Cerny
|
Start |
2024-08-15T21:20:00
|
End |
2024-08-15T23:05:04
|
Participant |
Robert Cerny
|
Start |
2024-08-16T07:33:39
|
End |
2024-08-16T10:27:10
|
Participant |
Robert Cerny
|
Start |
2024-08-17T08:27:59
|
End |
2024-08-17T10:00:05
|
Participant |
Robert Cerny
|
Start |
2024-08-17T17:00:00
|
End |
2024-08-18T00:05:42
|
Participant |
Robert Cerny
|
Start |
2024-08-18T08:00:00
|
End |
2024-08-18T10:41:54
|
Participant |
Robert Cerny
|
Start |
2024-08-18T16:00:00
|
End |
2024-08-18T17:19:41
|
Participant |
Robert Cerny
|
|