Bug 19838 - Add HTML customization for adding text to self-registration form
Summary: Add HTML customization for adding text to self-registration form
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Owen Leonard
QA Contact: Testopia
URL:
Keywords:
: 25100 31293 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-12-19 17:45 UTC by Katrin Fischer
Modified: 2026-02-09 21:37 UTC (History)
8 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
You can now add custom text to the OPAC patron self-registration form using the SelfRegistrationInstructions display location in HTML customizations.
Version(s) released in:
Circulation function:


Attachments
Bug 19838: Add customizable self registration instructions to Koha news (4.72 KB, patch)
2021-02-09 21:26 UTC, Lucas Gass (lukeg)
Details | Diff | Splinter Review
Bug 19838: Add customizable self registration instructions to Koha news (3.51 KB, patch)
2026-01-02 16:24 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 19838: (follow-up) Adapting to additional contents (4.11 KB, patch)
2026-01-02 16:24 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 19838: Add customizable self registration instructions to Koha news (3.56 KB, patch)
2026-01-03 03:28 UTC, David Nind
Details | Diff | Splinter Review
Bug 19838: (follow-up) Adapting to additional contents (4.15 KB, patch)
2026-01-03 03:28 UTC, David Nind
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2017-12-19 17:45:16 UTC
Some libraries would like to add some explanations to the self registration form. At the moment there is only a system preference for the page that shows after submitting the registration form. It would be helpful to have another that shows on the self registration form itself.
Comment 1 Lisette Scheer 2019-08-09 15:53:03 UTC
This would be very helpful. 
Lisette
Comment 2 Michael Adamyk 2021-02-09 15:39:30 UTC
Katrin, thanks for reporting this. I just ran into this issue myself, and it would be a very helpful feature.
Comment 3 Lucas Gass (lukeg) 2021-02-09 21:26:34 UTC
Created attachment 116618 [details] [review]
Bug 19838: Add customizable self registration instructions to Koha news

Test plan:
1. Apply patch
2. Go to /cgi-bin/koha/tools/koha-news.pl and create 'New entry' with a dsiplay location of SelfRegistrationInstructions
3. On the OPAC go to the self registration page
4. Your new content should be there.
5. Go back to the news tool and again edit the SelfRegistrationInstructions, try to set the library to something other than 'All libraries', you should not be able to. SelfRegistrationInstructions cannot be branch specific.
Comment 4 Lucas Gass (lukeg) 2021-02-09 21:29:44 UTC
I am assuming this should be in the News instead of as a system preference, although there is a problem with being able to select branch specific here. One cannot be logged into a branch while also self registering.

Added some JS to not allow a branch choice for this specific piece of content.
Comment 5 Séverine Queune 2021-02-10 07:55:24 UTC
(In reply to Lucas Gass from comment #4)
> I am assuming this should be in the News instead of as a system preference,
> although there is a problem with being able to select branch specific here.

Hi Lucas !
I don't completely agreed with that point, I think this feature should be branch specific but only available for the branches filled in  PatronSelfRegistrationLibraryList.
There can be some important informations a branch would like to display for future patrons, whereas the other doesn't, for example (before Covid times), the BULAC was open to anyone more than 15 it's our side "public library"), but our partner the Maison de l'Asie was only accessible for graduate students, teachers and researchers.
Comment 6 Lisette Scheer 2021-02-10 16:20:46 UTC
(In reply to Séverine Queune from comment #5)
> (In reply to Lucas Gass from comment #4)
> > I am assuming this should be in the News instead of as a system preference,
> > although there is a problem with being able to select branch specific here.
> 
> Hi Lucas !
> I don't completely agreed with that point, I think this feature should be
> branch specific but only available for the branches filled in 
> PatronSelfRegistrationLibraryList.
> There can be some important informations a branch would like to display for
> future patrons, whereas the other doesn't, for example (before Covid times),
> the BULAC was open to anyone more than 15 it's our side "public library"),
> but our partner the Maison de l'Asie was only accessible for graduate
> students, teachers and researchers.

Agreed, it would be helpful if the different news could show up when a patron selected their home branch as different libraries in a system might also have different instructions for what they need a patron to bring in to get their physical card. 

For example one of the libraries in our consortium is mailing a card to everyone who self registers and are in the service area, but we are not. Being able to provide that kind of information on a branch by branch basis would be very helpful.
Comment 7 Lucas Gass (lukeg) 2021-02-10 16:40:32 UTC
Séverine and Lisette,

I do not disagree with you at all, branch specific self reg instructions would be best. The problem with self registration is that the patron cannot be identified as belonging to any particular branch until after they have registered and selected a branch.
Comment 8 Barbara Johnson 2021-02-10 23:48:19 UTC
We're a single site library so we hide the home branch since there's only one and it doesn't make sense for the patron to have to select it or even see it.  But I can see how helpful it would be to have branch specific self reg instructions for larger libraries and consortiums.
Comment 9 Katrin Fischer 2021-02-10 23:56:08 UTC
I think then we would have to switch the text every time the library pull down is changed by the patron registering. This "on the fly" kind of change is not how the news system works currently, so I really feel it's out of scope here. But you could possibly get that effect with some additionally jQuery.
Comment 10 Katrin Fischer 2021-02-11 00:08:14 UTC
Maybe it could be an option to have a library specific text on the page that you get to after successful submission of the form? Then we know the library they registered for and could display "next steps" or "what's happening next".
Comment 11 Owen Leonard 2022-01-25 17:38:55 UTC
I'm marking this Failed QA because it won't work with the switch from News to Additional contents. However based on the discussion so far I'm not sure this works the way everyone needs it to.
Comment 12 Lucas Gass (lukeg) 2022-01-25 18:03:39 UTC
The only way I can see this working, for branch specific instructions, is to display the instructions after the user has registered and we know which branch they are associated with. But I'm not sure that is a solution that everyone would like as it cannot provide instructions that would help the user complete the form.
Comment 13 Lucas Gass (lukeg) 2022-01-27 21:48:29 UTC
*** Bug 25100 has been marked as a duplicate of this bug. ***
Comment 14 Katrin Fischer 2022-08-05 09:34:23 UTC
*** Bug 31293 has been marked as a duplicate of this bug. ***
Comment 15 David Cook 2022-08-07 23:44:50 UTC
(In reply to Katrin Fischer from comment #9)
> I think then we would have to switch the text every time the library pull
> down is changed by the patron registering. This "on the fly" kind of change
> is not how the news system works currently, so I really feel it's out of
> scope here. But you could possibly get that effect with some additionally
> jQuery.

I agree about branch-specific text being out of scope, as it would require additional enhancements.

I think one could achieve the goal by putting multiple text blocks in the "All libraries" entry with a visibility of none, and then toggling between them based on the library pull down. 

I've inserted self-registration text for quite a few libraries now, and it's always the same text for all branches. I think this would probably be the most common scenario, since typically you register for the system rather than just a branch. I think atypical scenarios could use a Jquery based solution or create further enhancements.
Comment 16 Owen Leonard 2026-01-02 16:24:29 UTC
Created attachment 190837 [details] [review]
Bug 19838: Add customizable self registration instructions to Koha news

Test plan:
1. Apply patch
2. Go to Tools -> HTML customizations and create 'New entry' with a
   dsiplay location of SelfRegistrationInstructions
3. On the OPAC go to the self registration page
4. Your new content should be there.
5. Go back to HTML customizations and edit your
   SelfRegistrationInstructions entry, try to set the library to
   something other than 'All libraries', you should not be able to.
   SelfRegistrationInstructions cannot be branch specific.
Comment 17 Owen Leonard 2026-01-02 16:24:33 UTC
Created attachment 190838 [details] [review]
Bug 19838: (follow-up) Adapting to additional contents

Also fixing enabling/disabling of library input
Comment 18 David Nind 2026-01-03 03:28:29 UTC
Created attachment 190857 [details] [review]
Bug 19838: Add customizable self registration instructions to Koha news

Test plan:
1. Apply patch
2. Go to Tools -> HTML customizations and create 'New entry' with a
   dsiplay location of SelfRegistrationInstructions
3. On the OPAC go to the self registration page
4. Your new content should be there.
5. Go back to HTML customizations and edit your
   SelfRegistrationInstructions entry, try to set the library to
   something other than 'All libraries', you should not be able to.
   SelfRegistrationInstructions cannot be branch specific.

Signed-off-by: David Nind <david@davidnind.com>
Comment 19 David Nind 2026-01-03 03:28:32 UTC
Created attachment 190858 [details] [review]
Bug 19838: (follow-up) Adapting to additional contents

Also fixing enabling/disabling of library input

Signed-off-by: David Nind <david@davidnind.com>
Comment 20 David Cook 2026-01-05 00:33:16 UTC
Like bug 39860 and bug 40659, this should be using a scrubber profile to protect against XSS vulnerabilities.
Comment 21 Owen Leonard 2026-02-09 13:11:37 UTC
(In reply to David Cook from comment #20)
> Like bug 39860 and bug 40659, this should be using a scrubber profile to
> protect against XSS vulnerabilities.

Sounds like we need a new coding guideline. David could you write up something to add to the next dev meeting? A follow-up patch here would be a great way to provide an example ;)
Comment 22 Lucas Gass (lukeg) 2026-02-09 17:21:38 UTC
(In reply to Owen Leonard from comment #21)
> (In reply to David Cook from comment #20)
> > Like bug 39860 and bug 40659, this should be using a scrubber profile to
> > protect against XSS vulnerabilities.
> 
> Sounds like we need a new coding guideline. David could you write up
> something to add to the next dev meeting? A follow-up patch here would be a
> great way to provide an example ;)

Yes, we do need a new coding guideline. If we do so, we should also file a bug and make sure all older HTML customization's get scrubbed, IMO. 

In doing so we can perhaps standardize some of the scrubber profiles? We currently have 3. 

One for 'note' which allows the following HTML tags:
    br b i em big small strong u hr span div p ol ul li dl dt dd

One for 'comment' which allows:
    br b i em big small strong

And one for "record_display" for Bug 39860, it is the most permissive one, allowing classes, IDs, and much more HTML:

                div span h1 h2 h3 h4 h5 h6 p br
                ul ol li dl dt dd
                a img
                strong b em i u s strike del ins sup sub
                blockquote cite q abbr acronym dfn
                table thead tbody tfoot tr td th caption
                pre code kbd samp var
                hr
                address

 
Do we need to come up with a general profile that can be used for all HTML customization?
Comment 23 David Cook 2026-02-09 21:37:16 UTC
(In reply to Lucas Gass (lukeg) from comment #22)
> (In reply to Owen Leonard from comment #21)
> > (In reply to David Cook from comment #20)
> > > Like bug 39860 and bug 40659, this should be using a scrubber profile to
> > > protect against XSS vulnerabilities.
> > 
> > Sounds like we need a new coding guideline. David could you write up
> > something to add to the next dev meeting? A follow-up patch here would be a
> > great way to provide an example ;)
> 
> Yes, we do need a new coding guideline. 

100% need a new coding guideline. People talk about adding things to dev meetings but I have no idea how that's done. Is there a person to send it to, somewhere to put it, or something else? I can't make it to dev meetings which makes it extra hard I think.

> Do we need to come up with a general profile that can be used for all HTML
> customization?

I don't think that's 100% possible, as different contexts can require different restrictions. The one I bump into the most locally is content that gets added into DataTables. If you allow tables into the HTML that's added into DataTables, things can bust. But then there's other places like OpacMainUserBlock where maybe you do want to allow tables. But it's not always clear what's going to end up in a DataTable as sometimes it might just be shown on a regular page. I don't have a good answer for that yet...