nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Renaming pages breaks the ".page <=> Site Map" association (if you don't have perms).

System

----------------------------------------------------------------
TeamSite/SitePublisher 6.7.2
LiveSite 3.1
Solaris 9
----------------------------------------------------------------

Hi folks,

I created a support ticket for this, but unfortunately Iwov is saying that there’s no fix. They’re filing a defect with engineering. So…I’ll put this question to the community, and maybe someone has come up with a clever workaround.

Problem summary: Users who don’t have Site Map editing permissions can still rename .pages, which breaks the associations within the Site Map.

In a nutshell: We’re building a web site that uses the Site Map extensively. The entire navigation architecture is based on it. Only site administrators will have permissions to edit the Site Map (i.e., “Edit Site Map” is CHECKED in the “Manage Roles” admin setting).

Good: When an administrator renames a .page file, that change is automatically reflected in “default.sitemap”. This is fantastic! Links don’t break, and pages across the site are automatically updated.

Not so good: When a NON-administrator renames a .page file, the page gets renamed; however, default.sitemap is NOT changed. As a result, the ".page <=> Site Map" association becomes broken across the entire site. I think we can live with default.sitemap not getting updated (due to permissions), but under that scenario, the user should NOT be allowed to rename that page.

Is anyone else here using the Site Map in a similar manner? Can you think of any clever workarounds?

Thanks in advance,

Find more posts tagged with

Comments

Adam Stoller

...
Not so good: When a NON-administrator renames a .page file, the page gets renamed; however, default.sitemap is NOT changed. As a result, the ".page <=> Site Map" association becomes broken across the entire site. I think we can live with default.sitemap not getting updated (due to permissions), but under that scenario, the user should NOT be allowed to rename that page.

Is anyone else here using the Site Map in a similar manner? Can you think of any clever workarounds?

Thanks in advance,

The classic response would be: Replace the OOTB menu item for Rename with a custom menu item that performs some checks before determining whether it can proceed with the OOTB Rename functionality (either via Perl/CLTs or Java/CSSDK code)

Migrateduser

Thanks, Fish. Yup, that would certainly be one avenue...something I was sort of hoping to avoid. But it may be the only feasible solution *sigh*.

I wonder if there's a way to leverage an "iwat" trigger (RenameFSE), and do some checks there. Though, I can't think of a way to block a rename through a trigger Smiley Sad

Rats and double rats...

Adam Stoller

Thanks, Fish. Yup, that would certainly be one avenue...something I was sort of hoping to avoid. But it may be the only feasible solution *sigh*.

I wonder if there's a way to leverage an "iwat" trigger (RenameFSE), and do some checks there. Though, I can't think of a way to block a rename through a trigger

Rats and double rats...

Since the triggers are post-operative and you're trying to pre-vent something - no, the triggers are probably not the way to go (unless you want to re-rename something behind the user's back and get them very confused)

Migrateduser

To get around the bug, I'm thinking that we might be able to handle this with workflow. We could authorize "everyone" to edit the Site Map, and then auto-attach default.sitemap any time a user submits their renamed page. We already have a "special" review task in the workflow when "default.sitemap" is attached. Hopefully this would capture the majority of unintentional changes.

Migrateduser

Good news! This turned out to be a non-issue. We had a bad (and confusing) combination of role/group assignments at the branch level. I think there were some overlapping and/or missing permissions. Somehow it caused conflicts with the group permissions for default.sitemap. Once we separated the branch’s role/group permissions from file/folder permissions, NON-administrators were able to rename .page files successfully (and the default.sitemap was updated accordingly).

Caveat: When a user renames a .page, the default.sitemap file becomes locked to them. Until default.sitemap is unlocked, users will experience the issue that’s in the "Problem summary" in my original post above. I think this can be handled with good policy (i.e., train users to unlock default.sitemap whenever they rename or move .page files).

Lesson learned: Our "roles" configuration is overly complex. While this is necessary for our requirements, we need to find a way to clarify (and simplify) permissions. Things can quickly get confusing if you don’t consider your "roles" architecture carefully.

Thanks,