Rename the README title to Extended OCC Web (occ & SQL terminal), link
the App Store listing, and describe the fork history in the past tense:
the project no longer tracks fanategorius/occweb. Credits stay.
One long value made every line of the table wider than the terminal,
so the whole table wrapped. Narrow the widest columns until the table
fits and end cut values with an ellipsis. Adding --full to the query,
which is an SQL comment, shows the values in full as before.
Only admins can use the app, so who gets admin rights decides who can use
it. The database should run as a scoped user without superuser or
server file/program rights, since the SQL checks are an extra layer.
Explain why sensitive occ commands are not blocked: an admin can reach
the same information in other ways, so a blocklist would only give a
false sense of security and make the app less useful.
Core still provides a working jQuery on NC32/33, but via a read-only
window.$ getter - loading our own vendored copy there too made its UMD
wrapper throw trying to reassign window.$ (confirmed on real containers,
harmless in practice since this app attaches via window.jQuery, but a real
avoidable console exception). Gate the extra script() call on
ServerVersion::getMajorVersion() >= 34 instead.
Re-tested both sides of the boundary: NC32 no longer requests jquery.js and
has zero console errors; NC34 still requests it and still works.
testbak/ (local, non-AIO docker compat rigs for NC32/33/34/35) found a real
fatal on NC35: OccOutput::setErrorOutput() didn't declare the ": void"
return type the Symfony Console version NC35 bundles now requires on
ConsoleOutputInterface. Fixed by declaring it - compatible with older
Symfony/NC versions too since it only narrows an untyped parent signature.
32/33 were also verified functional (the previously-suspected jQuery
getter-conflict console exception on those versions is real but harmless -
the app attaches via window.jQuery, not window.$).
min-version/max-version narrowed from 30/34 to 32/35: 30/31 were never
actually tested even before this session, so keeping them was an unverified
claim; 35 is now genuinely verified rather than guessed.
Independent Codex review of the app-id rename found real gaps our own
review missed:
- Makefile: app_name was derived from the checkout directory's own
basename, not the app id in appinfo/info.xml. Our actual working
checkout is still named "occweb" (matches the repo name), so
building from it would have produced an "occweb"-named/rooted
archive under the new "extended_occweb" id. Fixed by deriving
app_name from info.xml via xpath (same technique already used for
VERSION), and added an ensure-app-name-symlink step so the
Makefile's inherited "../$(app_name)" references (used throughout
the source/appstore tar exclude patterns) keep resolving correctly
regardless of what the checkout directory is actually named.
Verified end to end: `make appstore` now produces
extended_occweb.tar.gz with extended_occweb/ as its single top-level
folder, matching the App Store's stated requirement.
- Makefile: sign target had "occweb" hardcoded into both the
certificate path and the archive filename - broken independent of
the app_name fix above. Now derived from the same variables.
- Makefile: version target pushed the release tag to the "origin"
remote, which in this repo is the stale upstream
(fanategorius/occweb), not somewhere we want to push. Changed to
"fork" (dillardblom/occweb), matching how every tag has actually
been pushed this whole session.
- INSTALL-AIO.md / notes/deploy-nc01.md: the deploy snippet did
`git archive main` unconditionally, silently deploying the main
branch even if an operator had checked out a specific tag or
maintenance branch as instructed elsewhere. Changed to `git archive
HEAD`.
- README.md: the compatibility matrix's rollback advice
("git checkout v0.3.4") doesn't actually work as a rollback anymore
post-rename - that tag still declares the old occweb id, so checking
it out under an extended_occweb-named install just breaks. Added a
caveat explaining what a real rollback requires; full migration docs
are still deferred to when a test instance exists (tracked
separately, not written up here).
- js/index.js: the occ-command ajax call used the wrong jQuery .fail()
signature ((response, code) instead of (jqXHR, textStatus,
errorThrown)), so any failure printed the literal string
"[object Object]" instead of a useful message.
- js/index.js: the initial bootstrap call that builds the terminal had
no .fail() handler at all - a failure there (expired session/CSRF
token, network error, rejected admin check) left #app-content
permanently blank with zero diagnostic information. This is exactly
what made today's NC34 debugging session harder than it needed to
be; now it shows the actual HTTP status/reason in the page.
- OccController.php: translated a leftover Dutch comment (missed by
the earlier Russian->English pass since it wasn't Russian), and
documented why requireAdmin() is intentional defense-in-depth rather
than a misunderstanding of the framework: verified against
Nextcloud's own SecurityMiddleware source that any controller method
without @NoAdminRequired already rejects non-admins by default, so
this check (and the original "security fix" commit that added it)
was addressing a non-issue for THIS controller specifically.
DbController's equivalent check is still genuinely load-bearing -
that controller originally shipped with @PublicPage, which does
bypass the default protection - so it gets a note explaining the
distinction instead.
- README: added compatibility matrix rows for 0.4.0 (app id rename to
extended_occweb) and 0.4.1 (these fixes), both verified on NC 34.0.4.
Deferred to when a test instance exists (tracked, not fixed here): no
documented migration path from the old occweb id to extended_occweb
for existing installs, OccController's constructor doing expensive
work before the (redundant) admin check runs, and js/jquery.js loading
unconditionally on NC30-33 where core still provides jQuery.
Version bump to 0.4.1.
Nextcloud's app id "occweb" is effectively unavailable for a new store
listing: the original Adphi/occweb still owns that App Store slot
(stale, v0.2.3), and el-choco/occweb_v2 has since published a
same-lineage rewrite under its own id. Rather than fight over the
"occweb" name, publish this fork under its own id, matching the
<name> this app has always had: "Extended OCC Web".
Renames every place the literal app id is used: info.xml <id> and the
auto-generated navigation <route>, script()/style() registrations in
templates/index.php, the TemplateResponse app name in
OccController::index(), the /apps/... base URL in js/index.js, and the
'app' log context tag in DbController.php. The GitHub repo name and
its <website>/<bugs>/<repository>/<screenshot> links are unaffected -
those identify the repo, not the Nextcloud app.
Docs (README, INSTALL-AIO.md, install.sh) updated to clone into and
reference an "extended_occweb" directory, since Nextcloud requires the
app folder name to match its id - a plain `git clone` of this repo no
longer produces a correctly-named install directory on its own.
Version bump to 0.4.0 given the scope (breaking change for anyone who
already deployed under the old "occweb" id - requires disable+remove
of the old app and a fresh enable under the new id, not an in-place
upgrade).
README.md and install.sh's install instructions still told new users to
git clone the abandoned upstream (fanategorius/occweb), which lacks all
of this fork's fixes. Point those at dillardblom/occweb; leave the
Credits section's links to Adphi/fanategorius as-is since those are
deliberate attribution, not install instructions. Also repoint the
README screenshot badge, which was hotlinking Adphi's repo.
composer.json still listed only the original author; add ourselves
alongside, matching the info.xml author field.
Revert max-version 40->35: 35 was fanategorius's own tested release
value (commit 7c09dd2), not a guess. Bumping to 40 was our own
speculative headroom into an untested future major - exactly the
pattern this project's own history already reverted twice, for the
same stated reason ("hasn't been tested against newer Nextcloud
releases"). Getting auto-disabled by the compat check on an untested
major is the correct, safe failure mode; claiming compatibility we
haven't verified is not. 35 still satisfies the Codex finding (no
narrowing below a previously-validated ceiling) without guessing ahead.
Was untracked locally and stale (referenced apps/ instead of custom_apps/,
git clone inside the container instead of our tar-based deploy). Documents
the two things that just caused a production incident on nc01: files
extracted from a tarball keep the source uid/gid and need an explicit
chown to www-data, and skipping the installed_version sync after bumping
<version> puts the whole instance in "needs upgrade" state, which blocks
not just occ commands but the web login page too.
Link it from README.md's install section.
Also backport OccController's getConfig() -> IConfig::class fix (deprecated
internal API -> stable OCP interface), spotted while comparing against
Git-Usr123/occweb.
- New 'rename-user' template (templates / template rename-user <old> <new>):
best-effort uid rename across core tables (oc_users, oc_preferences,
oc_group_user, oc_group_admin, oc_ldap_user_mapping, oc_share, oc_mounts,
oc_storages). Explicitly NOT a supported Nextcloud operation - the
generated script carries an in-line warning (as leading SQL comments)
that app-specific tables (Talk, Calendar, Contacts, Mail, 2FA/WebAuthn...)
are not covered and that the data directory must be renamed on disk
manually, followed by occ files:scan --all. Documented the same caveat
in both READMEs.
- Hardened the round-2 transaction wrapping: beginTransaction()/commit()/
rollBack() are now wrapped in try/catch. PostgreSQL (our backend) has
fully transactional DDL so this wasn't actually broken here, but
Nextcloud also supports MySQL/MariaDB via the same IDBConnection, where
DDL implicitly commits - on that backend a DDL statement in the batch
would make a later commit()/rollBack() throw 'no active transaction'
and previously that exception was unhandled (HTTP 500 instead of a
clean JSON response). Now: if rollBack() itself fails after an error,
we report rollbackFailed+warning instead of falsely claiming rolledBack,
since earlier statements in that batch may already be permanently
applied. If commit() fails with nothing to commit (already
auto-committed), that's logged only, since the effects are already
durably persisted.
dillard
Egor Bugaev