System variable(s) used to unlock the menu links?

Would it be easier to create a custom menu that you could better control with variables?

Perhaps add a link in the player to replace the normal course menu with a slide of your design, launched as a lightbox?

I actually did that with the original GUI, but wanted to convert to new modern GUI and take advantage of some features. The lock is disabled by selecting the Next btn, so there has to be a system variable or combination of, that fires off.  Was testing assigning menu.slides, menu.visited, menu.sectionSlides, menu.slidesVisited, etc... but haven't hit the prize yet.

Many Thanks!

James,

The only solution with the built-in player menu is to use Javascript to access the backend of Storyline. The main setting is located in "Story_Content/frame.xml" there you will see:

<optiongroup name="menuoptions">
<options>
<option name="flow" value="free" />


This data feeds your "frame.desktop.min.js" file. There is bound to be a solution using Javascript that will allow you to dynamically change the "flow" settings. 

Hi, we've stumbled onto this and other similar threads; after the same functionality. I've submitted as a feature request and encourage anyone else interested in doing the same. The more that ask ups the chances for consideration. I feel it would be a valuable inclusion as a feature. Custom building a menu means not being able to use the built-in restricted Next button feature, which is a loss. (and a LOT of custom variables and triggers to replicate.)

Here's the text of my request.

A trigger to change a restricted menu to free flow.

(even better would be section (or even slide-level) granularity...but I know that's a reach.) Use case: we want to develop a course with a pre-test where student could test out of various topics. Failed topics remain restricted and must be viewed, but once viewed all topics are unlocked, including the ones they "passed" and weren't required to view.

This CAN be accomplished by building a custom menu, but it's a lot of extra programming.

Reading this i remembered a similar question i found a workaround for. Post about that is here.
https://community.articulate.com/discussions/articulate-storyline/trigger-to-change-player-flow

Basically the solution i had was not trying to change 'restricted' to 'free' but blocking list items in the menu thus in fact restricting choices.

https://360.articulate.com/review/content/c6b7e48a-f204-441d-81ea-4cdd5ed6a524/review

This approach also has the big advantage that you can customize menu items/list items as you can see in the second example.

https://360.articulate.com/review/content/146cbdd5-f36c-4ce4-a5f6-94effde85c42/review 

Working Storyline added.

Thanks! This is super helpful and very clever. The only potential problem I saw: if you click the Restrict button a couple of times in a row (instead of alternating between Restrict and Free), it keeps adding duplicate overlay boxes. The Free button will only remove one of those. I figure you could either have the Restrict button disable itself, or what I've done is added a few lines to check if there's already an overlay and nested the createElement code inside of an if statement.

let boxTest = document.getElementById('olID');
let b = boxTest ? true : false;

if (!b) { ...then your code...}

Hi Ted...I sent in the request as well.  This seems like a feature that should already be offered.  I see a lot of training come around with Test Out options.  I'm sure you could do this with a Custom Menu but this seems like a silly waste of time.  I really want to take advantage of the power of the Standard built-in menu.

The solution i added uses the Standard built-in menu. Just enhances it so it can be blocked or set free. Ted's addition fixes an issue i did not encounter ( due to lack of proper testing )

Hey Math and Ted.  

This code you offered up removes the "lock" symbol from the Menu but it does not unlock the menu item.  Any thoughts as to why this is happening?  I assume you were truly trying to unlock the Menu item vs just hiding the symbol?

const boxes = document.querySelectorAll('.cs-listitem');

for (const box of boxes) {
box.classList.remove('cs-restricted');
}

const menuItems =document.querySelector("#outline-content > ul > li");
const overlay = document.querySelector("#olID");

overlay.remove()

Ultimately I would like to remove the lock symbol and replace it with the "Check" but it has to be truly unlocked so the user can choose any slide within the skipped slides in a Module.  

Storyline uses several classes to set a menu item to restricted or locked. Namely 'cs-restricted' and 'cs-locked'. In principle you can make your own set of CSS classes and use those instead of Strorylines... or change the definition of the used classes in Storyline. Either by Javascript on start of a course or hacking it inside Articulate's folders.

I think we need to clarify, the above solution (Math's original with my little addition) is not really  locking and unlocking the built-in menu. It simulates locking by covering up the menu with the overlay element the code creates--and the CSS classes make the menu items appear locked or unlocked--but the menu setting in the Storyline player has to be left as "Free" when you publish.

So, this technique is just a workaround. I would still like Articulate to give us the ability to actually lock or unlock specific menu items with a trigger, leaving whatever topics they missed in the pretest locked and required to view.* Clearly the coding is there because things are currently locked and unlocked, but only as the student views slides one at a time. The testing out feature I really want would require a trigger to unlock parts of the menu,

*Bear in mind, using this approach might affect the completion criteria your course is set to. Percent or number of slides viewed won't work if you're letting them test out of viewing certain slides.

Nicely explained Ted :-)

Thanks to both of you for the info.  I agree...Articulate should add this as a feature!  Since my course is currently "locked" by page my completion criteria happens on the second to last page.  Long story.  So, jumping from Mod to Mod in a linear fashion would be fine if we could unlock those skipped pages.