Description
Andrew Isherwood
2021-01-11 11:46:03 UTC
Created attachment 115544 [details] [review] Bug 27378: Add new 'modaljs' syspref type This commit adds a new 'modaljs' syspref type. This is similar to the existing 'modalselect' syspref type but instead of using a file to create a list of selectable options which are displayed in the modal, it assumes that anything can happen within the modal driven by JS, and whatever happens is going to return a string, that will be saved as the syspref value. In our case, the string will be all the details of the “chunks” concatenated into a string Created attachment 115545 [details] [review] Bug 27378: Add sysprefs This commit adds 4 new sysprefs: - CookieConsent - the master on/off for this functionality - ConsentJS - The configuration for JS code that requires consent prior to running. - CookieConsentBar: Allows the admin to specify the HTML that will be displayed in the consent bar that appears at the bottom of the page - CookieConsentPopup: Allows the admin to specify the HTML that will be displayed in the cookie consent popup Created attachment 115546 [details] [review] Bug 27378: Add JS to power modaljs This commit adds the Javascript that provides the functionality within the consentJS modaljs modal. It provides the ability to display the current state of any consentJS values and to amend them, as well as add new ones. There is also some refactoring of the existing modalselect functions to allow re-use of existing code between modalselect & modaljs. This refactoring has been minimal and consists of abstracting functionality into functions to allow more wide use. Styles for the consentJS UI were also added. Created attachment 115547 [details] [review] Bug 27378: Add cookie consent display to OPAC This commit adds the display of the cookie consent bar and modal to the OPAC. - Adds a new JSConsents template plugin that enables a template to be populated with the contents of the ConsentJS syspref in a prepared, usable form - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate - Adds the ability for both authenticated and unauthenticated users to view and modify their consents either via "your consents" or a new unobtrusive "Your cookies" button in the bottom right of the screen. - Adds unit test for JSConsents.pm Created attachment 115548 [details] [review] Bug 27378: Add cookie consent display to staff UI This commit adds the display of the cookie consent bar and modal to the staff interface: - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate TEST PLAN --------- Note: As part of this test plan you will be required to remove a value from your browser's local storage store, we use this for storing a browser's cookie consent choice. To remove this value when instructed to do so, do the following: Chrome / Edge ------ - Press F12 - Click the "Application" tab - On the left, expand the "Local Storage" section - Find the entry that corresponds with the URL of your Koha and click on it - Find the entry in the list with a "Key" of "cookieConsent" - Click on it and press "Delete" on your keyboard Firefox ------- - Press F12 - Click the "Storage" tab - On the left, expand the "Local Storage" section - Find the entry that corresponds with the URL of your Koha and click on it - Find the entry in the list with a "Key" of "cookieConsent" - Click on it and press "Delete" on your keyboard 1. Ensure you have a tab open on the intranet view and one open on the OPAC view 2. Search for "consent" in the sysprefs => TEST: Observe there are 4 new sysprefs: - "ConsentJS" - "CookieConsent" - "CookieConsentBar" - "CookieConsentPopup" 3. Change the value for the "CookieConsent" syspref to "Require" 4. Refresh the intranet page => TEST: In the intranet view, observe that a cookie consent bar appears at the bottom of the page with just a single "Accept all cookies" button 5. Refresh the OPAC page => TEST: In the OPAC view, observe that a cookie consent bar appears at the bottom of the page with just a single "Accept all cookies" button 6. Add some text to the "CookieConsentBar" syspref, this can be HTML if you wish 7. Refresh the intranet page => TEST: In the intranet view, observe that the cookie consent bar appears at the bottom of the page containing the text you specified 8. Refresh the OPAC page => TEST: In the OPAC view, observe that the cookie consent bar appears at the bottom of the page containing the text you specified 9. Add some text to the "CookieConsentPop" syspref, this can be HTML if you wish 10. Click the "ConsentJS" syspref input 11. Click the "Add new code" link 12. Enter a name and description, and check both checkboxes 13. Click the "Click to expand" link 14. Enter the following Javascript: (function() { console.log('Hello from my test'); })() 15. Repeat the process of entering new code by clicking "Add new code" 3 times, ensure that the message being logged is different every time, this will enable you to verify that each consented bit of code is running 16. Click "Save" 17. Refresh the intranet page => TEST: In the intranet view, observe that the cookie consent bar appears at the bottom of the page containing 3 buttons 18. Refresh the OPAC page => TEST: In the OPAC view, observe that the cookie consent bar appears at the bottom of the page containing 3 buttons 19. Click the "More information" button => TEST: Observe that a cookie consent popup is displayed listing the codes you added in the syspref, displaying the name,description and checkbox for each, allowing a code to be selected 20.- Select a code => TEST: Observe that "Accept selected non-essential cookies" is enabled 21. Deselect all codes => TEST: Observe that "Accept selected non-essential cookies" is disabled 22. Open the developer tools for your browser (usually F12) and ensure you are viewing the Javascript console 23. Click accept all cookies => TEST: In the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 24. Navigate to any other pages in the OPAC => TEST: On each page load, in the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 25. Remove the cookieConsent local storage (as detailed at the start) 26. Switch to the intranet view 27. Repeat steps 19-25 in the intranet view 28. Refresh the page 29. Click the "Accept all cookies" button on the cookie bar => TEST: In the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 30. Remove the cookieConsent local storage (as detailed at the start) 31. Refresh the page 32. Click the "Accept only essential cookies" button on the cookie bar => TEST: In the Javascript console, observe that none of the messages in the codes you added to the ConsentJS syspref are displayed 33. Remove the cookieConsent local storage (as detailed at the start) 34. Refresh the page 35. Click the "More information" button on the cookie bar 36. Select two of the codes you defined in the ConsentJS syspref 37. Click the "Accept selected non-essential cookies" button => TEST: In the Javascript console, observe that only the messages from the selected codes you added to the ConsentJS syspref are displayed 38. Repeat steps 28-37 on the OPAC view What about rejecting them? :) (In reply to Jonathan Druart from comment #7) > What about rejecting them? :) Ok, it's the "Accept only essential cookies" button. I've just realised I've left a chunk off the test plan, so I'm setting this back to Assigned until I've added the missing bits TEST PLAN --------- Note: As part of this test plan you will be required to remove a value from your browser's local storage store, we use this for storing a browser's cookie consent choice. To remove this value when instructed to do so, do the following: Chrome / Edge ------ - Press F12 - Click the "Application" tab - On the left, expand the "Local Storage" section - Find the entry that corresponds with the URL of your Koha and click on it - Find the entry in the list with a "Key" of "cookieConsent" - Click on it and press "Delete" on your keyboard Firefox ------- - Press F12 - Click the "Storage" tab - On the left, expand the "Local Storage" section - Find the entry that corresponds with the URL of your Koha and click on it - Find the entry in the list with a "Key" of "cookieConsent" - Click on it and press "Delete" on your keyboard 1. Ensure you have a tab open on the intranet view and one open on the OPAC view, ensure you are logged in on both 2. Search for "consent" in the sysprefs => TEST: Observe there are 4 new sysprefs: - "ConsentJS" - "CookieConsent" - "CookieConsentBar" - "CookieConsentPopup" 3. Change the value for the "CookieConsent" syspref to "Require" 4. Refresh the intranet page => TEST: In the intranet view, observe that a cookie consent bar appears at the bottom of the page with just a single "Accept all cookies" button 5. Refresh the OPAC page => TEST: In the OPAC view, observe that a cookie consent bar appears at the bottom of the page with just a single "Accept all cookies" button 6. Add some text to the "CookieConsentBar" syspref, this can be HTML if you wish 7. Refresh the intranet page => TEST: In the intranet view, observe that the cookie consent bar appears at the bottom of the page containing the text you specified 8. Refresh the OPAC page => TEST: In the OPAC view, observe that the cookie consent bar appears at the bottom of the page containing the text you specified 9. Add some text to the "CookieConsentPop" syspref, this can be HTML if you wish 10. Click the "ConsentJS" syspref input 11. Click the "Add new code" link 12. Enter a name and description, and check both checkboxes 13. Click the "Click to expand" link 14. Enter the following Javascript: (function() { console.log('Hello from my test'); })() 15. Repeat the process of entering new code by clicking "Add new code" 3 times, ensure that the message being logged is different every time, this will enable you to verify that each consented bit of code is running 16. Click "Save" 17. Refresh the intranet page => TEST: In the intranet view, observe that the cookie consent bar appears at the bottom of the page containing 3 buttons 18. Refresh the OPAC page => TEST: In the OPAC view, observe that the cookie consent bar appears at the bottom of the page containing 3 buttons 19. Click the "More information" button => TEST: Observe that a cookie consent popup is displayed listing the codes you added in the syspref, displaying the name,description and checkbox for each, allowing a code to be selected 20.- Select a code => TEST: Observe that "Accept selected non-essential cookies" is enabled 21. Deselect all codes => TEST: Observe that "Accept selected non-essential cookies" is disabled 22. Open the developer tools for your browser (usually F12) and ensure you are viewing the Javascript console 23. Click accept all cookies => TEST: In the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 24. Navigate to any other pages in the OPAC => TEST: On each page load, in the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 25. Remove the cookieConsent local storage (as detailed at the start) 26. Switch to the intranet view 27. Repeat steps 19-25 in the intranet view 28. Refresh the page 29. Click the "Accept all cookies" button on the cookie bar => TEST: In the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 30. Remove the cookieConsent local storage (as detailed at the start) 31. Refresh the page 32. Click the "Accept only essential cookies" button on the cookie bar => TEST: In the Javascript console, observe that none of the messages in the codes you added to the ConsentJS syspref are displayed 33. Remove the cookieConsent local storage (as detailed at the start) 34. Refresh the page 35. Click the "More information" button on the cookie bar 36. Select two of the codes you defined in the ConsentJS syspref 37. Click the "Accept selected non-essential cookies" button => TEST: In the Javascript console, observe that only the messages from the selected codes you added to the ConsentJS syspref are displayed 38. Repeat steps 28-37 on the OPAC view 39. In the OPAC view, go to the "Your account" page => TEST: Observe that the "your consents" option is available 40. Click on "your consents" => TEST: Observe that a "Cookie consents" section is displayed, with a button 41. Click the "View your cookie consents" button => TEST: Observe that the "Cookie consent" popup is displayed allowing you to modify your cookie consents 42. Consent to whichever cookies you wish 43. Log out of the OPAC => Observe that a small "Your cookies" button is displayed in the bottom right of the screen 44. Click the "Your cookies" button => TEST: Observe that the "Cookie consent" popup is displayed allowing you to modify your cookie consents Created attachment 115756 [details] [review] Bug 27378: Move "Your cookies" to existing bar The new "Your cookies" button that appeared at the bottom right when an unauthenticated user had made their cookie consent selections wasn't ideal. It has now been moved to the top bar, next to "Lists", this feels like a much more sensible place for it. TEST PLAN --------- Note: As part of this test plan you will be required to remove a value from your browser's local storage store, we use this for storing a browser's cookie consent choice. To remove this value when instructed to do so, do the following: Chrome / Edge ------ - Press F12 - Click the "Application" tab - On the left, expand the "Local Storage" section - Find the entry that corresponds with the URL of your Koha and click on it - Find the entry in the list with a "Key" of "cookieConsent" - Click on it and press "Delete" on your keyboard Firefox ------- - Press F12 - Click the "Storage" tab - On the left, expand the "Local Storage" section - Find the entry that corresponds with the URL of your Koha and click on it - Find the entry in the list with a "Key" of "cookieConsent" - Click on it and press "Delete" on your keyboard 1. Ensure you have a tab open on the intranet view and one open on the OPAC view, ensure you are logged in on both 2. Search for "consent" in the sysprefs => TEST: Observe there are 4 new sysprefs: - "ConsentJS" - "CookieConsent" - "CookieConsentBar" - "CookieConsentPopup" 3. Change the value for the "CookieConsent" syspref to "Require" 4. Refresh the intranet page => TEST: In the intranet view, observe that a cookie consent bar appears at the bottom of the page with just a single "Accept all cookies" button 5. Refresh the OPAC page => TEST: In the OPAC view, observe that a cookie consent bar appears at the bottom of the page with just a single "Accept all cookies" button 6. Add some text to the "CookieConsentBar" syspref, this can be HTML if you wish 7. Refresh the intranet page => TEST: In the intranet view, observe that the cookie consent bar appears at the bottom of the page containing the text you specified 8. Refresh the OPAC page => TEST: In the OPAC view, observe that the cookie consent bar appears at the bottom of the page containing the text you specified 9. Add some text to the "CookieConsentPop" syspref, this can be HTML if you wish 10. Click the "ConsentJS" syspref input 11. Click the "Add new code" link 12. Enter a name and description, and check both checkboxes 13. Click the "Click to expand" link 14. Enter the following Javascript: (function() { console.log('Hello from my test'); })() 15. Repeat the process of entering new code by clicking "Add new code" 3 times, ensure that the message being logged is different every time, this will enable you to verify that each consented bit of code is running 16. Click "Save" 17. Refresh the intranet page => TEST: In the intranet view, observe that the cookie consent bar appears at the bottom of the page containing 3 buttons 18. Refresh the OPAC page => TEST: In the OPAC view, observe that the cookie consent bar appears at the bottom of the page containing 3 buttons 19. Click the "More information" button => TEST: Observe that a cookie consent popup is displayed listing the codes you added in the syspref, displaying the name,description and checkbox for each, allowing a code to be selected 20.- Select a code => TEST: Observe that "Accept selected non-essential cookies" is enabled 21. Deselect all codes => TEST: Observe that "Accept selected non-essential cookies" is disabled 22. Open the developer tools for your browser (usually F12) and ensure you are viewing the Javascript console 23. Click accept all cookies => TEST: In the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 24. Navigate to any other pages in the OPAC => TEST: On each page load, in the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 25. Remove the cookieConsent local storage (as detailed at the start) 26. Switch to the intranet view 27. Repeat steps 19-25 in the intranet view 28. Refresh the page 29. Click the "Accept all cookies" button on the cookie bar => TEST: In the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 30. Remove the cookieConsent local storage (as detailed at the start) 31. Refresh the page 32. Click the "Accept only essential cookies" button on the cookie bar => TEST: In the Javascript console, observe that none of the messages in the codes you added to the ConsentJS syspref are displayed 33. Remove the cookieConsent local storage (as detailed at the start) 34. Refresh the page 35. Click the "More information" button on the cookie bar 36. Select two of the codes you defined in the ConsentJS syspref 37. Click the "Accept selected non-essential cookies" button => TEST: In the Javascript console, observe that only the messages from the selected codes you added to the ConsentJS syspref are displayed 38. Repeat steps 28-37 on the OPAC view 39. In the OPAC view, go to the "Your account" page => TEST: Observe that the "your consents" option is available 40. Click on "your consents" => TEST: Observe that a "Cookie consents" section is displayed, with a button 41. Click the "View your cookie consents" button => TEST: Observe that the "Cookie consent" popup is displayed allowing you to modify your cookie consents 42. Consent to whichever cookies you wish 43. Log out of the OPAC => Observe that a "Your cookies" button is displayed in the top bar next to "Links" 44. Click the "Your cookies" button => TEST: Observe that the "Cookie consent" popup is displayed allowing you to modify your cookie consents Created attachment 116397 [details] [review] Bug 27378: Add new 'modaljs' syspref type This commit adds a new 'modaljs' syspref type. This is similar to the existing 'modalselect' syspref type but instead of using a file to create a list of selectable options which are displayed in the modal, it assumes that anything can happen within the modal driven by JS, and whatever happens is going to return a string, that will be saved as the syspref value. In our case, the string will be all the details of the “chunks” concatenated into a string Created attachment 116398 [details] [review] Bug 27378: Add sysprefs This commit adds 4 new sysprefs: - CookieConsent - the master on/off for this functionality - ConsentJS - The configuration for JS code that requires consent prior to running. - CookieConsentBar: Allows the admin to specify the HTML that will be displayed in the consent bar that appears at the bottom of the page - CookieConsentPopup: Allows the admin to specify the HTML that will be displayed in the cookie consent popup Created attachment 116399 [details] [review] Bug 27378: Add JS to power modaljs This commit adds the Javascript that provides the functionality within the consentJS modaljs modal. It provides the ability to display the current state of any consentJS values and to amend them, as well as add new ones. There is also some refactoring of the existing modalselect functions to allow re-use of existing code between modalselect & modaljs. This refactoring has been minimal and consists of abstracting functionality into functions to allow more wide use. Styles for the consentJS UI were also added. Created attachment 116400 [details] [review] Bug 27378: Add cookie consent display to OPAC This commit adds the display of the cookie consent bar and modal to the OPAC. - Adds a new JSConsents template plugin that enables a template to be populated with the contents of the ConsentJS syspref in a prepared, usable form - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate - Adds the ability for both authenticated and unauthenticated users to view and modify their consents either via "your consents" or a new unobtrusive "Your cookies" button in the bottom right of the screen. - Adds unit test for JSConsents.pm Created attachment 116401 [details] [review] Bug 27378: Add cookie consent display to staff UI This commit adds the display of the cookie consent bar and modal to the staff interface: - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate Created attachment 116402 [details] [review] Bug 27378: Move "Your cookies" to existing bar The new "Your cookies" button that appeared at the bottom right when an unauthenticated user had made their cookie consent selections wasn't ideal. It has now been moved to the top bar, next to "Lists", this feels like a much more sensible place for it. Created attachment 116403 [details] [review] Bug 27378: Delete cookies when consent removed We have provided the ability for a user to remove previously granted consent, but we were not removing the cookie associated with that consent. This was a complete oversight on my part. I've introduced an additional bit of metadata for each "consent" defined in the ConsentJS syspref, this allows the admin defining a "consent" to specify a string (which is treated as a regex) that allows us to identify a cookie name associated with that consent. So, for example, if Google Analytics was being added, an identifying string might be '_ga'. This allows us to subsequently remove a cookie that a previously granted consent has set. This commit also adds some missing 'html' filters in koha-tmpl/intranet-tmpl/prog/en/includes/intranet-bottom.inc and koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc REVISED TEST PLAN ----------------- Note: As part of this test plan you will be required to remove a value from your browser's local storage store, we use this for storing a browser's cookie consent choice. To remove this value when instructed to do so, do the following: Chrome / Edge ------ - Press F12 - Click the "Application" tab - On the left, expand the "Local Storage" section - Find the entry that corresponds with the URL of your Koha and click on it - Find the entry in the list with a "Key" of "cookieConsent" - Click on it and press "Delete" on your keyboard Firefox ------- - Press F12 - Click the "Storage" tab - On the left, expand the "Local Storage" section - Find the entry that corresponds with the URL of your Koha and click on it - Find the entry in the list with a "Key" of "cookieConsent" - Click on it and press "Delete" on your keyboard Note: Also you will be required to inspect cookies set in your browser. When instructed to do so, do the following: Chrome / Edge ------ - Press F12 - Click the "Application" tab - On the left, expand the "Cookies" section - Find the entry that corresponds with the URL of your Koha and click on it - View the list of cookies Firefox ------- - Press F12 - Click the "Storage" tab - On the left, expand the "Cookies" section - Find the entry that corresponds with the URL of your Koha and click on it - View the list of cookies 1. Ensure you have a tab open on the intranet view and one open on the OPAC view, ensure you are logged in on both 2. Search for "consent" in the sysprefs => TEST: Observe there are 4 new sysprefs: - "ConsentJS" - "CookieConsent" - "CookieConsentBar" - "CookieConsentPopup" 3. Change the value for the "CookieConsent" syspref to "Require" 4. Refresh the intranet page => TEST: In the intranet view, observe that a cookie consent bar appears at the bottom of the page with just a single "Accept all cookies" button 5. Refresh the OPAC page => TEST: In the OPAC view, observe that a cookie consent bar appears at the bottom of the page with just a single "Accept all cookies" button 6. Add some text to the "CookieConsentBar" syspref, this can be HTML if you wish 7. Refresh the intranet page => TEST: In the intranet view, observe that the cookie consent bar appears at the bottom of the page containing the text you specified 8. Refresh the OPAC page => TEST: In the OPAC view, observe that the cookie consent bar appears at the bottom of the page containing the text you specified 9. Add some text to the "CookieConsentPop" syspref, this can be HTML if you wish 10. Click the "ConsentJS" syspref input 11. Click the "Add new code" link 12. Enter a name and description, and check both checkboxes. For "String used to identify cookie name", enter "test1", this enables us to delete the cookie when consent is withdrawn. 13. Click the "Click to expand" link 14. Enter the following Javascript: (function() { console.log('Hello from test1'); document.cookie = 'test1=testing'; })() 15. Repeat steps 11 to 14 twice more, substituting "test1" for "test2" & "test3" 16. Click "Save" 17. Refresh the intranet page => TEST: In the intranet view, observe that the cookie consent bar appears at the bottom of the page containing 3 buttons 18. Refresh the OPAC page => TEST: In the OPAC view, observe that the cookie consent bar appears at the bottom of the page containing 3 buttons 19. Click the "More information" button => TEST: Observe that a cookie consent popup is displayed listing the codes you added in the syspref, displaying the name,description and checkbox for each, allowing a code to be selected 20.- Select a code => TEST: Observe that "Accept selected non-essential cookies" is enabled 21. Deselect all codes => TEST: Observe that "Accept selected non-essential cookies" is disabled 22. Open the developer tools for your browser (usually F12) and ensure you are viewing the Javascript console 23. Click accept all cookies => TEST: In the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed => TEST: In the cookie list (as detailed at the top of the test plan) observe that the cookies corresponding with the consents granted have been set. 24. Navigate to any other pages in the OPAC => TEST: On each page load, in the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 25. Remove the cookieConsent local storage (as detailed at the start) 26. Switch to the intranet view 27. Repeat steps 19-25 in the intranet view 28. Refresh the page 29. Click the "Accept all cookies" button on the cookie bar => TEST: In the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 30. Remove the cookieConsent local storage (as detailed at the start) 31. Refresh the page 32. Click the "Accept only essential cookies" button on the cookie bar => TEST: In the Javascript console, observe that none of the messages in the codes you added to the ConsentJS syspref are displayed 33. Remove the cookieConsent local storage (as detailed at the start) 34. Refresh the page 35. Click the "More information" button on the cookie bar 36. Select two of the codes you defined in the ConsentJS syspref 37. Click the "Accept selected non-essential cookies" button => TEST: In the Javascript console, observe that only the messages from the selected codes you added to the ConsentJS syspref are displayed 38. Repeat steps 28-37 on the OPAC view 39. In the OPAC view, go to the "Your account" page => TEST: Observe that the "your consents" option is available 40. Click on "your consents" => TEST: Observe that a "Cookie consents" section is displayed, with a button 41. Click the "View your cookie consents" button => TEST: Observe that the "Cookie consent" popup is displayed allowing you to modify your cookie consents 42. Remove consent from at least one cookie, click Save => TEST: In the cookie list in your browser (as detailed at the top of the test plan), observe that any cookies you removed consent from have either been removed or have no value. 43. Log out of the OPAC => Observe that a "Your cookies" button is displayed in the top bar next to "Links" 44. Click the "Your cookies" button => TEST: Observe that the "Cookie consent" popup is displayed allowing you to modify your cookie consents Created attachment 116416 [details] [review] Bug 27378: Add new 'modaljs' syspref type This commit adds a new 'modaljs' syspref type. This is similar to the existing 'modalselect' syspref type but instead of using a file to create a list of selectable options which are displayed in the modal, it assumes that anything can happen within the modal driven by JS, and whatever happens is going to return a string, that will be saved as the syspref value. In our case, the string will be all the details of the “chunks” concatenated into a string Created attachment 116417 [details] [review] Bug 27378: Add sysprefs This commit adds 4 new sysprefs: - CookieConsent - the master on/off for this functionality - ConsentJS - The configuration for JS code that requires consent prior to running. - CookieConsentBar: Allows the admin to specify the HTML that will be displayed in the consent bar that appears at the bottom of the page - CookieConsentPopup: Allows the admin to specify the HTML that will be displayed in the cookie consent popup Created attachment 116418 [details] [review] Bug 27378: Add JS to power modaljs This commit adds the Javascript that provides the functionality within the consentJS modaljs modal. It provides the ability to display the current state of any consentJS values and to amend them, as well as add new ones. There is also some refactoring of the existing modalselect functions to allow re-use of existing code between modalselect & modaljs. This refactoring has been minimal and consists of abstracting functionality into functions to allow more wide use. Styles for the consentJS UI were also added. Created attachment 116419 [details] [review] Bug 27378: Add cookie consent display to OPAC This commit adds the display of the cookie consent bar and modal to the OPAC. - Adds a new JSConsents template plugin that enables a template to be populated with the contents of the ConsentJS syspref in a prepared, usable form - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate - Adds the ability for both authenticated and unauthenticated users to view and modify their consents either via "your consents" or a new unobtrusive "Your cookies" button in the bottom right of the screen. - Adds unit test for JSConsents.pm Created attachment 116420 [details] [review] Bug 27378: Add cookie consent display to staff UI This commit adds the display of the cookie consent bar and modal to the staff interface: - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate Created attachment 116421 [details] [review] Bug 27378: Move "Your cookies" to existing bar The new "Your cookies" button that appeared at the bottom right when an unauthenticated user had made their cookie consent selections wasn't ideal. It has now been moved to the top bar, next to "Lists", this feels like a much more sensible place for it. Created attachment 116422 [details] [review] Bug 27378: Delete cookies when consent removed We have provided the ability for a user to remove previously granted consent, but we were not removing the cookie associated with that consent. This was a complete oversight on my part. I've introduced an additional bit of metadata for each "consent" defined in the ConsentJS syspref, this allows the admin defining a "consent" to specify a string (which is treated as a regex) that allows us to identify a cookie name associated with that consent. So, for example, if Google Analytics was being added, an identifying string might be '_ga'. This allows us to subsequently remove a cookie that a previously granted consent has set. This commit also adds some missing 'html' filters in koha-tmpl/intranet-tmpl/prog/en/includes/intranet-bottom.inc and koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc Created attachment 116423 [details] [review] Bug 27378: Add cookie domain and path A subtlety I missed was that some tracking services, such as Google Analytics, specify a cookie domain and path that differ from the default. E.g. on a site with a domain of demostaff.koha-ptfs.co.uk, the GA cookie will have a domain of '.koha-ptfs.co.uk' and a path of '/', even though the cookie may have been set at a different path. Both of these things makes sense, but of course unless we also specify both of those things when we try to delete a previously set cookie, we cannot. Therefore, I have added two more bits of metadata to each "consent", Cookie Domain and Cookie Path. It is necessary for an admin creating a "consent" entry to know and specify these values. They can be established by looking a cookie set by the service being configured. This adds more complexity to setting up a consent, but we cannot remove previously set cookies without it. REVISED TEST PLAN ----------------- Note: As part of this test plan you will be required to remove a value from your browser's local storage store, we use this for storing a browser's cookie consent choice. To remove this value when instructed to do so, do the following: Chrome / Edge ------ - Press F12 - Click the "Application" tab - On the left, expand the "Local Storage" section - Find the entry that corresponds with the URL of your Koha and click on it - Find the entry in the list with a "Key" of "cookieConsent" - Click on it and press "Delete" on your keyboard Firefox ------- - Press F12 - Click the "Storage" tab - On the left, expand the "Local Storage" section - Find the entry that corresponds with the URL of your Koha and click on it - Find the entry in the list with a "Key" of "cookieConsent" - Click on it and press "Delete" on your keyboard Note: Also you will be required to inspect cookies set in your browser. When instructed to do so, do the following: Chrome / Edge ------ - Press F12 - Click the "Application" tab - On the left, expand the "Cookies" section - Find the entry that corresponds with the URL of your Koha and click on it - View the list of cookies Firefox ------- - Press F12 - Click the "Storage" tab - On the left, expand the "Cookies" section - Find the entry that corresponds with the URL of your Koha and click on it - View the list of cookies 1. Ensure you have a tab open on the intranet view and one open on the OPAC view, ensure you are logged in on both 2. Search for "consent" in the sysprefs => TEST: Observe there are 4 new sysprefs: - "ConsentJS" - "CookieConsent" - "CookieConsentBar" - "CookieConsentPopup" 3. Change the value for the "CookieConsent" syspref to "Require" 4. Refresh the intranet page => TEST: In the intranet view, observe that a cookie consent bar appears at the bottom of the page with just a single "Accept all cookies" button 5. Refresh the OPAC page => TEST: In the OPAC view, observe that a cookie consent bar appears at the bottom of the page with just a single "Accept all cookies" button 6. Add some text to the "CookieConsentBar" syspref, this can be HTML if you wish 7. Refresh the intranet page => TEST: In the intranet view, observe that the cookie consent bar appears at the bottom of the page containing the text you specified 8. Refresh the OPAC page => TEST: In the OPAC view, observe that the cookie consent bar appears at the bottom of the page containing the text you specified 9. Add some text to the "CookieConsentPop" syspref, this can be HTML if you wish 10. Click the "ConsentJS" syspref input 11. Click the "Add new code" link 12. Enter a name and description, and check both checkboxes. - For "String used to identify cookie name", enter "test1", this enables us to delete the cookie when consent is withdrawn. - For "Cookie domain" enter the domain of your Koha. - For "Cookie path" enter "/" 13. Click the "Click to expand" link 14. Enter the following Javascript: (function() { console.log('Hello from test1'); document.cookie = 'test1=testing; domain=<the_domain_of_your_koha>; path=/'; })() 15. Repeat steps 11 to 14 twice more, substituting "test1" for "test2" & "test3" 16. Click "Save" 17. Refresh the intranet page => TEST: In the intranet view, observe that the cookie consent bar appears at the bottom of the page containing 3 buttons 18. Refresh the OPAC page => TEST: In the OPAC view, observe that the cookie consent bar appears at the bottom of the page containing 3 buttons 19. Click the "More information" button => TEST: Observe that a cookie consent popup is displayed listing the codes you added in the syspref, displaying the name,description and checkbox for each, allowing a code to be selected 20.- Select a code => TEST: Observe that "Accept selected non-essential cookies" is enabled 21. Deselect all codes => TEST: Observe that "Accept selected non-essential cookies" is disabled 22. Open the developer tools for your browser (usually F12) and ensure you are viewing the Javascript console 23. Click accept all cookies => TEST: In the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed => TEST: In the cookie list (as detailed at the top of the test plan) observe that the cookies corresponding with the consents granted have been set. 24. Navigate to any other pages in the OPAC => TEST: On each page load, in the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 25. Remove the cookieConsent local storage (as detailed at the start) 26. Switch to the intranet view 27. Repeat steps 19-25 in the intranet view 28. Refresh the page 29. Click the "Accept all cookies" button on the cookie bar => TEST: In the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 30. Remove the cookieConsent local storage (as detailed at the start) 31. Refresh the page 32. Click the "Accept only essential cookies" button on the cookie bar => TEST: In the Javascript console, observe that none of the messages in the codes you added to the ConsentJS syspref are displayed 33. Remove the cookieConsent local storage (as detailed at the start) 34. Refresh the page 35. Click the "More information" button on the cookie bar 36. Select two of the codes you defined in the ConsentJS syspref 37. Click the "Accept selected non-essential cookies" button => TEST: In the Javascript console, observe that only the messages from the selected codes you added to the ConsentJS syspref are displayed 38. Repeat steps 28-37 on the OPAC view 39. In the OPAC view, go to the "Your account" page => TEST: Observe that the "your consents" option is available 40. Click on "your consents" => TEST: Observe that a "Cookie consents" section is displayed, with a button 41. Click the "View your cookie consents" button => TEST: Observe that the "Cookie consent" popup is displayed allowing you to modify your cookie consents 42. Remove consent from at least one cookie, click Save => TEST: In the cookie list in your browser (as detailed at the top of the test plan), observe that any cookies you removed consent from have either been removed or have no value. 43. Log out of the OPAC => Observe that a "Your cookies" button is displayed in the top bar next to "Links" 44. Click the "Your cookies" button => TEST: Observe that the "Cookie consent" popup is displayed allowing you to modify your cookie consents Created attachment 116978 [details] [review] Bug 27378: Add new 'modaljs' syspref type This commit adds a new 'modaljs' syspref type. This is similar to the existing 'modalselect' syspref type but instead of using a file to create a list of selectable options which are displayed in the modal, it assumes that anything can happen within the modal driven by JS, and whatever happens is going to return a string, that will be saved as the syspref value. In our case, the string will be all the details of the “chunks” concatenated into a string Created attachment 116979 [details] [review] Bug 27378: Add sysprefs This commit adds 4 new sysprefs: - CookieConsent - the master on/off for this functionality - ConsentJS - The configuration for JS code that requires consent prior to running. - CookieConsentBar: Allows the admin to specify the HTML that will be displayed in the consent bar that appears at the bottom of the page - CookieConsentPopup: Allows the admin to specify the HTML that will be displayed in the cookie consent popup Created attachment 116980 [details] [review] Bug 27378: Add JS to power modaljs This commit adds the Javascript that provides the functionality within the consentJS modaljs modal. It provides the ability to display the current state of any consentJS values and to amend them, as well as add new ones. There is also some refactoring of the existing modalselect functions to allow re-use of existing code between modalselect & modaljs. This refactoring has been minimal and consists of abstracting functionality into functions to allow more wide use. Styles for the consentJS UI were also added. Created attachment 116981 [details] [review] Bug 27378: Add cookie consent display to OPAC This commit adds the display of the cookie consent bar and modal to the OPAC. - Adds a new JSConsents template plugin that enables a template to be populated with the contents of the ConsentJS syspref in a prepared, usable form - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate - Adds the ability for both authenticated and unauthenticated users to view and modify their consents either via "your consents" or a new unobtrusive "Your cookies" button in the bottom right of the screen. - Adds unit test for JSConsents.pm Created attachment 116982 [details] [review] Bug 27378: Add cookie consent display to staff UI This commit adds the display of the cookie consent bar and modal to the staff interface: - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate Created attachment 116983 [details] [review] Bug 27378: Move "Your cookies" to existing bar The new "Your cookies" button that appeared at the bottom right when an unauthenticated user had made their cookie consent selections wasn't ideal. It has now been moved to the top bar, next to "Lists", this feels like a much more sensible place for it. Created attachment 116984 [details] [review] Bug 27378: Delete cookies when consent removed We have provided the ability for a user to remove previously granted consent, but we were not removing the cookie associated with that consent. This was a complete oversight on my part. I've introduced an additional bit of metadata for each "consent" defined in the ConsentJS syspref, this allows the admin defining a "consent" to specify a string (which is treated as a regex) that allows us to identify a cookie name associated with that consent. So, for example, if Google Analytics was being added, an identifying string might be '_ga'. This allows us to subsequently remove a cookie that a previously granted consent has set. This commit also adds some missing 'html' filters in koha-tmpl/intranet-tmpl/prog/en/includes/intranet-bottom.inc and koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc Created attachment 116985 [details] [review] Bug 27378: Add cookie domain and path A subtlety I missed was that some tracking services, such as Google Analytics, specify a cookie domain and path that differ from the default. E.g. on a site with a domain of demostaff.koha-ptfs.co.uk, the GA cookie will have a domain of '.koha-ptfs.co.uk' and a path of '/', even though the cookie may have been set at a different path. Both of these things makes sense, but of course unless we also specify both of those things when we try to delete a previously set cookie, we cannot. Therefore, I have added two more bits of metadata to each "consent", Cookie Domain and Cookie Path. It is necessary for an admin creating a "consent" entry to know and specify these values. They can be established by looking a cookie set by the service being configured. This adds more complexity to setting up a consent, but we cannot remove previously set cookies without it. Created attachment 116986 [details] [review] Bug 27378: Fix typo on cookie deletion expiry This commit fixes a typo in the expiry date of the "delete cookie" setting. It was causing the cookie to be set to an empty value, rather than being removed from the cookie store. Created attachment 121728 [details] [review] Bug 27378: Add new 'modaljs' syspref type This commit adds a new 'modaljs' syspref type. This is similar to the existing 'modalselect' syspref type but instead of using a file to create a list of selectable options which are displayed in the modal, it assumes that anything can happen within the modal driven by JS, and whatever happens is going to return a string, that will be saved as the syspref value. In our case, the string will be all the details of the “chunks” concatenated into a string Created attachment 121729 [details] [review] Bug 27378: Add sysprefs This commit adds 4 new sysprefs: - CookieConsent - the master on/off for this functionality - ConsentJS - The configuration for JS code that requires consent prior to running. - CookieConsentBar: Allows the admin to specify the HTML that will be displayed in the consent bar that appears at the bottom of the page - CookieConsentPopup: Allows the admin to specify the HTML that will be displayed in the cookie consent popup Created attachment 121730 [details] [review] Bug 27378: Add JS to power modaljs This commit adds the Javascript that provides the functionality within the consentJS modaljs modal. It provides the ability to display the current state of any consentJS values and to amend them, as well as add new ones. There is also some refactoring of the existing modalselect functions to allow re-use of existing code between modalselect & modaljs. This refactoring has been minimal and consists of abstracting functionality into functions to allow more wide use. Styles for the consentJS UI were also added. Created attachment 121731 [details] [review] Bug 27378: Add cookie consent display to OPAC This commit adds the display of the cookie consent bar and modal to the OPAC. - Adds a new JSConsents template plugin that enables a template to be populated with the contents of the ConsentJS syspref in a prepared, usable form - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate - Adds the ability for both authenticated and unauthenticated users to view and modify their consents either via "your consents" or a new unobtrusive "Your cookies" button in the bottom right of the screen. - Adds unit test for JSConsents.pm Created attachment 121732 [details] [review] Bug 27378: Add cookie consent display to staff UI This commit adds the display of the cookie consent bar and modal to the staff interface: - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate Created attachment 121733 [details] [review] Bug 27378: Move "Your cookies" to existing bar The new "Your cookies" button that appeared at the bottom right when an unauthenticated user had made their cookie consent selections wasn't ideal. It has now been moved to the top bar, next to "Lists", this feels like a much more sensible place for it. Created attachment 121734 [details] [review] Bug 27378: Delete cookies when consent removed We have provided the ability for a user to remove previously granted consent, but we were not removing the cookie associated with that consent. This was a complete oversight on my part. I've introduced an additional bit of metadata for each "consent" defined in the ConsentJS syspref, this allows the admin defining a "consent" to specify a string (which is treated as a regex) that allows us to identify a cookie name associated with that consent. So, for example, if Google Analytics was being added, an identifying string might be '_ga'. This allows us to subsequently remove a cookie that a previously granted consent has set. This commit also adds some missing 'html' filters in koha-tmpl/intranet-tmpl/prog/en/includes/intranet-bottom.inc and koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc Created attachment 121735 [details] [review] Bug 27378: Add cookie domain and path A subtlety I missed was that some tracking services, such as Google Analytics, specify a cookie domain and path that differ from the default. E.g. on a site with a domain of demostaff.koha-ptfs.co.uk, the GA cookie will have a domain of '.koha-ptfs.co.uk' and a path of '/', even though the cookie may have been set at a different path. Both of these things makes sense, but of course unless we also specify both of those things when we try to delete a previously set cookie, we cannot. Therefore, I have added two more bits of metadata to each "consent", Cookie Domain and Cookie Path. It is necessary for an admin creating a "consent" entry to know and specify these values. They can be established by looking a cookie set by the service being configured. This adds more complexity to setting up a consent, but we cannot remove previously set cookies without it. Created attachment 121995 [details] [review] Bug 27378: Add new 'modaljs' syspref type This commit adds a new 'modaljs' syspref type. This is similar to the existing 'modalselect' syspref type but instead of using a file to create a list of selectable options which are displayed in the modal, it assumes that anything can happen within the modal driven by JS, and whatever happens is going to return a string, that will be saved as the syspref value. In our case, the string will be all the details of the “chunks” concatenated into a string Created attachment 121996 [details] [review] Bug 27378: Add sysprefs This commit adds 4 new sysprefs: - CookieConsent - the master on/off for this functionality - ConsentJS - The configuration for JS code that requires consent prior to running. - CookieConsentBar: Allows the admin to specify the HTML that will be displayed in the consent bar that appears at the bottom of the page - CookieConsentPopup: Allows the admin to specify the HTML that will be displayed in the cookie consent popup Created attachment 121997 [details] [review] Bug 27378: Add JS to power modaljs This commit adds the Javascript that provides the functionality within the consentJS modaljs modal. It provides the ability to display the current state of any consentJS values and to amend them, as well as add new ones. There is also some refactoring of the existing modalselect functions to allow re-use of existing code between modalselect & modaljs. This refactoring has been minimal and consists of abstracting functionality into functions to allow more wide use. Styles for the consentJS UI were also added. Created attachment 121998 [details] [review] Bug 27378: Add cookie consent display to OPAC This commit adds the display of the cookie consent bar and modal to the OPAC. - Adds a new JSConsents template plugin that enables a template to be populated with the contents of the ConsentJS syspref in a prepared, usable form - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate - Adds the ability for both authenticated and unauthenticated users to view and modify their consents either via "your consents" or a new unobtrusive "Your cookies" button in the bottom right of the screen. - Adds unit test for JSConsents.pm Created attachment 121999 [details] [review] Bug 27378: Add cookie consent display to staff UI This commit adds the display of the cookie consent bar and modal to the staff interface: - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate Created attachment 122000 [details] [review] Bug 27378: Move "Your cookies" to existing bar The new "Your cookies" button that appeared at the bottom right when an unauthenticated user had made their cookie consent selections wasn't ideal. It has now been moved to the top bar, next to "Lists", this feels like a much more sensible place for it. Created attachment 122001 [details] [review] Bug 27378: Delete cookies when consent removed We have provided the ability for a user to remove previously granted consent, but we were not removing the cookie associated with that consent. This was a complete oversight on my part. I've introduced an additional bit of metadata for each "consent" defined in the ConsentJS syspref, this allows the admin defining a "consent" to specify a string (which is treated as a regex) that allows us to identify a cookie name associated with that consent. So, for example, if Google Analytics was being added, an identifying string might be '_ga'. This allows us to subsequently remove a cookie that a previously granted consent has set. This commit also adds some missing 'html' filters in koha-tmpl/intranet-tmpl/prog/en/includes/intranet-bottom.inc and koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc Created attachment 122002 [details] [review] Bug 27378: Add cookie domain and path A subtlety I missed was that some tracking services, such as Google Analytics, specify a cookie domain and path that differ from the default. E.g. on a site with a domain of demostaff.koha-ptfs.co.uk, the GA cookie will have a domain of '.koha-ptfs.co.uk' and a path of '/', even though the cookie may have been set at a different path. Both of these things makes sense, but of course unless we also specify both of those things when we try to delete a previously set cookie, we cannot. Therefore, I have added two more bits of metadata to each "consent", Cookie Domain and Cookie Path. It is necessary for an admin creating a "consent" entry to know and specify these values. They can be established by looking a cookie set by the service being configured. This adds more complexity to setting up a consent, but we cannot remove previously set cookies without it. Created attachment 122635 [details] [review] Bug 27378: Add new 'modaljs' syspref type This commit adds a new 'modaljs' syspref type. This is similar to the existing 'modalselect' syspref type but instead of using a file to create a list of selectable options which are displayed in the modal, it assumes that anything can happen within the modal driven by JS, and whatever happens is going to return a string, that will be saved as the syspref value. In our case, the string will be all the details of the “chunks” concatenated into a string Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 122636 [details] [review] Bug 27378: Add sysprefs This commit adds 4 new sysprefs: - CookieConsent - the master on/off for this functionality - ConsentJS - The configuration for JS code that requires consent prior to running. - CookieConsentBar: Allows the admin to specify the HTML that will be displayed in the consent bar that appears at the bottom of the page - CookieConsentPopup: Allows the admin to specify the HTML that will be displayed in the cookie consent popup Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 122637 [details] [review] Bug 27378: Add JS to power modaljs This commit adds the Javascript that provides the functionality within the consentJS modaljs modal. It provides the ability to display the current state of any consentJS values and to amend them, as well as add new ones. There is also some refactoring of the existing modalselect functions to allow re-use of existing code between modalselect & modaljs. This refactoring has been minimal and consists of abstracting functionality into functions to allow more wide use. Styles for the consentJS UI were also added. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 122638 [details] [review] Bug 27378: Add cookie consent display to OPAC This commit adds the display of the cookie consent bar and modal to the OPAC. - Adds a new JSConsents template plugin that enables a template to be populated with the contents of the ConsentJS syspref in a prepared, usable form - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate - Adds the ability for both authenticated and unauthenticated users to view and modify their consents either via "your consents" or a new unobtrusive "Your cookies" button in the bottom right of the screen. - Adds unit test for JSConsents.pm Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 122639 [details] [review] Bug 27378: Add cookie consent display to staff UI This commit adds the display of the cookie consent bar and modal to the staff interface: - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 122640 [details] [review] Bug 27378: Move "Your cookies" to existing bar The new "Your cookies" button that appeared at the bottom right when an unauthenticated user had made their cookie consent selections wasn't ideal. It has now been moved to the top bar, next to "Lists", this feels like a much more sensible place for it. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 122641 [details] [review] Bug 27378: Delete cookies when consent removed We have provided the ability for a user to remove previously granted consent, but we were not removing the cookie associated with that consent. This was a complete oversight on my part. I've introduced an additional bit of metadata for each "consent" defined in the ConsentJS syspref, this allows the admin defining a "consent" to specify a string (which is treated as a regex) that allows us to identify a cookie name associated with that consent. So, for example, if Google Analytics was being added, an identifying string might be '_ga'. This allows us to subsequently remove a cookie that a previously granted consent has set. This commit also adds some missing 'html' filters in koha-tmpl/intranet-tmpl/prog/en/includes/intranet-bottom.inc and koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 122642 [details] [review] Bug 27378: Add cookie domain and path A subtlety I missed was that some tracking services, such as Google Analytics, specify a cookie domain and path that differ from the default. E.g. on a site with a domain of demostaff.koha-ptfs.co.uk, the GA cookie will have a domain of '.koha-ptfs.co.uk' and a path of '/', even though the cookie may have been set at a different path. Both of these things makes sense, but of course unless we also specify both of those things when we try to delete a previously set cookie, we cannot. Therefore, I have added two more bits of metadata to each "consent", Cookie Domain and Cookie Path. It is necessary for an admin creating a "consent" entry to know and specify these values. They can be established by looking a cookie set by the service being configured. This adds more complexity to setting up a consent, but we cannot remove previously set cookies without it. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Thoroughly tested by Barry Cannon (and their customers the Institutes of Technology consortium, Ireland). Add SO lines at their request. Error in : installer/data/mysql/atomicupdate/bug_27378_add_CookieConsentPopup_syspref.perl (shoudl quote with q{} so the | doesn't break it) In testing I was never able to get the cookies to set - can you provide some values in the test plan that work on koha testing docker - I got complaints of bad domain for cookies Question: Should you be able to keep using the site before clicking 'Accept' on the necessary cookies? Created attachment 124957 [details] [review] Bug 27378: Add new 'modaljs' syspref type This commit adds a new 'modaljs' syspref type. This is similar to the existing 'modalselect' syspref type but instead of using a file to create a list of selectable options which are displayed in the modal, it assumes that anything can happen within the modal driven by JS, and whatever happens is going to return a string, that will be saved as the syspref value. In our case, the string will be all the details of the “chunks” concatenated into a string Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 124958 [details] [review] Bug 27378: Add sysprefs This commit adds 4 new sysprefs: - CookieConsent - the master on/off for this functionality - ConsentJS - The configuration for JS code that requires consent prior to running. - CookieConsentBar: Allows the admin to specify the HTML that will be displayed in the consent bar that appears at the bottom of the page - CookieConsentPopup: Allows the admin to specify the HTML that will be displayed in the cookie consent popup Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 124959 [details] [review] Bug 27378: Add JS to power modaljs This commit adds the Javascript that provides the functionality within the consentJS modaljs modal. It provides the ability to display the current state of any consentJS values and to amend them, as well as add new ones. There is also some refactoring of the existing modalselect functions to allow re-use of existing code between modalselect & modaljs. This refactoring has been minimal and consists of abstracting functionality into functions to allow more wide use. Styles for the consentJS UI were also added. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 124960 [details] [review] Bug 27378: Add cookie consent display to OPAC This commit adds the display of the cookie consent bar and modal to the OPAC. - Adds a new JSConsents template plugin that enables a template to be populated with the contents of the ConsentJS syspref in a prepared, usable form - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate - Adds the ability for both authenticated and unauthenticated users to view and modify their consents either via "your consents" or a new unobtrusive "Your cookies" button in the bottom right of the screen. - Adds unit test for JSConsents.pm Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 124961 [details] [review] Bug 27378: Add cookie consent display to staff UI This commit adds the display of the cookie consent bar and modal to the staff interface: - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 124962 [details] [review] Bug 27378: Move "Your cookies" to existing bar The new "Your cookies" button that appeared at the bottom right when an unauthenticated user had made their cookie consent selections wasn't ideal. It has now been moved to the top bar, next to "Lists", this feels like a much more sensible place for it. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 124963 [details] [review] Bug 27378: Delete cookies when consent removed We have provided the ability for a user to remove previously granted consent, but we were not removing the cookie associated with that consent. This was a complete oversight on my part. I've introduced an additional bit of metadata for each "consent" defined in the ConsentJS syspref, this allows the admin defining a "consent" to specify a string (which is treated as a regex) that allows us to identify a cookie name associated with that consent. So, for example, if Google Analytics was being added, an identifying string might be '_ga'. This allows us to subsequently remove a cookie that a previously granted consent has set. This commit also adds some missing 'html' filters in koha-tmpl/intranet-tmpl/prog/en/includes/intranet-bottom.inc and koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 124964 [details] [review] Bug 27378: Add cookie domain and path A subtlety I missed was that some tracking services, such as Google Analytics, specify a cookie domain and path that differ from the default. E.g. on a site with a domain of demostaff.koha-ptfs.co.uk, the GA cookie will have a domain of '.koha-ptfs.co.uk' and a path of '/', even though the cookie may have been set at a different path. Both of these things makes sense, but of course unless we also specify both of those things when we try to delete a previously set cookie, we cannot. Therefore, I have added two more bits of metadata to each "consent", Cookie Domain and Cookie Path. It is necessary for an admin creating a "consent" entry to know and specify these values. They can be established by looking a cookie set by the service being configured. This adds more complexity to setting up a consent, but we cannot remove previously set cookies without it. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 124965 [details] [review] Bug 27378: (follow-up) Fix update delimiter As suggested by Nick in Comment #64 - Rebased and fixed merge conflicts - Modified update delimiter (In reply to Nick Clemens from comment #64) > Error in : > installer/data/mysql/atomicupdate/bug_27378_add_CookieConsentPopup_syspref. > perl > (shoudl quote with q{} so the | doesn't break it) Thanks, fixed. > In testing I was never able to get the cookies to set - can you provide some > values in the test plan that work on koha testing docker - I got complaints > of bad domain for cookies It was developed on KTD and I just ran through the test plan on the same and it worked perfectly. For step 12 of the test plan are you using the domain you use to access the KTD in your browser? > Question: Should you be able to keep using the site before clicking 'Accept' > on the necessary cookies? I think so, I've yet to encounter a site that wouldn't let me use it before I agreed to cookies. Hi Andrew, could you please rebase? I fixed the conflict in sysprefs.sql, but got stuck on the scss. Created attachment 130072 [details] [review] Bug 27378: Add new 'modaljs' syspref type This commit adds a new 'modaljs' syspref type. This is similar to the existing 'modalselect' syspref type but instead of using a file to create a list of selectable options which are displayed in the modal, it assumes that anything can happen within the modal driven by JS, and whatever happens is going to return a string, that will be saved as the syspref value. In our case, the string will be all the details of the “chunks” concatenated into a string Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 130073 [details] [review] Bug 27378: Add sysprefs This commit adds 4 new sysprefs: - CookieConsent - the master on/off for this functionality - ConsentJS - The configuration for JS code that requires consent prior to running. - CookieConsentBar: Allows the admin to specify the HTML that will be displayed in the consent bar that appears at the bottom of the page - CookieConsentPopup: Allows the admin to specify the HTML that will be displayed in the cookie consent popup Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 130074 [details] [review] Bug 27378: Add JS to power modaljs This commit adds the Javascript that provides the functionality within the consentJS modaljs modal. It provides the ability to display the current state of any consentJS values and to amend them, as well as add new ones. There is also some refactoring of the existing modalselect functions to allow re-use of existing code between modalselect & modaljs. This refactoring has been minimal and consists of abstracting functionality into functions to allow more wide use. Styles for the consentJS UI were also added. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 130075 [details] [review] Bug 27378: Add cookie consent display to OPAC This commit adds the display of the cookie consent bar and modal to the OPAC. - Adds a new JSConsents template plugin that enables a template to be populated with the contents of the ConsentJS syspref in a prepared, usable form - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate - Adds the ability for both authenticated and unauthenticated users to view and modify their consents either via "your consents" or a new unobtrusive "Your cookies" button in the bottom right of the screen. - Adds unit test for JSConsents.pm Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 130076 [details] [review] Bug 27378: Add cookie consent display to staff UI This commit adds the display of the cookie consent bar and modal to the staff interface: - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 130077 [details] [review] Bug 27378: Move "Your cookies" to existing bar The new "Your cookies" button that appeared at the bottom right when an unauthenticated user had made their cookie consent selections wasn't ideal. It has now been moved to the top bar, next to "Lists", this feels like a much more sensible place for it. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 130078 [details] [review] Bug 27378: Delete cookies when consent removed We have provided the ability for a user to remove previously granted consent, but we were not removing the cookie associated with that consent. This was a complete oversight on my part. I've introduced an additional bit of metadata for each "consent" defined in the ConsentJS syspref, this allows the admin defining a "consent" to specify a string (which is treated as a regex) that allows us to identify a cookie name associated with that consent. So, for example, if Google Analytics was being added, an identifying string might be '_ga'. This allows us to subsequently remove a cookie that a previously granted consent has set. This commit also adds some missing 'html' filters in koha-tmpl/intranet-tmpl/prog/en/includes/intranet-bottom.inc and koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 130079 [details] [review] Bug 27378: Add cookie domain and path A subtlety I missed was that some tracking services, such as Google Analytics, specify a cookie domain and path that differ from the default. E.g. on a site with a domain of demostaff.koha-ptfs.co.uk, the GA cookie will have a domain of '.koha-ptfs.co.uk' and a path of '/', even though the cookie may have been set at a different path. Both of these things makes sense, but of course unless we also specify both of those things when we try to delete a previously set cookie, we cannot. Therefore, I have added two more bits of metadata to each "consent", Cookie Domain and Cookie Path. It is necessary for an admin creating a "consent" entry to know and specify these values. They can be established by looking a cookie set by the service being configured. This adds more complexity to setting up a consent, but we cannot remove previously set cookies without it. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 130080 [details] [review] Bug 27378: (follow-up) Fix update delimiter As suggested by Nick in Comment #64 Rebased and ready for QA FAIL koha-tmpl/opac-tmpl/bootstrap/en/includes/masthead.inc FAIL filters missing_filter at line 465 ( <input class="consentCheckbox" type="checkbox" name="consentCheckbox" value="[% consent.id %]">) More: FAIL koha-tmpl/intranet-tmpl/prog/en/includes/intranet-bottom.inc FAIL filters missing_filter at line 112 ( <input class="consentCheckbox" type="checkbox" name="consentCheckbox" value="[% consent.id %]">) FAIL koha-tmpl/intranet-tmpl/prog/en/modules/admin/preferences.tt FAIL filters missing_filter at line 135 ( <input type="text" name="pref_[% CHUNK.name | html %]" data-initiator="[% CHUNK.initiator | html %]" data-processor="[% CHUNK.processor %]" id="pref_[% CHUNK.name | html %]" class="modaljs preference preference-[% CHUNK.type | html %]" readonly="readonly" value="[% CHUNK.value | html %]"/>) Created attachment 135309 [details] [review] Bug 27378: Add new 'modaljs' syspref type This commit adds a new 'modaljs' syspref type. This is similar to the existing 'modalselect' syspref type but instead of using a file to create a list of selectable options which are displayed in the modal, it assumes that anything can happen within the modal driven by JS, and whatever happens is going to return a string, that will be saved as the syspref value. In our case, the string will be all the details of the “chunks” concatenated into a string Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 135310 [details] [review] Bug 27378: Add sysprefs This commit adds 4 new sysprefs: - CookieConsent - the master on/off for this functionality - ConsentJS - The configuration for JS code that requires consent prior to running. - CookieConsentBar: Allows the admin to specify the HTML that will be displayed in the consent bar that appears at the bottom of the page - CookieConsentPopup: Allows the admin to specify the HTML that will be displayed in the cookie consent popup Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 135311 [details] [review] Bug 27378: Add JS to power modaljs This commit adds the Javascript that provides the functionality within the consentJS modaljs modal. It provides the ability to display the current state of any consentJS values and to amend them, as well as add new ones. There is also some refactoring of the existing modalselect functions to allow re-use of existing code between modalselect & modaljs. This refactoring has been minimal and consists of abstracting functionality into functions to allow more wide use. Styles for the consentJS UI were also added. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 135312 [details] [review] Bug 27378: Add cookie consent display to OPAC This commit adds the display of the cookie consent bar and modal to the OPAC. - Adds a new JSConsents template plugin that enables a template to be populated with the contents of the ConsentJS syspref in a prepared, usable form - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate - Adds the ability for both authenticated and unauthenticated users to view and modify their consents either via "your consents" or a new unobtrusive "Your cookies" button in the bottom right of the screen. - Adds unit test for JSConsents.pm Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 135313 [details] [review] Bug 27378: Add cookie consent display to staff UI This commit adds the display of the cookie consent bar and modal to the staff interface: - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 135314 [details] [review] Bug 27378: Move "Your cookies" to existing bar The new "Your cookies" button that appeared at the bottom right when an unauthenticated user had made their cookie consent selections wasn't ideal. It has now been moved to the top bar, next to "Lists", this feels like a much more sensible place for it. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 135315 [details] [review] Bug 27378: Delete cookies when consent removed We have provided the ability for a user to remove previously granted consent, but we were not removing the cookie associated with that consent. This was a complete oversight on my part. I've introduced an additional bit of metadata for each "consent" defined in the ConsentJS syspref, this allows the admin defining a "consent" to specify a string (which is treated as a regex) that allows us to identify a cookie name associated with that consent. So, for example, if Google Analytics was being added, an identifying string might be '_ga'. This allows us to subsequently remove a cookie that a previously granted consent has set. This commit also adds some missing 'html' filters in koha-tmpl/intranet-tmpl/prog/en/includes/intranet-bottom.inc and koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 135316 [details] [review] Bug 27378: Add cookie domain and path A subtlety I missed was that some tracking services, such as Google Analytics, specify a cookie domain and path that differ from the default. E.g. on a site with a domain of demostaff.koha-ptfs.co.uk, the GA cookie will have a domain of '.koha-ptfs.co.uk' and a path of '/', even though the cookie may have been set at a different path. Both of these things makes sense, but of course unless we also specify both of those things when we try to delete a previously set cookie, we cannot. Therefore, I have added two more bits of metadata to each "consent", Cookie Domain and Cookie Path. It is necessary for an admin creating a "consent" entry to know and specify these values. They can be established by looking a cookie set by the service being configured. This adds more complexity to setting up a consent, but we cannot remove previously set cookies without it. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 135317 [details] [review] Bug 27378: (follow-up) Fix update delimiter As suggested by Nick in Comment #64 Created attachment 135318 [details] [review] Bug 27378: (follow-up) Add missing filters Rebased and missing filters added in a follow-up.. QA scripts are happy now. Some stuff: 1) Old style database updates (we got 4 separate ones for the prefs). Might be worth combining them into one atomicupdate. 2) I think the system preference descriptions are not all self explanatory. I am struggling with a little with this one: + - Specify Javascript that requires user consent to run (e.g. tracking code) + - pref: ConsentJS + type: modaljs + initiator: populateConsentJS + processor: prepareConsentJS 3) New codes cannot be saved in ConsentJs And also getting stuck here in the test plan: 12. Enter a name and description, and check both checkboxes. - For "String used to identify cookie name", enter "test1", this enables us to delete the cookie when consent is withdrawn. - For "Cookie domain" enter the domain of your Koha. - For "Cookie path" enter "/" I have entered: Name: Test Description: Testing consent Requires consent in OPAC: checked Requires consent in staff interface: checked String used to identify cookie name: test1 Cookie domain: localhost Cookie path: / When I try to save, I get: You must complete all fields. x) Future enhancement ideas: * Move CookieConsentBar and CookieConsentPopup to HTML customizations, so they can be provided in multiple languages. Created attachment 151735 [details] [review] Bug 27378: Add new 'modaljs' syspref type This commit adds a new 'modaljs' syspref type. This is similar to the existing 'modalselect' syspref type but instead of using a file to create a list of selectable options which are displayed in the modal, it assumes that anything can happen within the modal driven by JS, and whatever happens is going to return a string, that will be saved as the syspref value. In our case, the string will be all the details of the “chunks” concatenated into a string Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit ec2dc19564a733a7d1db673331d41c3ae44235e1) Created attachment 151736 [details] [review] Bug 27378: Add sysprefs This commit adds 4 new sysprefs: - CookieConsent - the master on/off for this functionality - ConsentJS - The configuration for JS code that requires consent prior to running. - CookieConsentBar: Allows the admin to specify the HTML that will be displayed in the consent bar that appears at the bottom of the page - CookieConsentPopup: Allows the admin to specify the HTML that will be displayed in the cookie consent popup Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit d17ee9aff67f99393aa47376a33764840eb2ab38) Created attachment 151737 [details] [review] Bug 27378: Add JS to power modaljs This commit adds the Javascript that provides the functionality within the consentJS modaljs modal. It provides the ability to display the current state of any consentJS values and to amend them, as well as add new ones. There is also some refactoring of the existing modalselect functions to allow re-use of existing code between modalselect & modaljs. This refactoring has been minimal and consists of abstracting functionality into functions to allow more wide use. Styles for the consentJS UI were also added. Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit 16e78715c6bafba054104eadd1778599a75026da) Created attachment 151738 [details] [review] Bug 27378: Add cookie consent display to OPAC This commit adds the display of the cookie consent bar and modal to the OPAC. - Adds a new JSConsents template plugin that enables a template to be populated with the contents of the ConsentJS syspref in a prepared, usable form - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate - Adds the ability for both authenticated and unauthenticated users to view and modify their consents either via "your consents" or a new unobtrusive "Your cookies" button in the bottom right of the screen. - Adds unit test for JSConsents.pm Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit e8469e9997eaaefad834b9685e4906f89337bbc6) Created attachment 151739 [details] [review] Bug 27378: Add cookie consent display to staff UI This commit adds the display of the cookie consent bar and modal to the staff interface: - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit 40d4b094420ea1495996976434d250b15ee78c1b) Created attachment 151740 [details] [review] Bug 27378: Move "Your cookies" to existing bar The new "Your cookies" button that appeared at the bottom right when an unauthenticated user had made their cookie consent selections wasn't ideal. It has now been moved to the top bar, next to "Lists", this feels like a much more sensible place for it. Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit a663a7afa5fec005fed90b8a870e6633e133a539) Created attachment 151741 [details] [review] Bug 27378: Delete cookies when consent removed We have provided the ability for a user to remove previously granted consent, but we were not removing the cookie associated with that consent. This was a complete oversight on my part. I've introduced an additional bit of metadata for each "consent" defined in the ConsentJS syspref, this allows the admin defining a "consent" to specify a string (which is treated as a regex) that allows us to identify a cookie name associated with that consent. So, for example, if Google Analytics was being added, an identifying string might be '_ga'. This allows us to subsequently remove a cookie that a previously granted consent has set. This commit also adds some missing 'html' filters in koha-tmpl/intranet-tmpl/prog/en/includes/intranet-bottom.inc and koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit 13bea186b66e1fd02ddad1327c073a64701edb12) Created attachment 151742 [details] [review] Bug 27378: Add cookie domain and path A subtlety I missed was that some tracking services, such as Google Analytics, specify a cookie domain and path that differ from the default. E.g. on a site with a domain of demostaff.koha-ptfs.co.uk, the GA cookie will have a domain of '.koha-ptfs.co.uk' and a path of '/', even though the cookie may have been set at a different path. Both of these things makes sense, but of course unless we also specify both of those things when we try to delete a previously set cookie, we cannot. Therefore, I have added two more bits of metadata to each "consent", Cookie Domain and Cookie Path. It is necessary for an admin creating a "consent" entry to know and specify these values. They can be established by looking a cookie set by the service being configured. This adds more complexity to setting up a consent, but we cannot remove previously set cookies without it. Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit 2221f55646eb1675888725282005a613435ef0df) Created attachment 151743 [details] [review] Bug 27378: (follow-up) Fix update delimiter As suggested by Nick in Comment #64 (cherry picked from commit cf64bc373dcec60c51dccfe2e2f9359500c6cc9b) Created attachment 151744 [details] [review] Bug 27378: (follow-up) Add missing filters (cherry picked from commit 6b8565b949b62269f6d850e6d412458d0dbcfb37) Created attachment 151745 [details] [review] Bug 27378: Fix heading structure of opac-patron-consent The current heading structure of opac-patron-consent.tt jumps straight from an h1 to an h5 for cookie consents. This has been changed to an h2 with scss updates to maintain formatting Created attachment 151746 [details] [review] Bug 27378: Fix missing bootstrap button classes This patch restores the background colour to buttons in the intranet where bootstrap classes were being overidden with a default of #fff. The colour of the the "More Information" button in the cookies bar and the "Accept selected non-essential cookies" button in the cookies modal have been changed slightly to comply with accessibility colour contrasts. Created attachment 151747 [details] [review] Bug 27378: Add missing aria-labels The checkboxes on the cookie consent modal were failing accessibility testing for not being labelled. This patch adds aria-labels to the checkboxes to satisfy the accessibility requirements Created attachment 151748 [details] [review] Bug 27378: Add aria-label to more information button This patch adds an aria-label to the More Information button in order to comply with WCAG Accessibility guidelines Created attachment 151749 [details] [review] Bug 27378: Update to new atomicupdate structure This patch consolidates the previous 4 database update files into one atomicupdate file in line with the new structure Created attachment 151750 [details] [review] Bug 27378: Change ConsentJS to CookieConsentedJS This patch updates the name of the ConsentJS syspref to CookieConsentedJS and amends the description to be more clear what the syspref is for Created attachment 151751 [details] [review] Bug 27378: Stop the codemirror editor from duplicating Previously, if the "Add new code button" was clicked in the CookieConsentedJS editor, the original entry would have duplicated CodeMirror editors. This was exponential, i.e adding two new lines would result in three codemirror editors appearing on the first entry, two on the second and so on. The click event was not being applied properly and was being applied to every element with the .expand-textarea class, rather than specifically the new elements being created. The addExpandHandler function now loops through each element individually and decides whether to apply the click event handler. Created attachment 151752 [details] [review] Bug 27378: Prevent delete confirmation from duplicating Previously, if the "Add new code" button was clicked multipe times in the CookieConsentedJS editor and then those new items were deleted, the confirmation alert would show multiple times. This was an incremental issue, i.e. if 4 new items were deleted, then the first of those would require 4 confirmations to delete, the second would require 3 and so on. This is now prevented by looping through all delete buttons and avoiding duplicating the event listeners Created attachment 151753 [details] [review] Bug 27378: Remove two sysprefs and replace with html customisations Currently there are two sysprefs - CookieConsentBar and CookieConsentPopup. These allow the user to select what text they would like to see in the consent bar and modal. These have been removed and replaced with HTML customisations to allow more flexible customisations and different languages. Sponsored by: PTFS-Europe REVISED TEST PLAN ----------------- Note: As part of this test plan you will be required to remove a value from your browser's local storage store, we use this for storing a browser's cookie consent choice. To remove this value when instructed to do so, do the following: Chrome / Edge ------ - Press F12 or right click and choose “Inspect” - Click the "Application" tab - On the left, expand the "Local Storage" section - Find the entry that corresponds with the URL of your Koha and click on it - Find the entry in the list with a "Key" of "cookieConsent" - Click on it and press "Delete" on your keyboard Firefox ------- - Press F12 - Click the "Storage" tab - On the left, expand the "Local Storage" section - Find the entry that corresponds with the URL of your Koha and click on it - Find the entry in the list with a "Key" of "cookieConsent" - Click on it and press "Delete" on your keyboard Note: Also you will be required to inspect cookies set in your browser. When instructed to do so, do the following: Chrome / Edge ------ - Press F12 or right click and choose “Inspect” - Click the "Application" tab - On the left, expand the "Cookies" section - Find the entry that corresponds with the URL of your Koha and click on it - View the list of cookies Firefox ------- - Press F12 - Click the "Storage" tab - On the left, expand the "Cookies" section - Find the entry that corresponds with the URL of your Koha and click on it - View the list of cookies 1. Ensure you have a tab open on the intranet view and one open on the OPAC view, ensure you are logged in on both 2. Search for “cookieconsent" in the sysprefs => TEST: Observe there are 2 new sysprefs: - “CookieConsentedJS" - "CookieConsent" 3. Change the value for the "CookieConsent" syspref to "Require" and save 4. Refresh the intranet page => TEST: In the intranet view, observe that a cookie consent bar appears at the bottom of the page with just a single "Accept all cookies" button 5. Refresh the OPAC page => TEST: In the OPAC view, observe that a cookie consent bar appears at the bottom of the page with just a single "Accept all cookies" button 6. Navigate to Tools > HTML customisations 7. Click New entry 8. In Display location, select CookieConsentBar 9. Set the Publication Date for today’s date 10. Add some text to the text editor and click save 11. Refresh the intranet page => TEST: In the intranet view, observe that the cookie consent bar appears at the bottom of the page containing the text you specified 12. Refresh the OPAC page => TEST: In the OPAC view, observe that the cookie consent bar appears at the bottom of the page containing the text you specified 13. In the HTML customisations, repeat steps 7-10 but this time selecting CookieConsentPopup 14. Return to system preferences and search for “cookieconsent” again 15. Click the “CookieConsentedJS" syspref input 16. Click the "Add new code" link 17. Enter a name and description, and check both checkboxes. - For "String used to identify cookie name", enter "test1", this enables us to delete the cookie when consent is withdrawn. - For "Cookie domain" enter the domain of your Koha. - For "Cookie path" enter "/" 18. Click the "Click to expand" link 19. Enter the following Javascript: (function() { console.log('Hello from test1'); document.cookie = “test1=testing; domain=localhost; path=/; SameSite=None; Secure”; })(); N.B. IF YOUR DOMAIN IS NOT LOCALHOST, YOU WILL NEED TO CHANGE THIS TO YOUR CORRECT DOMAIN 20. Repeat steps 11 to 14 twice more, substituting "test1" for "test2" & "test3" 21. Click "Save" 22. Refresh the intranet page => TEST: In the intranet view, observe that the cookie consent bar appears at the bottom of the page containing 3 buttons 23. Refresh the OPAC page => TEST: In the OPAC view, observe that the cookie consent bar appears at the bottom of the page containing 3 buttons 24. Click the "More information" button => TEST: Observe that a cookie consent popup is displayed listing the codes you added in the syspref, displaying the name,description and checkbox for each, allowing a code to be selected 25. Select a code => TEST: Observe that "Accept selected non-essential cookies" is enabled 26. Deselect all codes => TEST: Observe that "Accept selected non-essential cookies" is disabled 27. Open the developer tools for your browser (usually F12) and ensure you are viewing the Javascript console 28. Click accept all cookies => TEST: In the Javascript console, observe that the messages in all the codes you added to the CookieConsentedJS syspref are displayed => TEST: In the cookie list (as detailed at the top of the test plan) observe that the cookies corresponding with the consents granted have been set. 29. Navigate to any other pages in the OPAC => TEST: On each page load, in the Javascript console, observe that the messages in all the codes you added to the ConsentJS syspref are displayed 30. Remove the cookieConsent local storage (as detailed at the start) 31. Switch to the intranet view 32. Repeat steps 19-25 in the intranet view 33. Refresh the page 34. Click the "Accept all cookies" button on the cookie bar => TEST: In the Javascript console, observe that the messages in all the codes you added to the CookieConsentedJS syspref are displayed 35. Remove the cookieConsent local storage (as detailed at the start) 36. Refresh the page 37. Click the "Accept only essential cookies" button on the cookie bar => TEST: In the Javascript console, observe that none of the messages in the codes you added to the CookieConsentedJS syspref are displayed 38. Remove the cookieConsent local storage (as detailed at the start) 39. Refresh the page 40. Click the "More information" button on the cookie bar 41. Select two of the codes you defined in the CookieConsentedJS syspref 42. Click the "Accept selected non-essential cookies" button => TEST: In the Javascript console, observe that only the messages from the selected codes you added to the CookieConsentedJS syspref are displayed 43. Repeat steps 28-37 on the OPAC view 44. In the OPAC view, go to the "Your account" page => TEST: Observe that the "your consents" option is available 45. Click on "your consents" => TEST: Observe that a "Cookie consents" section is displayed, with a button 46. Click the "View your cookie consents" button => TEST: Observe that the "Cookie consent" popup is displayed allowing you to modify your cookie consents 47. Remove consent from at least one cookie, click “Accept selected non-essential cookies” => TEST: In the cookie list in your browser (as detailed at the top of the test plan), observe that any cookies you removed consent from have either been removed or have no value. 48. Log out of the OPAC => Observe that a "Your cookies" button is displayed in the top bar next to "Links" 49. Click the "Your cookies" button => TEST: Observe that the "Cookie consent" popup is displayed allowing you to modify your cookie consents and that the consents match the same ones you had when logged in Quick summary of the new version as this has been idle for a while: - Rebased to latest master branch as of 26/05/23 - Accessibility fixes have been added where required - A glitch has been fixed with the codemirror editor where it was duplicating every time the "Add new code" button was pressed - Similarly, the confirmation alert for deleting new tracking code was also duplicating when the "Delete" button was pressed - Atomic update file has been revised to the new version - Two sysprefs removed and replaced with HTML customisations as per Katrin's last QA comments - One syspref renamed to make it clearer what it is for Setting back to Needs signoff as it has been on Failed QA for a while and I've made a few changes to the original concept Created attachment 151826 [details] [review] Bug 27378: Add new 'modaljs' syspref type This commit adds a new 'modaljs' syspref type. This is similar to the existing 'modalselect' syspref type but instead of using a file to create a list of selectable options which are displayed in the modal, it assumes that anything can happen within the modal driven by JS, and whatever happens is going to return a string, that will be saved as the syspref value. In our case, the string will be all the details of the “chunks” concatenated into a string Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit ec2dc19564a733a7d1db673331d41c3ae44235e1) Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151827 [details] [review] Bug 27378: Add sysprefs This commit adds 4 new sysprefs: - CookieConsent - the master on/off for this functionality - ConsentJS - The configuration for JS code that requires consent prior to running. - CookieConsentBar: Allows the admin to specify the HTML that will be displayed in the consent bar that appears at the bottom of the page - CookieConsentPopup: Allows the admin to specify the HTML that will be displayed in the cookie consent popup Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit d17ee9aff67f99393aa47376a33764840eb2ab38) Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151828 [details] [review] Bug 27378: Add JS to power modaljs This commit adds the Javascript that provides the functionality within the consentJS modaljs modal. It provides the ability to display the current state of any consentJS values and to amend them, as well as add new ones. There is also some refactoring of the existing modalselect functions to allow re-use of existing code between modalselect & modaljs. This refactoring has been minimal and consists of abstracting functionality into functions to allow more wide use. Styles for the consentJS UI were also added. Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit 16e78715c6bafba054104eadd1778599a75026da) Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151829 [details] [review] Bug 27378: Add cookie consent display to OPAC This commit adds the display of the cookie consent bar and modal to the OPAC. - Adds a new JSConsents template plugin that enables a template to be populated with the contents of the ConsentJS syspref in a prepared, usable form - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate - Adds the ability for both authenticated and unauthenticated users to view and modify their consents either via "your consents" or a new unobtrusive "Your cookies" button in the bottom right of the screen. - Adds unit test for JSConsents.pm Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit e8469e9997eaaefad834b9685e4906f89337bbc6) Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151830 [details] [review] Bug 27378: Add cookie consent display to staff UI This commit adds the display of the cookie consent bar and modal to the staff interface: - Adds a new cookieconsent.js script that drives the display and functionality of the cookie consent bar and modal - Adds styles for the cookie consent bar and modal - Adds the creation and population of the cookie consent bar and modal, if appropriate Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit 40d4b094420ea1495996976434d250b15ee78c1b) Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151831 [details] [review] Bug 27378: Move "Your cookies" to existing bar The new "Your cookies" button that appeared at the bottom right when an unauthenticated user had made their cookie consent selections wasn't ideal. It has now been moved to the top bar, next to "Lists", this feels like a much more sensible place for it. Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit a663a7afa5fec005fed90b8a870e6633e133a539) Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151832 [details] [review] Bug 27378: Delete cookies when consent removed We have provided the ability for a user to remove previously granted consent, but we were not removing the cookie associated with that consent. This was a complete oversight on my part. I've introduced an additional bit of metadata for each "consent" defined in the ConsentJS syspref, this allows the admin defining a "consent" to specify a string (which is treated as a regex) that allows us to identify a cookie name associated with that consent. So, for example, if Google Analytics was being added, an identifying string might be '_ga'. This allows us to subsequently remove a cookie that a previously granted consent has set. This commit also adds some missing 'html' filters in koha-tmpl/intranet-tmpl/prog/en/includes/intranet-bottom.inc and koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit 13bea186b66e1fd02ddad1327c073a64701edb12) Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151833 [details] [review] Bug 27378: Add cookie domain and path A subtlety I missed was that some tracking services, such as Google Analytics, specify a cookie domain and path that differ from the default. E.g. on a site with a domain of demostaff.koha-ptfs.co.uk, the GA cookie will have a domain of '.koha-ptfs.co.uk' and a path of '/', even though the cookie may have been set at a different path. Both of these things makes sense, but of course unless we also specify both of those things when we try to delete a previously set cookie, we cannot. Therefore, I have added two more bits of metadata to each "consent", Cookie Domain and Cookie Path. It is necessary for an admin creating a "consent" entry to know and specify these values. They can be established by looking a cookie set by the service being configured. This adds more complexity to setting up a consent, but we cannot remove previously set cookies without it. Signed-ff-by: Barry Cannon <bc@interleaf.ie> (cherry picked from commit 2221f55646eb1675888725282005a613435ef0df) Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151834 [details] [review] Bug 27378: (follow-up) Fix update delimiter As suggested by Nick in Comment #64 (cherry picked from commit cf64bc373dcec60c51dccfe2e2f9359500c6cc9b) Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151835 [details] [review] Bug 27378: (follow-up) Add missing filters (cherry picked from commit 6b8565b949b62269f6d850e6d412458d0dbcfb37) Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151836 [details] [review] Bug 27378: Fix heading structure of opac-patron-consent The current heading structure of opac-patron-consent.tt jumps straight from an h1 to an h5 for cookie consents. This has been changed to an h2 with scss updates to maintain formatting Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151837 [details] [review] Bug 27378: Fix missing bootstrap button classes This patch restores the background colour to buttons in the intranet where bootstrap classes were being overidden with a default of #fff. The colour of the the "More Information" button in the cookies bar and the "Accept selected non-essential cookies" button in the cookies modal have been changed slightly to comply with accessibility colour contrasts. Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151838 [details] [review] Bug 27378: Add missing aria-labels The checkboxes on the cookie consent modal were failing accessibility testing for not being labelled. This patch adds aria-labels to the checkboxes to satisfy the accessibility requirements Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151839 [details] [review] Bug 27378: Add aria-label to more information button This patch adds an aria-label to the More Information button in order to comply with WCAG Accessibility guidelines Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151840 [details] [review] Bug 27378: Update to new atomicupdate structure This patch consolidates the previous 4 database update files into one atomicupdate file in line with the new structure Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151841 [details] [review] Bug 27378: Change ConsentJS to CookieConsentedJS This patch updates the name of the ConsentJS syspref to CookieConsentedJS and amends the description to be more clear what the syspref is for Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151842 [details] [review] Bug 27378: Stop the codemirror editor from duplicating Previously, if the "Add new code button" was clicked in the CookieConsentedJS editor, the original entry would have duplicated CodeMirror editors. This was exponential, i.e adding two new lines would result in three codemirror editors appearing on the first entry, two on the second and so on. The click event was not being applied properly and was being applied to every element with the .expand-textarea class, rather than specifically the new elements being created. The addExpandHandler function now loops through each element individually and decides whether to apply the click event handler. Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151843 [details] [review] Bug 27378: Prevent delete confirmation from duplicating Previously, if the "Add new code" button was clicked multipe times in the CookieConsentedJS editor and then those new items were deleted, the confirmation alert would show multiple times. This was an incremental issue, i.e. if 4 new items were deleted, then the first of those would require 4 confirmations to delete, the second would require 3 and so on. This is now prevented by looping through all delete buttons and avoiding duplicating the event listeners Signed-off-by: Sam Lau <samalau@gmail.com> Created attachment 151844 [details] [review] Bug 27378: Remove two sysprefs and replace with html customisations Currently there are two sysprefs - CookieConsentBar and CookieConsentPopup. These allow the user to select what text they would like to see in the consent bar and modal. These have been removed and replaced with HTML customisations to allow more flexible customisations and different languages. Sponsored by: PTFS-Europe Signed-off-by: Sam Lau <samalau@gmail.com> Giving this another go... Overall this is mostly small stuff, apart from 9) maybe! We'll also need some good documetnation, but the test plan in comment 121 is a good start. 1) Perltidy Should we perltidy the new files at least? 2) System preferences - sysprefs.sql sysprefs.sql is supposed to be alphabetic (being a librarian, this is not acceptable! ;) ) ('ConfirmFutureHolds','0',... +('CookieConsentedJS', '', NULL, 'Add ... ('ConsiderOnSiteCheckoutsAsNormalCheckouts',... ('ContentWarningField', '',... +('CookieConsent', '0', NULL... 3) System preferences - YAML a) + - pref: CookieConsent + choices: + yes: Require + no: "Don't require" + - cookie consent to be displayed Should be 1 and 0. (blocker) Should we rephrase a bit? ... cookie consent to be displayed in the OPAC and staff interface. Question: Could it be interesting to make this OPAC only in the future? b) Add Javascript code that will run if cookie consent is provided (e.g. tracking code). Should we rephrase this a little? Run the following JavaScript if cookie consent was provided (e.g. tracking code): 3) Add to cookie documentation please https://wiki.koha-community.org/wiki/Use_of_Cookies For OPAC and staff interface. 4) Translatability (blocker) ' <a class="consentDelete" data-target="' + id + '" href="#">Delete</a>' + 5) Test plan and comments Giving that this is an old development there are quite some inconsistencies in what is the final product and what is mentioned in the commit messages. Like we started out with 4 prefs and now 2 are HTML customizations. Some squashing and clean-up could be really helpful I think. But: great updated test plan in comment 121 ! 6) Display issues a) In the OPAC, the cookie banner overlaps and blocks access to the language selection at the bottom. If you have them at the top too, that's ok, but some libraries prefer one over the other ( OpacLangSelectorMode = only footer ). b) In the staff interface we have the language chooser in front, cutting off a bit of the "Accept all cookies" button. c) In the OPAC readability (font color and size) is good, but in the staff interface it's much less readable. 7) Patron account a) It doesn't appear to be possible to revoke the general cookie consent? b) The contrast on the yellow "Accept selected non-essential" cookies seems bad (greyish font color on yellow background) c) Should the button read "View and update..."? d) I cannot close/cancel the modal without making a change. Clicking outside, pressing ESC, nothing works. We shoudl have a "Cancel" link. This is also true when using the "your cookies" link for a non-authenticated user. 8) Visibility OPAC/staff a) I checked one of the cookies for only OPAC and one only for staff interface. I still see all 3 cookies in the pop-up in both OPAC and staff after clearing local storage. b) This might be related: test2 is my "staff only" cookie. It's unchecked in the view, but it still gets added every time I refresh any OPAC page. Same for my "opac only" cookie: it's always added in staff interface on page reload. c) Where can staff view and alter their cookie consents? *** Bug 8155 has been marked as a duplicate of this bug. *** Just a note: JavaScript code from the test plan needs to have its quotes fixed in order to work: (function() { console.log('Hello from test1'); document.cookie = "test1=testing; domain=localhost; path=/; SameSite=None; Secure"; })(); Created attachment 153326 [details] [review] Bug 27378: Introduce cookie consent to OPAC and staff client To avoid confusion around commit messages and the content of this enhancement, this first commit is a squashed commit of all the original code submited to this bug. Following a few years of inactivity, it has been rebased and re-submitted with some fixes and concept changes contained in the more recent commits. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 153327 [details] [review] Bug 27378: (follow-up) Add missing filters (cherry picked from commit 6b8565b949b62269f6d850e6d412458d0dbcfb37) Created attachment 153328 [details] [review] Bug 27378: Fix accessibility issues Created attachment 153329 [details] [review] Bug 27378: Update to new atomicupdate structure This patch consolidates the previous 4 database update files into one atomicupdate file in line with the new structure Created attachment 153330 [details] [review] Bug 27378: Change ConsentJS to CookieConsentedJS This patch updates the name of the ConsentJS syspref to CookieConsentedJS and amends the description to be more clear what the syspref is for Created attachment 153331 [details] [review] Bug 27378: Stop the codemirror editor and delete confirmation from duplicating Previously, if the "Add new code button" was clicked in the CookieConsentedJS editor, the original entry would have duplicated CodeMirror editors. This was exponential, i.e adding two new lines would result in three codemirror editors appearing on the first entry, two on the second and so on. The click event was not being applied properly and was being applied to every element with the .expand-textarea class, rather than specifically the new elements being created. The addExpandHandler function now loops through each element individually and decides whether to apply the click event handler. Similarly, the delete confirmation was dupliacting for the same reason. This has also been resolved. Created attachment 153332 [details] [review] Bug 27378: Remove two sysprefs and replace with html customisations Currently there are two sysprefs - CookieConsentBar and CookieConsentPopup. These allow the user to select what text they would like to see in the consent bar and modal. These have been removed and replaced with HTML customisations to allow more flexible customisations and different languages. Sponsored by: PTFS-Europe Created attachment 153333 [details] [review] Bug 27378: (QA follow-up) Small fixes and tidy-ups This patch does the following: - Realphabetizes the lines in sysprefs.sql - Fixes a formatting error in patrons.pref - Adjusts the position of the cookie consent bar if the language selector is visible - Fixes translatability on the syspref modal Created attachment 153334 [details] [review] Bug 27378: (QA follow-up) Allow staff to view their cookie consents This patch allows staff to view their cookie consents through a link in the dropdown menu in the navbar. Previously staff had no way of accessing their cookie consents Created attachment 153335 [details] [review] Bug 27378: (QA follow-up) Add cancel button to cookie modal This patch adds a cancel button to the modal for reviewing cookie consents. Previously there was no way to exit without selecting one of the cookie options Created attachment 153336 [details] [review] Bug 27378: (QA follow-up) Add filtering for OPAC only and staff only cookies This patch fixes an issue where cookies selected as OPAC only would still show in the staff client and vise versa. The cookies are now filtered and only the correct cookies will be used in the OPAC and staff client (In reply to Katrin Fischer from comment #143) > Overall this is mostly small stuff, apart from 9) maybe! > > We'll also need some good documetnation, but the test plan in comment 121 is > a good start. > > 1) Perltidy > > Should we perltidy the new files at least? I've run perltidy for JSConsents.pm. > > 2) System preferences - sysprefs.sql > > sysprefs.sql is supposed to be alphabetic (being a librarian, this is not > acceptable! ;) ) Fixed :) > > ('ConfirmFutureHolds','0',... > +('CookieConsentedJS', '', NULL, 'Add ... > ('ConsiderOnSiteCheckoutsAsNormalCheckouts',... > ('ContentWarningField', '',... > +('CookieConsent', '0', NULL... > > 3) System preferences - YAML > > a) > + - pref: CookieConsent > + choices: > + yes: Require > + no: "Don't require" > + - cookie consent to be displayed > > Should be 1 and 0. (blocker) Fixed > Should we rephrase a bit? Re-written as per below > ... cookie consent to be displayed in the OPAC and staff interface. > > Question: Could it be interesting to make this OPAC only in the future? > > b) Add Javascript code that will run if cookie consent is provided (e.g. > tracking code). > > Should we rephrase this a little? Re-phrased as per below > Run the following JavaScript if cookie consent was provided (e.g. tracking > code): > > > 3) Add to cookie documentation please > > https://wiki.koha-community.org/wiki/Use_of_Cookies > > For OPAC and staff interface. Done > > 4) Translatability (blocker) > > ' <a class="consentDelete" data-target="' + id + '" > href="#">Delete</a>' + Fixed > > 5) Test plan and comments > > Giving that this is an old development there are quite some inconsistencies > in what is the final product and what is mentioned in the commit messages. > Like we started out with 4 prefs and now 2 are HTML customizations. Some > squashing and clean-up could be really helpful I think. > > But: great updated test plan in comment 121 ! I've squashed the original commits into one to remove the confusing messages. I've also consolidated the accessibility fixes into one commit and combined a couple of other similar commits to try and prevent duplication > > 6) Display issues > > a) In the OPAC, the cookie banner overlaps and blocks access to the language > selection at the bottom. If you have them at the top too, that's ok, but > some libraries prefer one over the other ( OpacLangSelectorMode = only > footer ). Fixed - it will now sit above the language selection when visible > > b) In the staff interface we have the language chooser in front, cutting off > a bit of the "Accept all cookies" button. Fixed as per above solution > > c) In the OPAC readability (font color and size) is good, but in the staff > interface it's much less readable. It currently just uses the default bootstrap class as in the rest of Koha, could this be a problem elsewhere? > > > 7) Patron account > > a) It doesn't appear to be possible to revoke the general cookie consent? Do you mean consent to all cookies including for example the session id? Giving this option could lead to issues with using Koha, we would probably need to be specific about which cookies this would delete > > b) The contrast on the yellow "Accept selected non-essential" cookies seems > bad (greyish font color on yellow background) It currently just uses the default bootstrap class as in the rest of Koha, could this be a problem elsewhere? > > c) Should the button read "View and update..."? > > d) I cannot close/cancel the modal without making a change. Clicking > outside, pressing ESC, nothing works. We shoudl have a "Cancel" link. This > is also true when using the "your cookies" link for a non-authenticated user. I've added a cancel button that now closes the modal > > > 8) Visibility OPAC/staff > > a) I checked one of the cookies for only OPAC and one only for staff > interface. I still see all 3 cookies in the pop-up in both OPAC and staff > after clearing local storage. > > b) This might be related: test2 is my "staff only" cookie. It's unchecked in > the view, but it still gets added every time I refresh any OPAC page. > Same for my "opac only" cookie: it's always added in staff interface on page > reload. For points A and B I've added some filtering into the call for the cookies code. This was missing previously so all cookies were being provided to both the OPAC and the staff client. This should now be fixed > > c) Where can staff view and alter their cookie consents? I've added a "My Consents" option under the user menu dropdown in the top right hand corner. This opens the modal and allows staff to review their consents Hopefully I've addressed everything, let me know if there are any further comments! Created attachment 154015 [details] [review] Bug 27378: Introduce cookie consent to OPAC and staff client To avoid confusion around commit messages and the content of this enhancement, this first commit is a squashed commit of all the original code submited to this bug. Following a few years of inactivity, it has been rebased and re-submitted with some fixes and concept changes contained in the more recent commits. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Created attachment 154016 [details] [review] Bug 27378: (follow-up) Add missing filters (cherry picked from commit 6b8565b949b62269f6d850e6d412458d0dbcfb37) Created attachment 154017 [details] [review] Bug 27378: Fix accessibility issues Created attachment 154018 [details] [review] Bug 27378: Update to new atomicupdate structure This patch consolidates the previous 4 database update files into one atomicupdate file in line with the new structure Created attachment 154019 [details] [review] Bug 27378: Change ConsentJS to CookieConsentedJS This patch updates the name of the ConsentJS syspref to CookieConsentedJS and amends the description to be more clear what the syspref is for Created attachment 154020 [details] [review] Bug 27378: Stop the codemirror editor and delete confirmation from duplicating Previously, if the "Add new code button" was clicked in the CookieConsentedJS editor, the original entry would have duplicated CodeMirror editors. This was exponential, i.e adding two new lines would result in three codemirror editors appearing on the first entry, two on the second and so on. The click event was not being applied properly and was being applied to every element with the .expand-textarea class, rather than specifically the new elements being created. The addExpandHandler function now loops through each element individually and decides whether to apply the click event handler. Similarly, the delete confirmation was dupliacting for the same reason. This has also been resolved. Created attachment 154021 [details] [review] Bug 27378: Remove two sysprefs and replace with html customisations Currently there are two sysprefs - CookieConsentBar and CookieConsentPopup. These allow the user to select what text they would like to see in the consent bar and modal. These have been removed and replaced with HTML customisations to allow more flexible customisations and different languages. Sponsored by: PTFS-Europe Created attachment 154022 [details] [review] Bug 27378: (QA follow-up) Small fixes and tidy-ups This patch does the following: - Realphabetizes the lines in sysprefs.sql - Fixes a formatting error in patrons.pref - Adjusts the position of the cookie consent bar if the language selector is visible - Fixes translatability on the syspref modal Created attachment 154023 [details] [review] Bug 27378: (QA follow-up) Allow staff to view their cookie consents This patch allows staff to view their cookie consents through a link in the dropdown menu in the navbar. Previously staff had no way of accessing their cookie consents Created attachment 154024 [details] [review] Bug 27378: (QA follow-up) Add cancel button to cookie modal This patch adds a cancel button to the modal for reviewing cookie consents. Previously there was no way to exit without selecting one of the cookie options Created attachment 154025 [details] [review] Bug 27378: (QA follow-up) Add filtering for OPAC only and staff only cookies This patch fixes an issue where cookies selected as OPAC only would still show in the staff client and vise versa. The cookies are now filtered and only the correct cookies will be used in the OPAC and staff client Hi Matt, 1) Tests are not passing: prove t/db_dependent/Koha/Template/Plugin/JSConsents.t t/db_dependent/Koha/Template/Plugin/JSConsents.t .. 1/3 # No tests run! # Failed test 'No tests run for subtest "all"' # at t/db_dependent/Koha/Template/Plugin/JSConsents.t line 23. Not an ARRAY reference at /kohadevbox/koha/Koha/Template/Plugin/JSConsents.pm line 34. # Looks like your test exited with 255 just after 3. t/db_dependent/Koha/Template/Plugin/JSConsents.t .. Dubious, test returned 255 (wstat 65280, 0xff00) Failed 1/3 subtests 2) Please some more tidy on the new files: WARN installer/data/mysql/atomicupdate/bug_27378-add_cookie_consents.pl WARN tidiness The file is less tidy than before (bad/messy lines before: 0, now: 5) WARN t/db_dependent/Koha/Template/Plugin/JSConsents.t WARN tidiness The file is less tidy than before (bad/messy lines before: 0, now: 2) 3) Cancel button in the modals should be a cancel link (not blocker) We usually have the design pattern that the submit is a button, but that the cancel is a link. 4) Cookie name or description with diacritics have OPAC and staff interface explode I had: Name: OPAC1ü Description: Description1ü Template process failed: undef error - malformed UTF-8 character in JSON string, at character offset 33 (before "\x{fffd}scription":"...") at /kohadevbox/koha/Koha/Template/Plugin/JSConsents.pm line 33. at /kohadevbox/koha/C4/Templates.pm line 127 I'll wait with further testing until this is fixed. Created attachment 154093 [details] [review] Bug 27378: (QA follow-up) Fix tests and character encoding This patch fixes an encoding issue when using diacritics. It also fixes a failing test, corrects the format of the "Cancel" links in the modal and perltidy has been used on all relevant files Back for this one... Created attachment 154264 [details] [review] Bug 27378: Introduce cookie consent to OPAC and staff client To avoid confusion around commit messages and the content of this enhancement, this first commit is a squashed commit of all the original code submited to this bug. Following a few years of inactivity, it has been rebased and re-submitted with some fixes and concept changes contained in the more recent commits. Signed-ff-by: Barry Cannon <bc@interleaf.ie> Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Created attachment 154265 [details] [review] Bug 27378: (follow-up) Add missing filters (cherry picked from commit 6b8565b949b62269f6d850e6d412458d0dbcfb37) Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Created attachment 154266 [details] [review] Bug 27378: Fix accessibility issues Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Created attachment 154267 [details] [review] Bug 27378: Update to new atomicupdate structure This patch consolidates the previous 4 database update files into one atomicupdate file in line with the new structure Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Created attachment 154268 [details] [review] Bug 27378: Change ConsentJS to CookieConsentedJS This patch updates the name of the ConsentJS syspref to CookieConsentedJS and amends the description to be more clear what the syspref is for Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Created attachment 154269 [details] [review] Bug 27378: Stop the codemirror editor and delete confirmation from duplicating Previously, if the "Add new code button" was clicked in the CookieConsentedJS editor, the original entry would have duplicated CodeMirror editors. This was exponential, i.e adding two new lines would result in three codemirror editors appearing on the first entry, two on the second and so on. The click event was not being applied properly and was being applied to every element with the .expand-textarea class, rather than specifically the new elements being created. The addExpandHandler function now loops through each element individually and decides whether to apply the click event handler. Similarly, the delete confirmation was dupliacting for the same reason. This has also been resolved. Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Created attachment 154270 [details] [review] Bug 27378: Remove two sysprefs and replace with html customisations Currently there are two sysprefs - CookieConsentBar and CookieConsentPopup. These allow the user to select what text they would like to see in the consent bar and modal. These have been removed and replaced with HTML customisations to allow more flexible customisations and different languages. Sponsored by: PTFS-Europe Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Created attachment 154271 [details] [review] Bug 27378: (QA follow-up) Small fixes and tidy-ups This patch does the following: - Realphabetizes the lines in sysprefs.sql - Fixes a formatting error in patrons.pref - Adjusts the position of the cookie consent bar if the language selector is visible - Fixes translatability on the syspref modal Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Created attachment 154272 [details] [review] Bug 27378: (QA follow-up) Allow staff to view their cookie consents This patch allows staff to view their cookie consents through a link in the dropdown menu in the navbar. Previously staff had no way of accessing their cookie consents Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Created attachment 154273 [details] [review] Bug 27378: (QA follow-up) Add cancel button to cookie modal This patch adds a cancel button to the modal for reviewing cookie consents. Previously there was no way to exit without selecting one of the cookie options Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Created attachment 154274 [details] [review] Bug 27378: (QA follow-up) Add filtering for OPAC only and staff only cookies This patch fixes an issue where cookies selected as OPAC only would still show in the staff client and vise versa. The cookies are now filtered and only the correct cookies will be used in the OPAC and staff client Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Created attachment 154275 [details] [review] Bug 27378: (QA follow-up) Fix tests and character encoding This patch fixes an encoding issue when using diacritics. It also fixes a failing test, corrects the format of the "Cancel" links in the modal and perltidy has been used on all relevant files Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Created attachment 154276 [details] [review] Bug 27378: (QA follow-up) Tidy admin/preferences.pl Signed-off-by: Katrin Fischer <katrin.fischer@bsz-bw.de> Ok, I think this all works now. I am really glad we found the encoding issue last round of testing, that would have bitten us badly. Thanks for persevering on this one Cait! Pushed to master for 23.11. Nice work everyone, thanks! (In reply to Tomás Cohen Arazi from comment #188) > Pushed to master for 23.11. > > Nice work everyone, thanks! Great ! Add a pointer for usage in the release notes ? Noticing that the combination of GDPR consent and cookie consent looks a bit weird on the opac-user consents tab. The first one is with radio buttons. The second cones directly under it (needs spacing) and is a popup where I can only click Accept. On bug 31503 I added additional consent types. The idea is that they share the same Save button. (Working with a description text, and two radio buttons. And showing the consent date from the patron consent table.) Could we rework this cookie consent somehow in the same line of thought? As a side note, 31503 is a retry of a development that stranded in QA last year because of opposition to the use of Authorised values.. This approach uses plugins. I don't see space issues myself.. could you drop a screenshot in here Marcel? Regards switching away from the modal.. it would mean sharing less code in the end case as the modal is used as the 'More information' dialogue when clicked on in the banner. I do think there aught to be some default content in the modal however.. I was surprised that we don't list the required cookies and what they do at all.. only the extra tracking cookies an administrator may be adding. I'm not sure how you could tie it all to one save button though.. the options in the modal are more voluminous (Accept all cookies, Accept essential cookies only, Accept selected non-essential cookies, Cancel). That same modal is also used for the 'Your cookies' button when you've accepted cookies but not logged in yet. Large enhancement not pushed to 23.05.x There's a whole set of follow-up bugs dealt with 3 months ago that should really have been in the first point release.. why is it taking so long to work through QA queues :( System preferences, HTML customizations and OPAC view added to the Koha manual. |