October 2024 - Koha-bugs - lists.koha-community.org

[Bug 14007] Item types for items hidden by OpacHiddenItems turn up in facet results
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14007 --- Comment #27 from David Cook <dcook(a)prosentient.com.au> --- Yeah... this one might not be fixable. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14007] Item types for items hidden by OpacHiddenItems turn up in facet results
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14007 --- Comment #26 from David Cook <dcook(a)prosentient.com.au> --- (In reply to David Cook from comment #25) > I'm going to take this one over. I've got a library who wants this fixed, > and I've got an idea on how to do it, so planning to do this soon. Except that I totally misunderstood the problem... Sure, if your OpacHiddenItem rule is an itype rule, you can filter it out of the facets. But if your OpacHiddenItem rule is a withdrawn rule, it's not clear what facet value belongs to a hidden item. Yep. I get it now. Bit of an oversight there... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11583] Add WYSIWYG editor for HTML notices/letters
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11583 --- Comment #14 from David Cook <dcook(a)prosentient.com.au> --- I tried out my ideas of extracting the problematic tokens and replacing with a safe token, letting TinyMCE init, and then replacing the safe tokens with the problematic tokens, but there doesn't seem to be a simple supported way of doing that without re-processing the content. -- The best bet might be to have the separate tabs. Say a CodeMirror on one tab, and a TinyMCE on another tab, and keep them synchronized, and use "protect" to stop TinyMCE from interfering with Template::Toolkit and <<>> notice syntax. That said... that's still going to be super error-prone, as TinyMCE is a pretty blunt instrument, which loves to mangle content. -- I vaguely recall someone wanting to support Mustache syntax instead of Template::Toolkit in the notices. But.. I think TinyMCE's messing with formatting would still be problematic. -- I don't know. The more I look at this, the more impossible it seems. We could do nicer previews, but I don't know about using a WYSIWYG editor... at least not with the complexity of notice templates we support. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 11583] Add WYSIWYG editor for HTML notices/letters
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11583 --- Comment #13 from David Cook <dcook(a)prosentient.com.au> --- Actually, at Kohacon2024, maybe what we discussed was just improved preview options... those would be much more doable. -- With the WYSIWYG... perhaps we could do a plugin that lets you insert template syntax into the notice without it getting entity escaped. That might not be a terrible workaround... But we'd also need some code to prevent entity escaping at init/load time, which would be more difficult. (What we could do is pre-process, extract our notice syntax and replace with a safe magical tokens like a random custom element like <24t0824ht> or {{24t0824ht}}, init/load TinyMCE, and then replace those safe tokens with our notice syntax extractions programmatically. It would be hacky, but it could probably work.) The WYWISYG would make adding HTML more user-friendly but adding Koha notice syntax more difficult. -- But in any case... this would take a lot of experimenting and even then a TinyMCE upgrade could break it. More thinking to do here... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 11583] Add WYSIWYG editor for HTML notices/letters
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11583 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |In Discussion --- Comment #12 from David Cook <dcook(a)prosentient.com.au> --- I'm not a TinyMCE expert, so my guess is that there is code that could be written to make this work, but I'm guessing it would be a fair bit of code. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 11583] Add WYSIWYG editor for HTML notices/letters
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11583 --- Comment #11 from David Cook <dcook(a)prosentient.com.au> --- (In reply to David Cook from comment #9) > After a bit of reading, it looks like we could use TinyMCE's "protect" > configuration option to allow both the TT syntax and the original <<>> > syntax to be preserved (and not HTML entity encoded). Ok, the "protect" means they're not handled by the TinyMCE at all, so they don't appear in the editor either. We could workaround that by providing both a source view and a HTML view, so that you could add your notice syntax and then sort of "preview" it, or add your HTML and then view what that's like in the source... Although technically the HTML view would still not be the same as a "rendered" view. -- TinyMCE also meddles heavily with pre-existing whitespace which can be important with Template::Toolkit in more complex notices. Also, you could enter <<whatever.whatever>> or [% stuff => stuff %] into the editor still and they would appear with the escaped HTML. That's not good. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 11583] Add WYSIWYG editor for HTML notices/letters
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11583 --- Comment #10 from David Cook <dcook(a)prosentient.com.au> --- Since TinyMCE already uses an iframe for the WYSIWYG, we shouldn't need to do anything extra with iframes or shadow DOM... We could also use on of TinyMCE's CSS configuration options to include NoticeCSS... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 11583] Add WYSIWYG editor for HTML notices/letters
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11583 --- Comment #9 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #1) > I wonder if this is still doable with the new TT syntax vs the more simple > placeholders we had before. After a bit of reading, it looks like we could use TinyMCE's "protect" configuration option to allow both the TT syntax and the original <<>> syntax to be preserved (and not HTML entity encoded). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 11583] Add WYSIWYG editor for HTML notices/letters
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11583 --- Comment #8 from David Cook <dcook(a)prosentient.com.au> --- Funny enough I just had a library ask for this... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 9365] MARCXML ILS-DI GetRecords response incorrectly encoded
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '24

23 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9365 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0