to make an app that add a new field let’s call it “title” type Data, set this field as “subject_field” and “title_field” with property setters in the Doctype ToDo, and in hook.py of the app use a method on validate of ToDo Doctype that will use frappe.utils.strip_html_tags and “truncate” to fill this field, and after_install make a script that populate this “title” field with the same rule as on validate
make a PR on github with the same code
make a PR on github that somewhere in frappe/public/js/frappe/list/base_list.js use similar frappe/public/js/frappe/ui/page.js method set_title strip_html on field of HTML type to render them
I’m willing to do one of them, just wonder what is the best way ?
For this solution, I’m not able to do it for now, but I’m ok, it will be the better one.
May be Frappe team will take action in that direction as you’ve open as Issue on Github
The issue of post 1 of this thread was quickly resolved with a PR.
If the translations provided (see above) where integrated I don’t know, but an empty description prevents the ToDo form to be saved, so it probably can’t exist unless by direct database manipulation.
Maybe you found a similar behavior elsewhere in the ERPNext or Frappe app. At least I did, (but didn’t raise anything, so far at least, because it didn’t hamper me like the title bug of this thread). This can happen of course, because it’s just one aspect of a wider use case collection most any feature does have, so, as something might simply get overlooked during dev work, it might be useful to raise a PR, bug report or so.
Stripping code from a mixture of data and code is always a tricky and even dangerous thing. It sits right at the border of secure vs. vulnerable.
On one hand you want to provide the user with nice functionality (e.g. text formatting), so the formatting must be stored somehow (in the database).
On the other hand, html tends to evolve and include more and more stuff (especially JS code bits), and if the stripping of the formatting isn’t done perfectly all the time (over the evolving time, and including the relevant libraries to manipulate the byte streams), you can easily introduce a “stored XSS” vulnerability, by any oversight.
So it might seem easier to a dev to just output the code (html) with the entered user data by using some “safe display” library function which just renders the html safely, as compared to correctly stripping of the code from the byte stream in the field with another library function.
So here we are in the field of “software supply chain”, “software BOM” and the communication of vulnerabilities as well as knowledge and awareness of the possible issues for users, usability and use cases, in a quickly evolving world wide software ecosystem.
