Skip to content

Release tools 4.7.0 #345

Description

@jayblanc

✅ Summary

  1. Minimum Jahia version
  2. Testing matrix
  3. Prepare checklist
  4. Tests checklist
  5. Publication checklist

ℹ️ Maintenance release on the 4_x branch (Jahia 8.1 line). The companion release on main is Release tools 5.4.0 — this ticket carries the same two changes, backported.

Minimum Jahia version

We aim at reducing the possible deployment matrices by regularly bumping up the minimum Jahia version when releasing new versions of our modules.
When creating a Release ticket for a module, consult with your PM to identify the new minimum Jahia version this module must be associated with.
The default guideline is for a new module release to be compatible with the 2 previous releases.

Current Jahia Version: 8.1.6.0 (jahia-modules parent on 4_x)
Desired Jahia Version: 8.1.6.0 (no change — deliberately not bumped: the entire purpose of this maintenance release is to serve customers still on the Jahia 8.1 line, so the usual "bump to narrow the matrix" guideline does not apply here)

📜 Testing matrix

Notes for release testing:

Scope: two backports + one older change that was never released. ⚠️ 4_6_0 was tagged in October 2024 — QA-15396 landed on this branch in January 2025 and has been sitting unreleased ever since, so 4.7.0 ships it too. It is not a backport and needs its own testing; don't treat this release as backport-only.

#342feat: enforce authorization in jsp (backport of #329)

  • Every tool JSP now checks the systemToolsAccess permission on /tools at the page itself (tools:requireToolsAccess / ToolsAccessGuard), alongside the existing Shiro filter-chain rule; JspPrecompileServlet does the same. A failing check returns 403 and aborts rendering.
  • The guard itself is the upstream code unchangedJahiaAccountRealm.isPermitted() and applicationcontext-security.xml were diffed between 8.1.6.0 and 8.2.0.0 and are equivalent for this purpose.
  • Adaptations specific to this line: Mockito pinned to the 4.x line (mockito-inline, since 4_x builds on JDK 8); whitespace-neutral JSP inserts preserving each file's line endings (25 of 53 files are CRLF). loadAverage.jsp exists here and is guarded too; packageWiresAnalyzer.jsp / provisioning.jsp do not exist on this line.
  • ⚠️ No automated coverage on this line. The Cypress spec (toolsAccess.spec.ts) was not backported — 4_x has no tests/ directory and no integration-test CI job to host it. QA coverage must therefore be manual and exhaustive:
    • with a user holding systemToolsAccess on /tools → all 54 tool pages still render normally;
    • with an authenticated user without it → 403 on each, no content rendered.
  • Author's own verification (recorded on the PR): all 53 JSPs translate through Jasper in both the pristine and modified trees; the guard is the first executable element of every page; emitted output is byte-identical except groovyConsole.jsp (one newline, from removing a redundant taglib declaration).

#343fix: encode the node path in the JCR query results Repository Explorer link (backport of #341)

  • Single file: src/main/resources/jcrQuery.jsp (re-applied by hand — the file lives at impl/src/main/resources/ on main after the multi-module migration, and line numbers differ). The link now renders ${fn:escapeXml(functions:escapePath(node.path))}.
  • Prerequisites were checked explicitly for the 8.1 taglib: functions:escapePath is present in functions.tld at both JAHIA_8_1_6_0 and JAHIA_8_1_9_0 with the same signature, and the functions prefix is already declared in this JSP.
  • ⚠️ Reviewed but not deploy-verified on this line (it was deploy-verified on main), and nothing in this repo's build compiles this JSP's body. QA must exercise it on a real 8.1 instance: run a JCR query, click through to Repository Explorer — ordinary paths must work unchanged, reserved characters (", <, >, &) must come out encoded. A regression test for this page is still owed.

#95 / #97 — QA-15396: filter management by filter name (merged Jan 2025, unreleased until now — not a backport, 4_x-only)

  • Render filters registered through OSGi are now manipulated by filter name (the same key already used to display them) instead of the previous identifier, which did not match for OSGi-registered filters. Labels for the disable/enable actions were corrected on this branch.
  • QA instruction: on the render filters tool, list the filters, then disable and re-enable one registered by a module via OSGi and confirm the action applies to the intended filter and that its state is reflected correctly after a refresh. Check the disable/enable labels read correctly.
  • This change has never shipped to customers, so it carries the full risk of a first release — it should not be waved through on the assumption that "everything here is already validated on main".

Release mechanics on this line (differ from main):

  • The release must be triggered from the 4_x branch, not main.
  • 4_x releases via maven-release-plugin and has no .chachalog/ — the changelog is written by hand, it will not be generated.

Version matrix

We aim at clearly documenting the possible deployment scenarios in a matrix and specify which ones are expected to be tested or not.
In the testing matrix, always use the latest patch version of a particular release

The following combinations should be validated:

ℹ️ If you are releasing for the main branch of a module, make sure to complete the checklist below when working on the ticket.

✏️ Prepare checklist

  • All other tickets within that milestone are are closed — verified: this ticket is the only open item in tools 4.7.0
  • Testing matrix and Minimum Jahia version are detailed
  • Jahia-parent (minimum Jahia version) was updated if requested in the ticket — not requested: minimum stays 8.1.6.0 by design on this line, so nothing to do
  • Release creation has been triggered from the Github Release UI (detailed documentation) — triggered from 4_x as pre-release 4_7_0workflow run 30554161707

⚠️ This line's workflow runs release-publication, which promotes the staging repository straight to the Nexus release repository (autoDropAfterRelease: true). Unlike main, 4.7.0 is therefore published on success, before the Tests checklist below is worked through — that was an explicit, informed decision by the release owner, not an oversight. The Tests checklist becomes post-publication verification; any defect needs a 4.7.1.

🚦 Tests checklist

General

  • Manual tests detailing testing steps for validating the release of this module are present on Testrail
  • Automated tests using the release artifacts were executed against the oldest and newest release of Jahia

Module migration

  • Upgrade from the previous released version of the module was tested
  • The upgrade did not require clearing the browser cache (i.e. missing labels)

While Testing

  • No warnings or errors are present in the browser console when testing the module
  • No warnings or errors are present in Jahia logs when testing the module (incl. migration)
  • Select a random set of fixes from the release and verify them on the minimum jahia-version

After Testing

  • Tested combinations (Jahia versions, modules versions) are listed in this released ticket
  • Tested scenarios not detailed in Testrail are listed in this release ticket
  • The version was updated in the Selenium integration tests

🚀 Publication checklist

  • The release changelog was prepared
  • In case of a major release, a Breaking Changes section is present in the Changelog
  • The artifact was released on Nexus
  • If the module is included in Jahia distribution, jahia-pack-private was updated with the released version
  • ⚠️ If the module has a dependency to a recent release of graphql-dxm-provider, server-availability-manager or personal-api-tokens, contact the Cloud team to require their approval before publication.
  • If applicable, corresponding academy pages were published
  • The module was published on the store
  • The modules releases log page on the Academy was updated
  • A message was published on slack #releases channel
  • The milestone on GitHub was closed
  • The GitHub Release is not in Draft anymore and does contain the changelog

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions