support ticket features

[stdweird]

I am trying out the ticket support and have some feature requests:

• support form.yml.erb like the dashboard apps. i don't really like that this data ends up in the main config files, i prefer to be able to manage it like the other interactive apps forms
• support form.js like the dashboard apps. i would like to add some dynamic things, and prefer not ot have to fork the email_service_template.html.erb (or inject the javascript via the description ;)
• limit the number of CC addresses. i prefer that people don't try to mass mail eg all students in a class or so
• allow html tags in the description page. they are now "escaped/encoded" by rails, but you can probably use .html_safe (like <%= support_ticket_description_text.html_safe %>)

Anyway, i am probably discovering this pretty late, but this could be a great addition to our site. Nice work!

[abujeda]

For more complex requirements, you can override the template used to render the support ticket form:

support_ticket:
  ui_template: "my_custom_template"

The default location for the override is:
/etc/ood/config/apps/dashboard/views/support_ticket/my_custom_template.html.erb

And use the current implementation as a reference:
https://github.com/OSC/ondemand/blob/master/apps/dashboard/app/views/support_ticket/email_service_template.html.erb

[stdweird]

@abujeda thanks. any idea how to include the default template (i am no erb expert). i only need to append some javascript to it, no other changes required

[abujeda]

You should be able to by adding a render partial to the custom template:

# /etc/ood/config/apps/dashboard/views/support_ticket/my_custom_template.html.erb
<%= javascript_tag nonce: true do -%>
    const my_custom_js_here = true
<% end  %>

<%= render partial: 'support_ticket/email_service_template' %>

Do let us know if this works for you as we haven't try this option before.

[stdweird]

@abujeda thanks

[stdweird]

@abujeda hmm, the partial render looks for file prefixed with _ it seems. i get There was an error processing your request: Missing partial support_ticket/_email_service_template

[abujeda]

Ahh yes. email_service_template is not a partial. Let me see if there is an alternative

[abujeda]

Try updating partial to file:

# /etc/ood/config/apps/dashboard/views/support_ticket/my_custom_template.html.erb
<%= javascript_tag nonce: true do -%>
    const my_custom_js_here = true
<% end  %>

<%= render file: 'support_ticket/email_service_template' %>

[stdweird]

There was an error processing your request: render file: should be given the absolute path to a file.
with the fullpath i get verbatim data (as expected from the docs)

[stdweird]

i symlinked the email_service_template to _email_service_template and then the partial works. it's at least easier to maintain then to fork the full email_service_template code.

[abujeda]

Sorry for the back and forth, I should have tried myself before making the comment.
This works for me and does not require the symlink (using template instead):

<%= javascript_tag nonce: true do -%>
  const my_custom_js_here = true
<% end  %>

<%= render template: 'support_ticket/email_service_template' %>

[stdweird]

@abujeda awesome. thanks for helping out

[stdweird]

@abujeda i added supporting html tags in the description. maybe you know some other magic to achieve the same without having to touch the original email_service_template ;)

[johrstrom]

You can redefine any partial following these instructions. This new file you provide in /etc/ood will override the one provided in /var/www so it's upgrade safe because you don't edit the original file.

https://osc.github.io/ood-documentation/latest/customizations.html?#overriding-pages

[stdweird]

@johrstrom yes, @abujeda mentioned how to do this. but i only want to add some javascript like the apps forms do, not sure that is so unique to my case (and the description not being considered html safe is probably a bug anyway).

anyway, i'll manage. thanks again for all the work that went into it

[stdweird]

some short update on this: i managed to do what i want using monkey patching some modules and classes. that way i have minimal issues with the upstream code.

i let you decide if you want to add this as features or not. for me, this can be closed

[abujeda]

Would it be possible for you to share the monkey patching that you have implemented?
There might be something that we could learn from that code and include it in the main codebase.

[stdweird]

@abujeda it's to implement some specific things, like a html description. i also made 3 categories in the support form, to require/hide certain data when filing a ticket. also to send html mails to support (with additional metadata generated so support doesn't have to look it up, incl links to certain tools we have; hence the need for html mail).

the monkey patches are applied via the initialisers, and looks like

# html safe support ticket description
require 'request_tracker_service'

module SupportTicketHelper
  # monkey patch this method to get html safe code
  #    for some reason, this works
  def support_ticket_description_text
    @user_configuration.support_ticket[:description].html_safe
  end
end

# different email template names (to control html vs text mails)
require 'support_ticket_mailer'
# reopen class after import, and edit it
class SupportTicketMailer
  default template_name: 'hpcugent_email'
end

[stdweird]

i forgot about another one, that might be useful: it's for server side jobid validation (so people can/must fill in a corectjob).
the magic hidden tings are related to my javascript that has to hide required attribute, so it puts in some placeholder text so the server side validation of required attributes doesn't fail.

the jobinfo gathered is basically sacct -j JOBID --json | jq '.jobs[0]'.
the form has a required job_id and hidden job_data. the validation by checking the job via sacct, also returns the data; and i don't want to quirey it again later, so i pass it around (on ther server side) using the hidden job_data attr.

# server side validation of jobid

# orig SupportTicket class from apps/dashboard/app/models/support_ticket.rb
require 'support_ticket'
# orig SupportTicketValidator from apps/dashboard/app/models/concerns/support_ticket_validator.rb
#    has the original validate method support_ticket_validation; no easy way to monkey path that one
module SupportTicketValidatorJob
  def support_ticket_validation_custom
    # run original validation
    support_ticket_validation
    # run custom code
    #   find job_data attr :
    job_data_attr = nil
    job_data_name = 'job_data'

    job_id_attr = nil
    job_id_name = 'job_id'

    attributes.each do |attr|
      if attr.id == job_data_name
        job_data_attr = attr
      end
      if attr.id == job_id_name
        job_id_attr = attr
      end
    end

    # no user feedback here; this is a deployment error
    if job_id_attr.nil?
      Rails.logger.error("No attr with name #{job_id_name} found #{attributes.inspect}")
    end
    if job_data_attr.nil?
      Rails.logger.error("No attr with name #{job_data_name} found #{attributes.inspect}")
    end

    validate_job_id(job_id_attr, job_data_attr)
  end


  def validate_job_id(job_id_attr, job_data_attr)
    job_id = "#{job_id_attr.value}".strip
    # all digits? not match any non-digit
    if job_id !~ /\D/
      # lookup jobid via vscood jobinfo
      #   need to pass ', as_string: true' because the smartattribute make it a string
      sacct_data = sacct_job_info(job_id, as_string: true)
      if sacct_data.nil?
        errors.add(job_id_attr.id, "No job data found for job id #{job_id}. Is the job id correct?")
      else
        # set value
        job_data_attr.value = sacct_data
      end
    else
      # keep in sync with 'const MAGIC_HIDDEN_REQUIRED = 'magic_hidden_required_placeholder';' in js
      if job_id != 'magic_hidden_required_placeholder'
        errors.add(job_id_attr.id, "Jobid must be all digits, got '#{job_id}'")
      end
    end
  end
end

class SupportTicket
  include SupportTicketValidatorJob

  validate :support_ticket_validation_custom
end

[abujeda]

Thanks for sharing!!

I will take a look and create an issue in my backlog to add some improvements to the support ticket feature.

[johrstrom]

Sorry for the late reply, but I'm not 100% we don't already support this out of the box?

https://osc.github.io/ood-documentation/latest/customizations.html#id22 and https://osc.github.io/ood-documentation/latest/customizations.html#overriding-pages

support form.yml.erb like the dashboard apps.

This is already supported.

support form.js like the dashboard apps.

Copy the partial and add a <script> tag that points to your javascript that you provided in the public directory.

limit the number of CC addresses.

You should be able to set maxlength html property in the form.yml.erb like configuration you're providing.

https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/maxlength

allow html tags in the description page

Again, overriding the partial should allow you to do anything you like here.