Details
-
Improvement
-
Resolution: Won't Do
-
Neutral
-
None
-
None
-
-
Empty show more show less
-
Content Mngmt 14, Content Mngmt 15
-
8
Description
Copy from slack from mika. https://magnolia-cms.slack.com/archives/C0260UJMGPQ/p1632293443002100
Here is Mika' msg:
It's quite rare that we have other incompatibilities (or try to be compatible with multiple models at the same time) in other parts of the UI. An equivalent would be if developers change their dialogs or content-types, then when editors open this content, properties would be empty. Here we actually try to be nice and can read from both old/new content model, but only write according to one model. Changing to the new model affects project templates, so it needs to be a conscious decision (dev team would run the groovy task and update templates).Overall, we agree we try to bother editors the least possible. Let me try to summarize a proposal below (we tried that yesterday, and I might still miss some corner cases):
The ideal case for us is to ensure that all stories in a workspace are consistent (no new & old model in the same workspace at the same time). Let's see if we can get there.
# When we create a story from scratch, we could check any (or the first) existing story to infer which model we're on.
- If workspace contains no story => use the new model.
- If we don't want to infer the model every time, we can cache it in memory (managed-component), or even persist as a property under the workspace root node (modelVersion) when migration is complete and upon fresh installs, if that helps.
- Maybe a better way to check the workspace structure is to query for mgnl:block and differentiate if parent node is the story or an intermediate blocks node? (Could be that the first story we find doesn't have any block)
- Nice to have: when importing an old story into a workspace with new structure, we could apply the task upon import.
In other words my proposal is: only the pre-existing structure in JCR should drive which structure we save to => not the i18n property. This means: * If i18n is false and the workspace has the new structure, we save the indexed blocks under the blocks node (not the old way), transparently for editors.
- If i18n is true (on any field, title or blocks) and the workspace has the old structure, this is when we disable the language switcher, prompting users to contact their dev team to update. They should still be able to save the old way—I think you demo'd that it works. We can also set i18n to false programmatically if that helps (then most likely, the language chooser is no longer visible).
Checklists
Attachments
Issue Links
- is superseded by
-
CONTEDIT-456 Provide early awareness regarding story structure info from browser subapp
-
- Open
-