Change Details

## User Story "As an editor, I frequently use the tools provided in the sidebar and would like it to remain open and available as I navigate the site". As discussed in T246427, the collapsible sidebar should have the ability to maintain its collapsed/expanded state while navigating between pages. This task encompasses the work needed to implement that functionality **for logged-in users only**. The state will be tied to the users account, and will therefore persist across devices and loggged-in sessions as well. ## Technical approach - We need to create a new hidden user-preference that stores the sidebar open/collapsed state. - Based on that preference, we conditionally set the `checked` attribute of the `<input type="checkbox" class="vector-menu-checkbox vectorMenuCheckbox" aria-labelledby="{{label-id}}">` element in [[ https://github.com/wikimedia/Vector/blob/72afb66fb8b3f571b1deba131e53f03447a4df2d/includes/templates/Menu.mustache#L9 | Menu.mustache ]] in PHP. - When a user clicks the menu icon, we intercept that click with JS that sends an AJAX request to the API endpoint that updates the user-preference. The user preference should not be visible as an option in Special:Preferences, since it would be redundant to have the same functionality in two places. That makes this a **JS only** feature. ## Open questions **How do we handle narrow widths?** If the design of the sidebar overlaps the content at very narrow widths and takes up lots of space, like it does on Minerva, then keeping it open across page-views would be unexpected an undesireable. **[[design needed]]** ## Acceptance criteria [] A feature flag exists that can be used to disable saves the database in the event the traffic is much higher than expected. - While logged in, the sidebar retains state: - [] while navigating between pages. - [] across devices. - [] after logging-out and logging back in again. **QA environment**: Beta cluster ## Sign off steps [] Make sure we've reached out to the DBA with the deployment plan and expected traffic to the preferences database table

## User Story "As an editor, I frequently use the tools provided in the sidebar and would like it to remain open and available as I navigate the site". As discussed in T246427, the collapsible sidebar should have the ability to maintain its collapsed/expanded state while navigating between pages. This task encompasses the work needed to implement that functionality **for logged-in users only**. The state will be tied to the users account, and will therefore persist across devices and loggged-in sessions as well. ## Technical approach - We need to create a new hidden user-preference that stores the sidebar open/collapsed state. - Based on that preference, we conditionally set the `checked` attribute of the `<input type="checkbox" class="vector-menu-checkbox vectorMenuCheckbox" aria-labelledby="{{label-id}}">` element in [[ https://github.com/wikimedia/Vector/blob/72afb66fb8b3f571b1deba131e53f03447a4df2d/includes/templates/Menu.mustache#L9 | Menu.mustache ]] in PHP. - When a user clicks the menu icon, we intercept that click with JS that sends an AJAX request to the API endpoint that updates the user-preference. The user preference should not be visible as an option in Special:Preferences, since it would be redundant to have the same functionality in two places. That makes this a **JS only** feature. ## Open questions **How do we handle narrow widths?** If the design of the sidebar overlaps the content at very narrow widths and takes up lots of space, like it does on Minerva, then keeping it open across page-views would be unexpected an undesireable. **[[design needed]]** ## Acceptance criteria [] A feature flag exists that can be used to disable saves the database in the event the traffic is much higher than expected. **QA environment**: Beta cluster - While logged in, the sidebar retains state: - [] while navigating between pages. - [] across devices. - [] after logging-out and logging back in again. ## Sign off steps [] Make sure we've reached out to the DBA with the deployment plan and expected traffic to the preferences database table

## User Story "As an editor, I frequently use the tools provided in the sidebar and would like it to remain open and available as I navigate the site". As discussed in T246427, the collapsible sidebar should have the ability to maintain its collapsed/expanded state while navigating between pages. This task encompasses the work needed to implement that functionality **for logged-in users only**. The state will be tied to the users account, and will therefore persist across devices and loggged-in sessions as well. ## Technical approach - We need to create a new hidden user-preference that stores the sidebar open/collapsed state. - Based on that preference, we conditionally set the `checked` attribute of the `<input type="checkbox" class="vector-menu-checkbox vectorMenuCheckbox" aria-labelledby="{{label-id}}">` element in [[ https://github.com/wikimedia/Vector/blob/72afb66fb8b3f571b1deba131e53f03447a4df2d/includes/templates/Menu.mustache#L9 | Menu.mustache ]] in PHP. - When a user clicks the menu icon, we intercept that click with JS that sends an AJAX request to the API endpoint that updates the user-preference. The user preference should not be visible as an option in Special:Preferences, since it would be redundant to have the same functionality in two places. That makes this a **JS only** feature. ## Open questions **How do we handle narrow widths?** If the design of the sidebar overlaps the content at very narrow widths and takes up lots of space, like it does on Minerva, then keeping it open across page-views would be unexpected an undesireable. **[[design needed]]** ## Acceptance criteria [] A feature flag exists that can be used to disable saves the database in the event the traffic is much higher than expected. **QA environment**: Beta cluster - While logged in, the sidebar retains state: - [] while navigating between pages. - [] across devices. - [] after logging-out and logging back in again. **QA environment**: Beta cluster ## Sign off steps [] Make sure we've reached out to the DBA with the deployment plan and expected traffic to the preferences database table