Bug 38706

Summary: Replace UserJS system preference with snippets
Product: Koha Reporter: Lucas Gass (lukeg) <lucas>
Component: Architecture, internals, and plumbingAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: andrew, blawlor, dcook, hacheng, kebliss, lisette, magnus, marion.durand, martin.renvoize, michael.skarupianski, michaela.sieber, paul.derscheid
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39538
GIT URL: Change sponsored?: ---
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Lucas Gass (lukeg) 2024-12-13 20:55:37 UTC
Currently the UserJS's are just a big blob of JS with each piece unrelated to the next. 

It would be nice if we replaced the system preference with individual "snippets". These could live somewhere like HTML customizations.

This would bring more organization to JS customization. It could also allow staff to see how created/edited/deleted certain blocks much easier.

It could also make it easier to incorporate different permission checks for who can create/edit/delete JS. 

See Bug 34536.
Comment 1 David Cook 2024-12-15 23:36:07 UTC
+1

--

It could be interesting to have enabled/disabled options as well. Sure, in theory, you can always just comment out the code you want to disable, but depending on how you've done your code comments this can actually be a bit of a pain. Having an easy way to turn these on/off could potentially be handy.

--

This is a bit of a tangent, but this could also allow us to enhance the UserJS feature. For instance, if we could toggle on 'type="module"', then we'd be able to add support for user-defined ES6 modules. 

(I'm curious how ES6 module imports from external URLs work with Content-Security-Policy...)

That said, I don't know how much of a value add this really would be. It just popped into my mind, as I was writing some ES6 modules last week, which made it easy to share code around my codebase without interfering/polluting the global namespace. 

Anyway, just food for thought.
Comment 2 David Cook 2024-12-16 01:57:16 UTC
(Aside: Of course, today is the day I learn that you can actually use dynamic imports in regular Javascript code...so even less utility for making the snippets appear as modules...)
Comment 3 Magnus Enger 2024-12-16 07:28:19 UTC
+1 I think it would make sense to do the same for UserCSS? And have one smippet go to either the OPAC or staff, or both?
Comment 4 Andrew Fuerste-Henry 2024-12-16 14:12:13 UTC
(In reply to Magnus Enger from comment #3)
> +1 I think it would make sense to do the same for UserCSS? And have one
> smippet go to either the OPAC or staff, or both?

I like the idea of doing the same to UserCSS.

I also like the idea of giving the user the choice of where to apply those snippets. I suppose we'd want to cover all the varieties of those sysprefs, though:
SelfCheckInUserCSS
SCOUserCSS
OPACUserCSS
IntranetUserCSS

SelfCheckInUserJS
SCOUserJS
OPACUserJS
IntranetSlipPrinterJS
IntranetUserJS
Comment 5 David Cook 2024-12-16 23:03:39 UTC
(In reply to Magnus Enger from comment #3)
> +1 I think it would make sense to do the same for UserCSS? And have one
> smippet go to either the OPAC or staff, or both?

This would be a problem when we implement Content-Security-Policy. Each individual snippet will need its own type indicated.
Comment 6 David Cook 2024-12-16 23:04:35 UTC
(In reply to David Cook from comment #5)
> (In reply to Magnus Enger from comment #3)
> > +1 I think it would make sense to do the same for UserCSS? And have one
> > smippet go to either the OPAC or staff, or both?
> 
> This would be a problem when we implement Content-Security-Policy. Each
> individual snippet will need its own type indicated.

I might be misinterpreting what you're saying though.

Overall, yes for doing it for UserCSS as well. Just so long as the snippets are clearly marked as CSS or Javascript.
Comment 7 David Cook 2024-12-16 23:05:31 UTC
(In reply to Andrew Fuerste-Henry from comment #4)
> I also like the idea of giving the user the choice of where to apply those
> snippets. I suppose we'd want to cover all the varieties of those sysprefs,

There's also the question of branch-level CSS and Javascript and how that fits into this...
Comment 8 Andrew Fuerste-Henry 2024-12-17 16:23:32 UTC
(In reply to David Cook from comment #7)
> (In reply to Andrew Fuerste-Henry from comment #4)
> > I also like the idea of giving the user the choice of where to apply those
> > snippets. I suppose we'd want to cover all the varieties of those sysprefs,
> 
> There's also the question of branch-level CSS and Javascript and how that
> fits into this...

True! I forgot that OPAC CSS and JS had been added to branches. In the structure we're ideating here it would make sense to pull that out of the branches setup and instead let each snippet be limited to one or more branches.
Comment 9 David Cook 2024-12-17 22:17:50 UTC
(In reply to Andrew Fuerste-Henry from comment #8)
> True! I forgot that OPAC CSS and JS had been added to branches. In the
> structure we're ideating here it would make sense to pull that out of the
> branches setup and instead let each snippet be limited to one or more
> branches.

Yep, I'd agree.