fix: accept folder.view2 exports in Import Everything - #53
Conversation
Import Everything rejected any file without an fv3_export_version wrapper, so a folder.view2 backup dead-ended on "Not a valid FV3 backup file." The file was always importable — the dedicated Import Docker/Import VM buttons take it verbatim — but nothing pointed there, and those buttons already detect the reverse mistake and redirect. Only this direction was missing. Import Everything now detects a bare folder export (one folder object or an id => folder map) and offers Docker/VM buttons, reusing the same import path as the dedicated buttons. The type choice is buttons rather than confirm/cancel because sweetalert reports ESC and Cancel identically, so a dismissal would silently import as whichever type happened to map to false. They are bound with addEventListener: an inline onclick inside sweetalert's own markup compiles but never fires. Extract fv3ImportFolderMap() so the docker, vm and folder-export paths share one loop instead of three copies. Behaviour is unchanged, including vm import not calling sync_order.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe change centralizes folder-export validation and import handling for Docker, VM, and full-backup imports. Full-backup imports now count valid folder exports and require a Docker or VM selection. ChangesFolder export import
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant FullBackupImport
participant SelectionDialog
participant fv3ImportFolderMap
participant FolderAPI
participant FolderTable
FullBackupImport->>FullBackupImport: validate export and count folders
FullBackupImport->>SelectionDialog: present Docker or VM choices
SelectionDialog->>fv3ImportFolderMap: import selected export
fv3ImportFolderMap->>FolderAPI: create or update folders
fv3ImportFolderMap->>FolderTable: refresh table
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai review |
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@src/folder.view3/usr/local/emhttp/plugins/folder.view3/scripts/folderview3.js`:
- Around line 157-165: Update fv3ImportFolderMap to use
fv3IsFolderShaped(content) instead of the truthiness check on content.name when
selecting the import mode. Route structurally valid single-folder exports,
including empty names, through create.php; otherwise process the folder map with
update.php and preserve the existing docker order synchronization.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 74d4fb44-12c4-4c18-8f41-e8f1efca5294
📒 Files selected for processing (1)
src/folder.view3/usr/local/emhttp/plugins/folder.view3/scripts/folderview3.js
fv3ImportFolderMap picked its import mode with `if (content.name)`. An empty name is legal, so a single-folder export named "" fell through to the map branch and its own keys were posted as folder ids — name, icon, settings, regex, containers, actions all pass update.php's id charset, so six junk folders got written. The inverse also misfired: a map whose folder id is the string "name" was treated as a single folder. Select on fv3IsFolderShaped() instead, which is the same predicate detection already uses, so the two agree. Pre-existing in importDocker/importVm; fixing it in the shared helper covers both buttons.
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai full review |
|
|
@coderabbitai review |
|
|
@coderabbitai full review |
|
|
@coderabbitai full review |
✅ Action performedFull review finished. |
The remove block ran `removepkg folder.view3-<version>`, but since 2026.07.07.1 the package is named folder.view3-<version>-x86_64-1. removepkg aborted with "No such package ... Can't remove" while the following rm -rf lines still deleted the plugin dir and flash config, orphaning the /var/log/packages entry. upgradepkg --install-new then reported "Skipping package ... (already installed)" on reinstall, so files were never extracted and the plugin came back dead while plugin-manager reported success. - Remove now globs /var/log/packages/folder.view3-* and removepkg's each basename: version-agnostic, and it also clears legacy pre-2026.07.07.1 entries the old exact-name call could never match. Siblings folder.view and folder.view2 do not match the glob. - Install gained --reinstall so a stale entry can never suppress extraction. - The package name now has a single definition (&pkgname;) referenced by the pre-install prune, the install FILE/URL and the post-install keep-check, so the four-way hand-reconstruction that allowed this drift is gone. Builds beta 2026.08.14.1, bundling the two fixes already on beta: folder.view2 exports accepted by Import Everything (#53), and autostart membership matching what the Docker page renders (#54).
Merges beta into main and builds the stable package. - Uninstall removes the plugin cleanly: the remove block matched the package DB entry without its -x86_64-1 suffix, so removepkg aborted while the following rm -rf lines still deleted the plugin dir and flash config. The orphaned entry then made upgradepkg skip extraction on reinstall, leaving the plugin installed-but-dead. - Import Everything accepts a folder.view2 backup file (#53). - Container autostart order matches the folder membership the Docker page renders, including label-assigned containers (#54). CHANGES consolidated to a single ###2026.08.14 heading; main keeps its stable changelog history rather than beta's per-build entries.
1 participant
Problem
A folder.view2 user reported their backup JSON could not be imported into FolderView3 and that they had to convert it by hand.
The file was always importable — Import Docker / Import VM accept a bare folder.view2 export verbatim. Import Everything rejected it, because
importAllrequires anfv3_export_versionwrapper and folder.view2 has no such concept: it downloadsDocker.json/VM.json, a bareid => foldermap, or a single folder object.The guard was one-directional.
importDocker/importVmalready detect a full bundle and redirect to Import Everything, but nothing pointed the other way — the error readNot a valid FV3 backup file., which reads as "your file is broken" and sends people off to convert a file that never needed converting.Change
Import Everything now detects a bare folder export and offers Docker folders / VM folders, reusing the same import path as the dedicated buttons.
Two details worth calling out:
doneFunction(!1)), so mapping the two types onto that boolean would silently import as whichever type mapped tofalsewhenever the dialog was dismissed.addEventListener. An inlineonclickinside sweetalert's own markup compiles but never fires — the modal swallows the click, so the dialog would appear and do nothing.fv3ImportFolderMap()is extracted so the docker, vm and folder-export paths share one loop instead of three copies. Behaviour is unchanged, including vm import not callingsync_order.Detection
A payload counts as a folder export only when it is a single folder object, or a non-empty map whose every value is folder-shaped (
namestring, plus acontainersarray orsettingsobject). Anything else still getsNot a valid FV3 backup file.Verified against{}, arrays,css-config.json,settings.json, and maps containing a non-folder member.Testing
Verified on Unraid 7.3.2 against plugin 2026.08.01, driving a real
Filethrough the real file input:docker.json, original ids and regex intactvm.json,docker.jsonuntouchedImported folders keep their folder.view2 ids, so members and settings carry over unchanged.
Summary by CodeRabbit
New Features
Bug Fixes