Forcing email on start

Get Help
1

I would like to make one of our apps always provide an email on start.

Is it as simple as, in form.yml, removing the field from the form: stanza, and adding bc_email_on_started: true to the attributes: stanza?

2

You need both form and attribute sections. Form defines what the options are, attribute configures those attributes.

So it’d look like this:

form:
  - bc_email_on_started
attributes:
  bc_email_on_started: 1
1 Like
3

Hi @jeff.ohrstrom ,
actually this is not working for me. ( both on 1.7.14 and on 1.6.20), with batch_connect template: “basic”.

I was trying to do the opposite of @datakid , so for a specific app I need to make sure the checkbox does not appear on the form at all, and email notification is turned off.

But for some reason either way, if I set bc_email_on_started to 0 or to 1, I get a failure when I submit the job.
If I hardcode the value the checkbox disappears from the rendered form as I want, but when I click on Launch, I get a 400 and I get this error in the log

    App 29564 output: [2020-08-26 10:34:28 -0400 ] FATAL ""
    App 29564 output: [2020-08-26 10:34:28 -0400 ] FATAL "ActionController::ParameterMissing (param is missing or the value is empty: batch_connect_session_context):"
    App 29564 output: [2020-08-26 10:34:28 -0400 ] FATAL ""
    App 29564 output: [2020-08-26 10:34:28 -0400 ] FATAL "app/controllers/batch_connect/session_contexts_controller.rb:73:in `session_contexts_param'\napp/controllers/batch_connect/session_contexts_controller.rb:30:in `create'"

It seems to not manage to get that mandatory attribute.
I don’t have any issue with hardcoding other paramters. just this one. :man_shrugging:
so in summary, none of the following seems to work:

  1. omitting bc_email_on_started from both form and attributes stanzas.

form:
  - bc_email_on_started
attributes:
  bc_email_on_started: 1

form:
  - bc_email_on_started
attributes:
  bc_email_on_started: 0

Do you have any suggestion?

4

First, I think you’re issue with the 400 is that you have to give the user at least 1 option. If you hard code everything, there are no options and therefore no context to submit. So this error isn’t really to do with the email specifically, but generally in that you need to allow at least 1 user defined option, 1 thing that is not hard coded.

Is this for bc_desktop app or something else?

If it’s for something else like Jupyter/Matlab and so on, just don’t use it. Use your option 1 to just not use it anywhere. In completely brand new applications, no fields are mandatory so if you don’t specify it - OOD will never use it.

If it is for bc_desktop, that is sort of a special case. “mandatory” fields are a strong word. They’re more like pre-defined convenience fields. It’s like this: if you don’t specify anything in form we pre-populate it with a bunch of fields that you can then specify and tweak in attributes. If you do start to specify things in the form stanza, then you’ll need to specify every item because you’re specific configuration is now overriding our generic one.

1 Like
5

Awesome. Thanks @jeff.ohrstrom .
you were absolutely right. I was hardcoding everything on this app.
It is a rstudio app for a class, and the instructor asked us if we could hardcode everything to make it easier for the students.
I tried leaving one parameter out for the users to pick, omitting the bc_email_on_started and now it works.
Thanks again.
Francesco

6

Awesome! Note that if you’re familiar with javascript you can hide the field and auto-populate it. So it’ll still be there, technically, just hidden with css. It’s sort of having your cake and eating it too.

You can see our javascript for a similar use case here where we hide the project field and auto-populate it given the ‘class’ you’re in. So student’s can submit with their appropriate chargeback codes, but they themselves didn’t have to specify it.

7

I would consider this a bug. You should be able to hard code everything and then you would expect just a submit button to appear. We will open an issue and make sure this gets fixed in a 1.8 patch release.

1 Like
8

@francesco_pontiggia FYI https://ask.cyberinfrastructure.org/t/osc-support-of-classroom-instruction/1480/3 is a summary of the approach we are taking with supporting classes. I know you were interested in the big icon launch interface that we will have in OnDemand 2.0. Using the /etc/ood/config/locales/en.yml to add these icons in the welcome_html is a simple work around to provide something similar that we are doing with class.osc.edu.

9

Thanks @jeff.ohrstrom . that is a very useful example .

10

@efranz , that is awesome. thanks!! that’s great.
I’ll certainly try to do something along those lines.