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();
})
