Based on your use case I would recommend checking out the blog post on access signposting by SuzieH because it sounds like it accomplishes similar to what you’re looking for.
Jeff, thanks! Following the link you have shared I see suggestions how to make an IF statement using UserRoles and CoreNode ID's and CoreNode Ancestors.
With this I should be able to make a component appear for Testmembers when the current node is not a test environment and they are about to write a comment.
The real challenge will be to add a component to the postpage (start a discussion page). Can I even do that using the page and component editors in studio?
Yeah, depending on where you're wanting to place the component (e.g. banner across the top of the page, etc.) then you can just add the component to the PostPage quilt.
In our environment I even had to get a bit more creative since the new support case form in the Case Portal also utilizes the PostPage and I wanted the editor to be two-thirds width in the Case Portal with a right rail for case information/policies (not unlike the Case Portal in Atlas) but wanted the editor to span the full width everywhere else.
So I decided to create a custom layout for the PostPage which is shown below.
In my layout I keep the main-content section for most discussion styles, and then created the support-main-content and support-side-content sections to be specific to the Case Portal.
This is what the XML for my PostPage quilt looks like:
<quilt layout="custom.postPage" nestable="false" disableTopCssClass="false">
<add to="common-footer">
<component id="quilt:Footer"/>
</add>
<add to="masthead-standard">
<component id="custom.page.masthead"/>
<component id="common.widget.breadcrumb"/>
</add>
<add to="support-main-content">
<component id="custom.postPage.editor" casePage="true"/>
</add>
<add to="common-page-title">
<component id="common.widget.page-title"/>
<component id="custom.submit.integrations.ideas"/>
</add>
<add to="support-side-content">
<component id="custom.case.casepageinfo"/>
</add>
<add to="main-content">
<component id="custom.postPage.editor"/>
</add>
<add to="common-header">
<component id="quilt:Header"/>
</add>
<remove from="sub-header-main" for="Header">
<component id="common.widget.search-form"/>
</remove>
<remove from="header-right" for="Header">
<component id="common.widget.search-form-toggle"/>
</remove>
</quilt>I wanted to be able to call the out-of-the-box editor component in both locations without actually rendering it twice and without having to create two separate custom components. (My Components tab in Studio is long enough already!),
So I wrapped the editor component in a custom component called custom.postPage.editor (shown below) and I included it twice in my quilt, while defining a component parameter called casePage in only one of them.
<#-- Get the casePage component parameter value if defined -->
<#assign casePage = env.context.component.getParameter("casePage")!"false" />
<#-- Convert the parameter value to Boolean -->
<#if casePage == "true">
<#assign casePage = true />
<#else>
<#assign casePage = false />
</#if>
<#-- Define when the rich-text editor should be rendered -->
<#if page.name == "PostPage">
<#if casePage?? && casePage && page.interactionStyle == "support">
<#-- Only render within the Case Portal -->
<@component id="editor"/>
<#elseif (!casePage?? || !casePage) && page.interactionStyle != "support">
<#-- Only render when not within the Case Portal -->
<@component id="editor"/>
</#if>
</#if>
I know this is probably a weird use case but hopefully it helps illustrate how you can bend the PostPage to your will in Studio. 😊
