Skip to content

NPS-D: clarify MongoDB 8 migration requirements - #1460

Merged
TM-PO-Netwrix merged 2 commits into
devfrom
tm-npsd
Sep 1, 2026
Merged

NPS-D: clarify MongoDB 8 migration requirements#1460
TM-PO-Netwrix merged 2 commits into
devfrom
tm-npsd

Conversation

@TM-PO-Netwrix

Copy link
Copy Markdown
Contributor

Summary

  • Add a MongoDB 4.0 deployments notice to the NPS-D landing page (index.md), explaining the 26.09.0 bridge release and the upcoming platform update (Python 3.13, MongoDB 8.0 required)
  • Update deploysecureone.md and upgrademongodb4to8.md to decouple the migration deadline from a specific version number (26.09.1), instead referencing "the NPS-D release that updates the backend to Python 3.13 and supported library versions"

Test plan

  • Verify the new MongoDB notice renders correctly on the landing page
  • Verify updated wording in deploysecureone.md and upgrademongodb4to8.md is consistent
  • Confirm build passes

Generated with AI

Co-Authored-By: Claude Code ai@netwrix.com

@github-actions

github-actions Bot commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Documentation PR Review

Editorial Review

docs/privilegesecurediscovery/2.22/index.md

  • Clarity — Line 44: "before upgrading to that release or any later version" has an ambiguous antecedent. The nearest release named in the sentence is NPS-D 26.09.0, but the intended referent is the future Python 3.13 release mentioned two sentences earlier. As written, a reader can parse this as "complete the migration before upgrading to 26.09.0," which contradicts the preceding instruction to upgrade to 26.09.0 first. Suggested fix: "If your deployment still uses MongoDB 4.0, upgrade to NPS-D 26.09.0 and complete Upgrade MongoDB 4.0 to 8.0 before upgrading to that future platform release or any later version."
  • Clarity — Line 38: "bridge release" is used without definition. This is the product landing page, so it may be the first NPS-D content a reader sees, and the term isn't defined anywhere else on the page. Suggested fix: define it inline — "NPS-D 26.09.0 is the bridge release for moving existing deployments from MongoDB 4.0 to MongoDB 8.0: it is the only release that runs both database versions side by side while the data is copied."
  • Completeness — Line 43: "If your deployment still uses MongoDB 4.0" gives the reader a condition but no way to evaluate it. Nothing on this page tells an administrator how to determine which MongoDB version their deployment runs. Suggested fix: add a pointer — "To determine which MongoDB version your deployment uses, run docker service ls | grep -i mongo on a database node, or run s1 mongo-upgrade check, which reports the current MongoDB engine version."
  • Structure — Lines 37–46: the new admonition follows the :::note block about the 2.22.x end-of-life line, so the page ends with legacy-line guidance followed by current-line (26.09) guidance. A reader scanning for release-line information will expect the 26.09 guidance nearer the "Release Lines" section it applies to. Suggested fix: move the :::important MongoDB 4.0 deployments block above the end-of-life :::note, directly after the "This documentation covers both release lines..." paragraph.

docs/privilegesecurediscovery/2.22/installation/containerbaseddeployment/deploysecureone.md

  • Clarity — Lines 123–125: "the NPS-D release that updates the backend to Python 3.13 and supported library versions" identifies a release the reader cannot act on. Unlike the equivalent text in index.md, this version omits "future," so the reader can't tell whether that release already exists or is still unreleased, and has no version number or way to identify it when it ships. Suggested fix: "...complete Upgrade MongoDB 4.0 to 8.0 before upgrading to a future NPS-D release that updates the backend to Python 3.13 and supported library versions, or to any release after it. Check the release notes for each version to confirm whether it includes that platform update."
  • Completeness — Line 124: "supported library versions" doesn't tell the reader anything actionable — it names no libraries and implies no reader-visible change. Because the sentence's only purpose is to help the reader recognize the boundary release, this phrase adds length without adding a signal they can check. Suggested fix: drop it and keep the identifying detail the reader can verify — "...that updates the backend to Python 3.13."

docs/privilegesecurediscovery/2.22/installation/upgrademongodb4to8.md

  • Clarity — Line 18: same unidentifiable-release problem as deploysecureone.md, and it replaces a concrete, checkable boundary ("NPS-D 26.09.1 and all later releases support MongoDB 8.0 only") with one the reader can't map to a version. This is the page an administrator uses to plan a maintenance window, so an unresolvable "upgrade before release X" leaves them unable to schedule against it. Suggested fix: "> Important: Complete this migration on NPS-D 26.09.0. A future NPS-D release updates the backend to Python 3.13 and supported library versions; as part of that platform update, MongoDB 8.0 is required and MongoDB 4.0 is no longer supported. Check the release notes for each version to confirm whether it includes that platform update before you upgrade."
  • Clarity — Line 18: the replacement is a single 54-word sentence pair inside a blockquote that carries three distinct facts (when to migrate, what the future release changes, what the consequence is). At this length, in a callout, the consequence — MongoDB 4.0 stops being supported — is the easiest part to miss. Suggested fix: split into short sentences as shown above, leading with the action ("Complete this migration on NPS-D 26.09.0.") before the explanation.
  • Consistency — Line 18: the future-release constraint now appears in three files with three different phrasings ("A future NPS-D release will update...", "the NPS-D release that updates...", "the NPS-D release that updates... or to any later release"). Readers who follow the link chain from index.md to this page see the same constraint restated differently each time and may reasonably wonder whether the three describe the same release. Suggested fix: settle on one sentence for this constraint and reuse it verbatim in all three locations.

Summary

8 editorial suggestions across 3 files. Vale and Dale issues are auto-fixed separately.


What to do next:

Comment @claude on this PR followed by your instructions to get help:

  • @claude fix all issues — fix all editorial issues
  • @claude help improve the flow of this document — get writing assistance
  • @claude explain the voice issues — understand why something was flagged

You can ask Claude anything about the review or about Netwrix writing standards.

Automated fixes are only available for branches in this repository, not forks.

@github-actions

github-actions Bot commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Auto-Fix Summary

8 issues fixed, 7 skipped across 3 files

Category Fixes
Dale: idioms 1
Dale: passive-voice 6
Dale: undefined-acronyms 1
Skipped (needs manual review) Reason

| docs/privilegesecurediscovery/2.22/index.md:18 — Dale: undefined-acronyms | NPS-D is a Netwrix product short name and the full product name "Netwrix Privilege Secure for Discovery" already appears earlier in the page, which the rule explicitly excludes from flagging. |
| docs/privilegesecurediscovery/2.22/index.md:11 — Dale: wordiness | The overview sentence about self-administering privilege access is somewhat redundant, but it is approved product positioning prose and any tightening risks changing the intended meaning. |
| docs/privilegesecurediscovery/2.22/installation/containerbaseddeployment/deploysecureone.md:15 — Dale: passive-voice | "All nodes have OS prerequisites installed" is a stative have-something-done construction describing a required condition, not an agentless passive clause; rewriting would make the prerequisite less clear. |
| docs/privilegesecurediscovery/2.22/installation/upgrademongodb4to8.md:20 — Dale: xy-slop | "This process is a side-by-side data migration, not an in-place MongoDB server upgrade" is positive-then-negative disambiguation of a genuinely confusable operation, not the negative-then-positive 'x is not y, x is z' pattern the rule targets. The same reasoning applies to lines 89, 187, 195, and 554. |
| docs/privilegesecurediscovery/2.22/installation/upgrademongodb4to8.md:216 — Dale: passive-voice | "as described in [AWS Configuration]" is a standard cross-reference convention; rewriting it into active voice would restructure the sentence without improving clarity. |
| docs/privilegesecurediscovery/2.22/installation/upgrademongodb4to8.md:62 — Dale: passive-voice | "For an installation originally deployed with an earlier release" is a reduced passive relative clause with no natural active agent; an active rewrite reads awkwardly and could obscure the condition. |
| docs/privilegesecurediscovery/2.22/installation/upgrademongodb4to8.md:608 — Dale: passive-voice | "the checkpoint volume created on the node that ran run" is a reduced passive participle used as a technical noun qualifier; rewriting adds words without improving clarity. Same for similar participles on lines 454, 468, 663, and 949. |

Ask @claude on this PR if you'd like an explanation of any fix.

@TM-PO-Netwrix
TM-PO-Netwrix merged commit b7c4380 into dev Sep 1, 2026
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants