On IE11, pages using recaptcha (like profile edit)
weren't showing the recaptcha.
On reloading, it would appear.
Mysterious.
Anyway, removing the
'<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" >
fixed the problem.
Files in the download dir can have accompanying ".md5" files
containing their MD5 and size.
This eliminates the need to calculate these when creating a job using the file.
The .md5 files were being created by stage_file (local staging)
but not by remote file management.
In fact, the latter wasn't checking for file immutability violations.
I changed remote file management to add this check,
and to create the .md5 file.
The latter is done in a new function shared with stage_file.
- The RPC handler was expecting the "BOINC names" to be the file MD5.
This is no longer true; the BOINC name can be anything as long as it's unique.
- To reflect this, use <phys_name> instead of <md5> in request messages.
This means that you'll need to update both RPC client and server software.
- BoincJobFile::insert() needed to return the insert ID
This supports the TACC use case,
in the jobs in a batch can use different Docker images
and different input and output file signatures,
none of which are known in advance.
Python API binding:
- A JOB_DESC object can optionally contain wu_template and result_template
elements, which are the templates (the actual XML) to use for that job.
Add these to the XML request message if present.
- Added the same capability to the PHP binding, but not C++.
- Added and debugged test cases for both languages.
Also, submit_batch() can take either a batch name (in which case
the batch is created) or a batch ID
(in which the batch was created prior to remotely staging files).
RPC handler:
- in submit_batch(), check for jobs with templates specified
and store them in files.
For input templates (which are deleted after creating jobs)
we put them in /tmp,
and use a map so that if two templates are the same we use 1 file.
For output templates (which have to last until all jobs are done)
we put them in templates/tmp, with content-based filenames
to economize.
- When creating jobs, or generating SQL strings for multiple jobs,
use these names as --wu_template_filename
and --result_template_filename args to create_work
(either cmdline args or stdin args)
- Delete WU templates when done
create_work.cpp:
handle per-job --wu_template and --result_template args in stdin job lines
(the names of per-job WU and result templates).
Maintain a map mapping WU template name to contents,
to avoid repeatedly reading them.
For jobs that don't specify templates, use the ones specified
at the batch level, or the defaults.
- editing resource shared wasn't working
- change sizes of controls to "input-sm"
- show errors correctly in project prefs
- move selection of project prefs from project_specific_prefs.inc
to project.inc.
This means that (unless you've added your own project prefs)
you can update project_specific_prefs.inc from master, with no changes.
NOTE: projects will need to move their project prefs selections, e.g.
define('COLOR_PREFS', false);
from project_specific_prefs.inc to project.inc.
Then copy project.sample/project_specific_prefs.inc to your project/
policy change: when showing lists of name/value pairs in a table,
don't show the names with a different background color or font.
This is what Edward Tufte would call "noise".
Keep the visuals as simple as possible.
Bootstrap forms require a bunch of <div>s and other stuff.
I wrapped these in functions like
form_start()
form_end()
form_submit()
form_select_multiple()
form_input_text()
General idea going forward:
put HTML (especially Bootstrap-specified) in utility functions,
e.g. in util.inc or bootstrap.inc.
This will make the higher-level code easier to read,
and will facilitate moving to CSS frameworks other than Bootstrap.
The front page was displaying as 2 columns even on phones.
I couldn't figure out the problem, but I switched to the standard
page_head() (moving the top part to project_banner()) and that fixed it.
In messages (forum or PM) a [pre] section with a long line
would stretch the table cell,
causing that message and others to run off the edge of the window.
The solution, as Juha pointed out, is to use table-layout:fixed
for those tables, and to explicitly set the width of the other columns.
This causes the long lines to be put in boxes with a horizontal scrollbar,
and nothing overflows.
David Anderson