https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=36282 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #1 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Created attachment 164381 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=164381&action=edit Bug 35716: PoC **K-T-D TEST ONLY** At /kohadevbox/koha, run the following: - sudo cpan File::Copy::Recursive - sudo rm -rf /usr/share/koha - sudo perl Makefile.PL # press Enter on all prompts - sudo make install - find /usr/share/koha -name hello.js Notice the output: /usr/share/koha/opac/htdocs/opac-tmpl/js/hello.js /usr/share/koha/intranet/htdocs/intranet-tmpl/js/hello.js My first attemp was using the file_map that is used to PM but I failed. Even changing the code to allow for multiple targets in the file_map, the WriteMakefile will always only map 1 to 1 from the PM hashref. But PL_FILES allows for an array of destinations given one source. This patch needs more work as a SHARED_TMPL_DIR env variable would be ideal, amongst other improvements, but this is just a proof of concept to have others look at and see if they agree with this approach. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #3 from Nick Clemens (kidclamp) <nick@bywatersolutions.com> --- I love the idea here - it's frustrating that we have to maintain two sets of files for the same purposes - this could go along way towards standardizing more of what we do -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 Phil Ringnalda <phil@chetcolibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |phil@chetcolibrary.org -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #5 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- https://gitlab.com/koha-community/Koha/-/blob/main/C4/Templates.pm?ref_type=... I feel like we could do something here perhaps.. so instead of make copying to two places, we have a shared directory at the top level where we look for included including translated ones after we've looked in the more localised for themes version of the same files? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m --- Comment #7 from Fridolin Somers <fridolin.somers@biblibre.com> --- Great idea. I suggest we use the name "common" in stead of share that can mislead to file sharing over network. A bit like packages name like "koha-common", "mysql-common". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- Of course, I think this actually represents an opportunity to take it further! "tmpl" stands for templates, and templates are processed server-side. They shouldn't be web-facing! So let's think of a new structure! E.g. Git: "/kohadevbox/koha/public/shared/static" Package install: /usr/share/koha/public/shared/static Apache: Alias /shared /usr/share/koha/public/shared -- Eventually, we'd have "/public/opac" and "/public/admin" as well. (One of the advantages of using the "public" directory name is that it reminds you that whatever is located there will be served publicly.) These would contain "static" and "cgi-bin" directories for our static assets and CGI scripts. And the "templates" would move to /usr/share/koha/templates (or /tt or /tmpl or whatever), so they're not web/internet-facing. They're just available server-side as they should be. One day, "C4" and "Koha" will move into the "lib" folder in the git source tree as well. This is a code organisation which is super common elsewhere and I use it on lots of other apps. In the long-run, it would make it much easier to develop/maintain and securely run Koha. Eventually, the contents of /kohadevbox/koha and /usr/share/koha will be more closely aligned. (Obviously, only the /kohadevbox/koha will have things like "t", "xt", etc.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #11 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #8)

Another option is Apache configuration. We could modify the following files: /etc/koha/apache-shared-opac.conf /etc/koha/apache-shared-intranet.conf

Alternatively, we could use /etc/koha/apache-shared.conf, but I was thinking about how koha-gitify already touches these files, so it would be easier to work with them for now. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 Jacob O'Mara <jacob.omara@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jacob.omara@ptfs-europe.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |martin.renvoize@ptfs-europe |y.org |.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38340 CC| |pedro.amorim@ptfs-europe.co | |m --- Comment #12 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- I love your comments David, I think it's a brilliant idea. Would you be keen in submitting a patch? Maybe we start with the shared-tmpl and then move to the /public approach? I'd be onboard with whatever approach, as long as it stops us having to duplicate the same code that's used by staff and opac. I'm coming back to this bug because I could really make use of this for bug 38340, as there's quite a few shared .inc files and one .js file there that will have to make their way to intranet-tmpl and opac-tmpl as duplicated assets, but if we had this that'd no longer be the case. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #14 from David Cook <dcook@prosentient.com.au> --- Looking at this again briefly as I find it interesting... Apache config approach: - This would be easy to implement using the Debian packages and it would "just work" - However, any other Koha installation would require manual work to upgrade their Apache configuration, and it wouldn't be obvious what needs to be done (but then that's going to always be a problem with any non-package upgrade in terms of the Apache...) - Automagically will work with ktd if we implement via these files: /etc/koha/apache-shared-opac.conf /etc/koha/apache-shared-intranet.conf Symlinks: - Similarly easy to do with Debian packages - Similarly won't work for other install types. Would require manual upgrade work - Won't work in ktd without extra effort Make: - This would probably involve being a bit hacky and duplicating the code into opac and intranet targets... - Won't work in ktd because we're pre-make at this stage -- Overall, I think that really narrows it down to the Apache config only stragegy -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #16 from David Cook <dcook@prosentient.com.au> --- Sorry, Pedro, but given the amount of work this is going to take... I don't think that I'll be working on it at all. There's too many other things with higher impact for me to work on, unfortunately. I think the update to koha-conf.xml is going to be the biggest blocker... -- If we could work out the koha-conf.xml problem, then I would say "./koha-tmpl/shared/vendor/" would be a good start, because then we could pop in all kinds of language-independent third-party/vendor libraries without worrying about translations at all... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #18 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #17)

How good would it be if we had something like Catalyst's $c->uri_for()?

Then again... we don't really have an application root when we're using Plack... - Perl is proxied from Apache "/cgi-bin/koha" to Starman "/opac" or "/intranet" - Static assets are served by Apache from "/" If we were to use a proper version of $c->uri_for(), we'd need to serve both from the same root. (I do this with other apps that use Catalyst. I serve /app_root/static from Apache and /app_root from Catalyst, and then I can use $c->uri_for() to build all my self-referential URLs, and easily mount the app at whatever path I want.) -- But I guess for a proof-of-concept here we could get away with not having anything in koha-conf.xml We could just add something into Koha/Template/Plugin/Asset.pm. Just need to refactor the "url" function there. We could even refactor it to be automagical if we really wanted to... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #20 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #19)

(In reply to David Cook from comment #16)

...

Sorry, Pedro, but given the amount of work this is going to take... I don't think that I'll be working on it at all.

Well, clearly I didn't stick to that.

But even refactoring Koha/Template/Plugin/Asset.pm... we need to know the application file system route if we're going to find the file as part of the algorithm used there...

Which I guess means maybe adding another parameter to "Asset.url()" which takes a value like 'shared', which doesn't do a filesystem lookup against the application file root and instead just serves it from the web root.

Catalyst looks like it's a bit sneaky with how it finds its "home" and "root" (for templates). I don't want to get autobanned by Bugzilla so I won't paste links... Catalyst.pm#L3584 and Catalyst/Utils.pm#L204 We could use __FILE__ to get /kohadevbox/koha/Koha/Template/Plugin/Asset.pm or /usr/share/koha/lib/Koha/Template/Plugin/Asset.pm Using their algorithm we could then pop off Koha/Template/Plugin/Asset.pm and "lib" if it's present which gives us "/usr/share/koha" or "/kohadevbox/koha" which... doesn't help us. I reiterate about how Koha's file structure is one of my pet peeves... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=36221 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #23 from David Cook <dcook@prosentient.com.au> --- (In reply to Pedro Amorim from comment #22)

(In reply to David Cook from comment #21)

...

This was a huge waste of my time today 🤣.

I disagree haha

Haha thanks, Pedro. Means a lot to me :).

This is clearly a complex issue with numerous potential implications. I lack the required expertise here to develop an effective solution quickly so your input and thoughts are very much welcome. I still very much believe this should be a high priority thing to fix and the long term gains are many.

Since it's fresh in my mind now, I want to keep working on this, but I do have some other things I need to take care of. Let's see how fast I can bang something together... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #25 from David Cook <dcook@prosentient.com.au> --- Created attachment 174481 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=174481&action=edit Bug 35716: (alternate) Add a "public" directory to Koha and share its "shared" subdir This change adds a "public" directory to Koha. Using Apache configuration, we share "public/shared" as "/shared", which allows us to serve the same static content for both the OPAC and the staff interface. At this time, this must be non-translated static assets, such as CSS, vendor Javascript libraries, images, or other code which does not deal with translatable strings. Test plan: 1. Apply the patch and koha-plack --restart kohadev 2. Make sure you're using a correct koha-gitify NOTE: See https://gitlab.com/koha-community/koha-gitify/-/merge_requests/3 NOTE: Need to modify koha-gitify for rewriting apache-shared-*.conf files NOTE: 'Alias /shared "/usr/share/koha/public/shared"' => qq#Alias /shared "$gitcheckout/public/shared"#, 3. Setup Apache configuration sudo cp debian/templates/apache-shared-opac.conf /etc/koha/apache-shared-opac.conf sudo cp debian/templates/apache-shared-intranet.conf /etc/koha/apache-shared-intranet.conf sudo rm /etc/koha/apache*git.conf sudo /kohadevbox/gitify/koha-gitify kohadev /kohadevbox/koha sudo service apache2 restart 4. Go to http://localhost:8081/cgi-bin/koha/mainpage.pl 5. Open the console, and run the following: debug_shared_js(); 6. Note that the console log shows "You successfully ran this function!" 7. Go to http://localhost:8080/cgi-bin/koha/opac-main.pl 8. Open the console, and run the following: debug_shared_js(); 9. Note that the console log shows "You successfully ran this function!" 10. Check Koha installations -- 1. Check a "single" build NOTE: For simplicity, run the following as the root user: make clean rm -rf /opt/kohatest/ INSTALL_MODE=single INSTALL_BASE=/opt/kohatest PERL_MM_USE_DEFAULT=1 perl Makefile.PL make make install vi /opt/kohatest/etc/koha-httpd.conf Note that the 'shared' alias is there: Alias /shared "/opt/kohatest/public/shared" 2. Check a "dev" build NOTE: For simplicity, run the following as the root user: make clean rm -rf /opt/kohatest/ INSTALL_MODE=dev INSTALL_BASE=/opt/kohatest PERL_MM_USE_DEFAULT=1 perl Makefile.PL make make install vi /opt/kohatest/etc/koha-httpd.conf Note that the 'shared' alias is there: Alias /shared "/kohadevbox/koha/public/shared" 3. Check a "standard" build NOTE: For simplicity, run the following as the root user: make clean rm -rf /opt/kohatest/ INSTALL_MODE=standard INSTALL_BASE=/opt/kohatest KOHA_USER=root PERL_MM_USE_DEFAULT=1 perl Makefile.PL make make install vi /etc/kohatest/koha-httpd.conf Note that the 'shared' alias is there: Alias /shared "/opt/kohatest/public/shared" -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #27 from David Cook <dcook@prosentient.com.au> --- QA tools aren't happy, but fixing the tidiness on Makefile.PL and rewrite-config.PL would require a HUGE tidying effort. I don't think it's worth it. QA tools also aren't happy with what I've done for the intranet-bottom.inc, opac-bottom.inc, and public/shared/js/debug.js but that's fine for now. Those are really just for a proof-of-concept at this point. We could easily leave off those files and Koha/Template/Plugin/Asset.pm and just have this first change be a structural one. In fact, that's probably preferable anyway... -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #174481|0 |1 is obsolete| | --- Comment #28 from David Cook <dcook@prosentient.com.au> --- Created attachment 174483 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=174483&action=edit Bug 35716: (alternate) Add a "public" directory to Koha and share its "shared" subdir This change adds a "public" directory to Koha. Using Apache configuration, we share "public/shared" as "/shared", which allows us to serve the same static content for both the OPAC and the staff interface. At this time, this must be non-translated static assets, such as CSS, vendor Javascript libraries, images, or other code which does not deal with translatable strings. Test plan: 1. Apply the patch and koha-plack --restart kohadev 2. Make sure you're using a correct koha-gitify NOTE: See https://gitlab.com/koha-community/koha-gitify/-/merge_requests/3 NOTE: Need to modify koha-gitify for rewriting apache-shared-*.conf files NOTE: 'Alias /shared "/usr/share/koha/public/shared"' => qq#Alias /shared "$gitcheckout/public/shared"#, 3. Setup Apache configuration sudo cp debian/templates/apache-shared-opac.conf /etc/koha/apache-shared-opac.conf sudo cp debian/templates/apache-shared-intranet.conf /etc/koha/apache-shared-intranet.conf sudo rm /etc/koha/apache*git.conf sudo /kohadevbox/gitify/koha-gitify kohadev /kohadevbox/koha sudo service apache2 restart 4. Go to http://localhost:8081/shared/.placeholder Note that there's a file there 5. http://localhost:8080/shared/.placeholder Note that it's the same file as the staff interface 6. Check Koha installations -- 1. Check a "single" build NOTE: For simplicity, run the following as the root user: make clean rm -rf /opt/kohatest/ INSTALL_MODE=single INSTALL_BASE=/opt/kohatest PERL_MM_USE_DEFAULT=1 perl Makefile.PL make make install vi /opt/kohatest/etc/koha-httpd.conf Note that the 'shared' alias is there: Alias /shared "/opt/kohatest/public/shared" 2. Check a "dev" build NOTE: For simplicity, run the following as the root user: make clean rm -rf /opt/kohatest/ INSTALL_MODE=dev INSTALL_BASE=/opt/kohatest PERL_MM_USE_DEFAULT=1 perl Makefile.PL make make install vi /opt/kohatest/etc/koha-httpd.conf Note that the 'shared' alias is there: Alias /shared "/kohadevbox/koha/public/shared" 3. Check a "standard" build NOTE: For simplicity, run the following as the root user: make clean rm -rf /opt/kohatest/ INSTALL_MODE=standard INSTALL_BASE=/opt/kohatest KOHA_USER=root PERL_MM_USE_DEFAULT=1 perl Makefile.PL make make install vi /etc/kohatest/koha-httpd.conf Note that the 'shared' alias is there: Alias /shared "/opt/kohatest/public/shared" -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #30 from David Cook <dcook@prosentient.com.au> --- There we go. Put that together with my pull request to the community's koha-gitify, and we've got a fully functioning shared path between the OPAC and the staff interface. Koha/Template/Plugin/Asset.pm would only need a little bit more refactoring to make the QA tools happy. The core architectural change is the thing I'm most pleased with. Hope you enjoy it, Pedro ;) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #32 from Pedro Amorim <pedro.amorim@ptfs-europe.com> --- Hi David, for what it's worth, I'm blown away by this work. Thank you so much for following up. I won't pretend to understand everything that's going on here, but this sure looks promising and far superior to my initial PoC. I'm able to follow the test plan successfully up to step 5, but for step 6 onwards, the 'make install' command is failing for me with the error: chown: invalid user: ‘koha:koha’ make: *** [Makefile:12431: set_koha_ownership] Error 1 I believe this is because the Makefile tries to chown to koha:koha but ktd's user:group is kohadev-koha:kohadev-koha. Please let me know what I'm missing here if you can. The error I'm encountering is possibly not even related to this work (?). I'm not as familiarized with all the different Koha builds options as you are. What should be our next steps here to ensure a seamless upgrade path for existing installations? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #34 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #33)

...

I'm able to follow the test plan successfully up to step 5, but for step 6 onwards, the 'make install' command is failing for me with the error: chown: invalid user: ‘koha:koha’ make: *** [Makefile:12431: set_koha_ownership] Error 1

I believe this is because the Makefile tries to chown to koha:koha but ktd's user:group is kohadev-koha:kohadev-koha. Please let me know what I'm missing here if you can. The error I'm encountering is possibly not even related to this work (?).

That error should only appear for the "standard" build. Are you saying you have it for all the builds.

In any case, you should be able to get around it by setting the KOHA_USER and KOHA_GROUP environmental variables to "kohadev-koha" and "kohadev-koha".

I just ran as root to be lazy.

Actually because of the chown I guess you'd have to be running as root/with sudo anyway. But yeah looking at https://github.com/Koha-Community/Koha/blob/main/Makefile.PL#L1706 it does look like set_koha_ownership is a noop except for the "standard" install mode. And then only if you're not using KOHA_USER=root, which I did put in the test plan, so you should be fine? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 Pedro Amorim <pedro.amorim@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=39449 -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.derscheid@lmscloud.de -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #37 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Disclaimer, haven't read the entire conversation here yet. Will also provide a POC after I have read it. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 --- Comment #39 from David Cook <dcook@prosentient.com.au> --- (In reply to Paul Derscheid from comment #36)

So here's how I see this happening.

We have a shared src directory where we have the js scripts/modules, then we configure the bundler (rspack) to output bundles to the destinations where those scripts/modules previously lived.

Easy setup, minification, watching for file changes, perfectly ktd compatible with low overhead.

Thoughts?

I've got a few questions and comments. 1. At the moment, this looks like it would only work for Javascript? There could be many different file types that need to be shared, although I imagine rspack could be updated to handle other formats as well? 2. If I understand correctly, it would work for KTD, because rspack would watch for changes in the source files, and then build new ones at save time? How does that factor into the test plan? 3. I'd suggest not using "/koha-tmpl/shared", because "/kohadevbox/koha/koha-tmpl" is the DocumentRoot for KTD/git deployments where with the Debian deployments it's like /usr/share/koha/opac/htdocs and /usr/share/koha/intranet/htdocs. I went with "/public" in my patch, so that the files wouldn't be web-accessible except as we explicitly define. We could add Apache rules to block access to it, but seems to me it would be easier just to put it in a different source directory other than a web server accessible one. 4. It looks a bit verbose in terms of on-going maintenance, but not unmanageably so. 5. Minimizing for production is pretty cool. 6. Looking at it again... does it bundle all the listed entries into one file? That seems very suboptimal, since we wouldn't want to load everything for every page? 7. I like that the change is all dev-side and wouldn't require any changes to existing installations. 8. How would you manage "./koha-tmpl/opac-tmpl/lib" and "./koha-tmpl/intranet-tmpl/lib"? It seems to me that these are some of the libraries that would benefit the most from being shared across the two interfaces. -- Overall, I'm intrigued! I hope the above isn't off-putting. They're just some thoughts that came to mind while reviewing the patch and thinking about it. I'd love for us to come up with a solution for this. Just yesterday I was copying the exact same Javascript file between both interfaces and feeling a little sad about it. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35716 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |roadmap_25_11 -- You are receiving this mail because: You are watching all bug changes.