Hi Sebb, Thanks for taking the time to respond.
I guess it would be possible to compose the list of reasons on the front end and pass them to the back end to compose the email. There would be a bit more network traffic because the entire text of the reasons would have to be sent. I admit I missed the comment at the beginning of the reject section which specifically refers to corresponding changes needed in incomplete.json.rb. It is a bit awkward to stitch together changes from multiple files into one branch/PR but that's just me. All told it's probably not worth spending more energy on this. Regards, Craig > On Jun 11, 2022, at 03:57, sebb <seb...@gmail.com> wrote: > > On Sat, 11 Jun 2022 at 00:15, Craig Russell <apache....@gmail.com> wrote: >> >> When parts.js.rb is updated to add more reasons to reject a document, a >> corresponding change must be made to incomplete.json.rb. >> >> Is there an easy way for incomplete.json.rb to somehow pick up the changes, >> perhaps by redefining the structure of the reasons to include all of the >> parts: the name of the variable, the text to be displayed on the tool, and >> the text to be inserted into the email? >> > > Note that parts.js.rb is converted to Javascript, and runs in the > browser, whereas incomplete.json.rb runs as a script on the server. > >> Just asking because I had this same issue last time I updated the checkboxes >> and didn't update the email text. >> >> Thinking out loud, each reason would be e.g. >> reason[1] = [@unsigned, ' unsigned', ' the document appears to be unsigned'] >> reason[2] = [@script_font, ' script font', ' a name typed in a script font >> is not a signature'] >> >> But maybe it would help if the parts.js.rb would calculate the reasons >> before invoking the incomplete message processing? In other words, just move >> the message calculation from incomplete.json.rb to parts.js.rb. > > Maybe; I'm not convinced that the effort is worthwhile compared with > (say) ensuring that the code has comments reminding maintainers what > to do. > >> Craig L Russell >> c...@apache.org >> Craig L Russell c...@apache.org
