Actions not visible after moving content

Hi community,

We wrote an updater to move a folder (with sub folders) to another folder (via session.move) and we’re seeing weird behavior. When non-admin users click the context menu on a sub folder of the moved folder, they will see “No actions available”. Also, when they open an article inside one of the moved sub folders, they will not see the top bar with the edit actions.

If an admin does the same, they do see the context menu and action bar. When clicking “Edit allowed content…” in the context menu and saving (without changing anything) the other users can suddenly see the context menu again. When republishing the article again, non-admin users also get the action bar back (for those particular sub folder and article). This seems to indicate that this is not a permission issue.

We ran a consistency check hoping that this would identify an issue, but it came back empty:
17:18:23 version: loaded 2149000 infos…
17:18:24 checking 59132 node references
17:18:24 0 missing targets; 0 broken references
17:18:25 checking 91734 node references
17:18:25 0 missing targets; 0 broken references
17:18:25 default: checked 2149156 bundles.
17:18:25 Checked 2149156 nodes in 25702 ms.
17:18:25 0 problems found
17:18:25 Done

Any idea what could be the issue and fix here? We would of course rather not write an updater that touches all sub folders and articles for this.

Kind regards,
Davey Chu

I guess you might have created folders using JCR API somehow and move documents afterward. In that case, you have to carefully set some system internal properties on the folders too. Otherwise, some actions on the folders might become unavailable.
You might want to use the programmatic APIs option [1] of the folder-context-menu forge plugin in your updater scripts or Java code, to take advantage of the best practices and knowledge.



Are these system internal properties visible in the console or how can we see them? We haven’t created any folders. We only moved an existing folder node (with its children) to be the child of another existing folder node. After the workaround mentioned in the original post, the console does not show any difference (if we compare the yaml export before and after).

If someone else has the same issue, we seem to have solved it with the following updater code:

boolean doUpdate(Node node) {
    try {
        if (node.hasProperty("hippo:name")) {
            node.setProperty("hippo:name", node.getProperty("hippo:name").getValue())
        if (node.hasProperty("hippostd:state")) {
            node.setProperty("hippostd:state", node.getProperty("hippostd:state").getValue())
    } catch (e) {
        log.debug "something went wrong $e"
    return false

Still no clue what caused it and why making a fake change fixes it. If anyone can shed some light on this matter, please do.