I have a customer running various types of projects. They collect various metrics based on project specific requirements.
I have created a custom doctype to allow them to collect these metrics.
Every once in a while, the metrics collected need to be changed (added/removed).
My question is:
Is it possible (using some variant of the salary slip process) to allow PMs to define the metrics they need to collect from the front end. In other words:
I have a universe of 100 metrics (defined in a table - similar to Salary Components)
I then have a form listing only the metrics that I selected when defining the project.
I have 15-20 permutations of parameters I need to collect.
I could always create a separate custom form for each permutation. So to your point, I can use customize form and create a new form for each set.
but a more elegant / time saving solution would be to allow user to select which parameters need to be collected for a project (when creating the Project)
The Custom form should then pick up these parameters and list them. User can input values for the parameters.
TO a certain extent - this is the approach taken by the salary component > Salary Structure > Salary slip documents.
Is the global set of fields pre-defined (the universe of 100 fields)? Or do project managers need to be able to define new fields on the fly?
If they’re pre-defined, you could always just use the depends_on property for each potential field, with display or non-display determined by the value of parameters defined a linked project document. That would certainly be the simplest option if it suits your needs.
Beyond that, if you’re willing to write some python, pretty much anything is possible.
Ultimately, I used an approach similar to the salary process.
a. Create a docType called parameters. This has the list of parameters that have to be collected. UOM etc.
b. Create a docType called Parameter Structure. This contains the set of parameters for each test. So Structure1 - may have 25 tests. Structure 2 - 55 tests.
There is a child table called ‘Parameters list’. This would store the set of tests.
c. Create a doctype called Parameter Test Results. There is a child table called ‘Parameter Results list’ in this form.
d. create a custom script so that when you select the ‘Parameter Structure’ it will auto-populate the child table from the ‘parameters list’ table.
e. Disable the add rows in ‘Parameter Results List’
f. Only enable the ‘value’ column in ‘Parameter Results List’ (rest are read only)
I must sincerely thank everyone on this forum. For each and every one of the above steps, I was able to quickly find an answer here.
But if anyone is interested, this is the custom script I had created on the ‘Lab Test Results’ Doctype. I have also flagged the discussions that aided me (Immeasurably) at the end of the code snippet
frappe.ui.form.on(‘Lab Test Results’, “lab_test_structure”, function(frm) {
//if (frm.doc.lab_test_structure){ - this is not really neccessary
frm.clear_table(“parameter_lists”);
frappe.model.with_doc(“Lab Test Structure”,frm.doc.lab_test_structure, function() {
var source_doc=frappe.model.get_doc(“Lab Test Structure”,frm.doc.lab_test_structure);
$.each(source_doc.parameters_list, function(index, source_row){
var d = frm.add_child(“parameters_list”);
d.parameter=source_row.parameter;
d.sample_position=source_row.sample_position;
d.uom=source_row.uom;
cur_frm.refresh_field(‘parameters_list’);
})
})
//}
})
frappe.ui.form.on(‘Lab Test Results’,“project”, function(frm){
// your code here
cur_frm.fields_dict[‘lab_test_structure’].get_query=function(frm) {
return {
filters: [[‘Lab Test Structure’,‘Project’,‘=’,frm.project]
]
}
};
})
frappe.ui.form.on(‘Lab Test Results’,“onload”, function(frm){
// your code here
$(“.grid-add-row”).hide();
})
