Don't involve jobItem in reading data
The GUI code for reading data files looks heavily overengineered to me. See also #364 (closed).
With this MR, I suggest to give up the coupling with jobItem. No clue why it was introduced, how it was intended to work, and whether it was workig as intended.
@a.nejati @m.svechnikov, I'd like both of you to review.
Merge request reports
Activity
No clue why it was introduced, how it was intended to work
The intention seems clear: to provide additional information for user. If the datafield belonged to some job, then to write comment and status for for that job.
Right now if we create a job, save it, delete data file and try to reopen the project, this code that you are removing will work. Job status will be
Failed
and inMessages
tab there will be a description. If to create a job with real data but delete only one data file, simulated or real, then there will be crash through ASSERT(0).The question is what should we do if some datafield files are missing. One way is to stop opening the project after a warning is displayed, the other one is to continue loading other data. In the latter case the removed code should be replaced with something similar, but without creating unexpected dependencies.
Edited by Mikhail Svechnikovmentioned in issue #365 (closed)
Closing here, discussion to be continued under issue #365 (closed).