fix: add new pages to sidebar after patch approval #247
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR addresses issue #244 (refer to the full description there).
Problem
New Wiki Pages can be published in two distinct ways: (i) immediately, if the creator holds the
Wiki Approver
role; or (ii) pending manual approval of the associatedWiki Page Patch
if the creator lacks theWiki Approver
role.The logic for this is embedded in the whitelisted
update
function within thewiki/doctype/wiki_report/wiki_report.py
file. This function checks if the user possesses thesubmit
perm for that doctype to determine whether to submit it immediately or not. There is an issue within this function: it expects to receive thenew_sidebar_items
argument from the API call, and subsequently stores it (at runtime) in theWiki Page Patch
object. However, this doctype lacks a corresponding field, thus the information is not persisted in the database. Consequently, when the doctype is not immediately submitted, this information is lost, preventing its later use in updating the sidebar.Solution
In my opinion, there is a design flaw in how sidebar updates are currently managed. Nevertheless, I have chosen not to alter the existing mechanism within this PR (such a refactor could be pursued in a following PR). My solution leverages the
new_sidebar_group
property (an existing property of the doctype) to compute the position in the sidebar and to update it when thenew_sidebar_items
property is not present (preserving the original behavior).