[MGNLCT-81] Content Types evolution Created: 03/Dec/18 Updated: 15/Dec/22 Resolved: 15/Dec/22 |
|
| Status: | Closed |
| Project: | Content Types |
| Component/s: | None |
| Affects Version/s: | 1.0 |
| Fix Version/s: | None |
| Type: | Epic | Priority: | Major |
| Reporter: | Mikaël Geljić | Assignee: | Unassigned |
| Resolution: | Obsolete | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Template: |
|
||||||||
| Epic Name: | Content Types evolution | ||||||||
| Acceptance criteria: |
Empty
|
||||||||
| Description |
|
Once a Content Type is modeled, it should be clear how to modify it over time, while maintaining integrity of existing content. Keep moving away from dialogs/apps as the implicit model for customer data. Offer tooling for it to evolve over time, with assisted bulk-changes and without Java version handlers. Example story: As a project developer, I can declare changes to my content types models, so that pre-existing content can be migrated or "adapted", e.g. rename properties, add new properties with a default value, etc. TBC |