[MGNLCI-25] Automatic bootstrapping and configurable import-task strategy Created: 29/Jun/20 Updated: 08/Sep/20 Resolved: 24/Jul/20 |
|
| Status: | Closed |
| Project: | Content Importer |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.0.4 |
| Type: | Bug | Priority: | Major |
| Reporter: | Christopher Zimmermann | Assignee: | Robert Šiška |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||
| Issue Links: |
|
||||||||||||
| Template: |
|
||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||
| Release notes required: |
Yes
|
||||||||||||
| Documentation update required: |
Yes
|
||||||||||||
| Date of First Response: | |||||||||||||
| Sprint: | HL & LD 6, HL & LD 7, HL & LD 8 | ||||||||||||
| Story Points: | 8 | ||||||||||||
| Description |
|
Two possible approaches to address this (maybe there are others): 1. The new 'magnolia.content.boostrap.initial=true' property should cause detected files to be imported only when the Magnolia instance is installed, not at every startup. This would be most consistant to the known behaviour of the bootstrap files that modules supply or that are placed in 'WEB-INF/boostraps' directory. 2. The system could keep track of which files have been imported, so that at every startup it would only import files that it had not already imported. This is related to what has been reported in |
| Comments |
| Comment by Robert Šiška [ 08/Jul/20 ] |
|
Current progress: Changes implemented in Bootstrap is not triggered when the module was only updated. To rebootstrap again, one can set /modules/content-importer/config/initialBootstrap property to true. |
| Comment by Christopher Zimmermann [ 09/Jul/20 ] |
|
Sounds good. |
| Comment by Christopher Zimmermann [ 09/Jul/20 ] |
|
Can I acheive this? As a developer, I want
Context: As a developer - i typically never log into public instance. The expected practice is that i drop files in the directory, I then see the tasks in adminCentral, approve the tasks, and then go to that content and publish it to the public instance. If tasks are always created on public instances - then it would be confusing if developer logs into public instance and finds many import tasks there (and they might not know that the content was already published from the author, etc.) Not a giant problem. |
| Comment by Christopher Zimmermann [ 10/Jul/20 ] |
|
I'd like to rename magnolia.content.bootstrap.initial, as I don't think its clear what it does from the name. I propose
|
| Comment by Christopher Zimmermann [ 10/Jul/20 ] |
|
It would be useful if there was additionally a way for developers to opt to always import without tasks. Maybe another configuration property like: magnolia.content.bootstrap.noTasks=true (default false) |
| Comment by Robert Šiška [ 13/Jul/20 ] |
|
czimmermann
Question remains what should be configurable, what should be the defaults, etc. About bootstrapping into content-type defined workspaces - when both contentType definition and content are present at the instance startup, then it works. But when you just drop a light-module with content, then the content can get picked first (although it usually doesn't from my experience). We had this exact problem with apps and contentTypes and we found some workaround, but I'd rather discourage users from mixing light-modules and content. In that scenario, nobody would expect it work when you import content first. About public/author issues - I guess there could be some checks in code whether you're on author, but wouldn't it be easier to just disable content bootstrapping on public through magnolia properties? That would also be much more clear if we encouraged to have content and light-modules on separate locations. |
| Comment by Christopher Zimmermann [ 13/Jul/20 ] |
|
Thanks for the diagram. Process looks good. Re issues with dropping light-module with content on running instance. We can certainly live without it. And evaluate later. Personally I think lightmodules should be able to include content, but there is a lot of disagreement there so for now I recommeend the pattern of not including bootstraps in light modules. Re disabling contgent bootstrapping on public: Sadly this just becomes way too difficult for a developer. You could easily have 10's of bootstrap files. To process each task is minimum of 3 clicks. And then you need to know where all of these imports are and go to those apps to publish them all. A 'magnolia.content.bootstrap.noTasksOnInstall' property mitigates this. We should in the future look into:
|
| Comment by Robert Šiška [ 15/Jul/20 ] |
|
What's been implemented:
Defaults are onlyImportAtInstall=false and createTasks=always. Valid values for createTasks are always, onchange & never. |