Usability question from a UI review. From a submitter list, is it feasible to click on a submitter and get to a constrained list of submissions owned by that submitter?
Current thought is that this is feasible given our current set of data (owner column in both submitter and submission tables). I'm going ahead with a prototype of the functionality to validate this thought. jross mentioned that this may be affected by some of the hierarchical fair share (limits) functionality, which I will be sure to look into as well.
I had a nice prototype of this working [in my "naive" sense of working], but that was only tested with "regular" users (no quotas/accounting groups involved). Upon further review it appears that the hierarchical fair share that jross mentioned is actually "quotas" in the interface and it does affect the effort required for this feature. If a submission is entered under an accounting group in the form of a.b.c.croberts, the value in the Submission table's Owner column will be "croberts" (seems to be either the cumin-user or the user logged in that executed the condor_submit process), which does not match the Owner column in the Submitter table (The Submitter.Owner column gets a value of a.b.c.croberts). The existing functionality of the "submitters list" is to show accounting group jobs owners in the form of "a.b.c.croberts". This uses the data from the Submitter table. In order to be able to reliably link between the submitter table and the submissions table, we would likely need more information to be stored. Any thoughts on this? I'm not sure exactly which data might already be available from condor and which data might be an RFE if we need it. Is there any chance that cumin-data is already pulling enough data for this and that we just need to add some columns/data to make the feature possible? Given that quotas come into play here, we may need to rethink the interface a bit so that the hierarchical nature can be properly reflected in the end.
The hack-around is nifty, but it doesn't get us quite the functionality that cumin needs to implement the feature required in the BZ. The hack-around gives us the data as a submission attribute that we see only when we make the qmf call. It is not something that would make it into the cumin database which is where we would need this data. Cumin could probably implement a good chunk of the functionality if it made the following assumption about the contents of the Owner fields: --Assume that in the submitter table, the actual "user owner" is either the actual contents of the field (if there are no "." in the value), or that the "user owner" is everything after the last dot. After talking with Erik and Trevor though, it turns out that assumption isn't a particularly good one to make. Fringe cases like invalid accounting groups/user names would throw wrenches in this approach. Also, a reconfig/restart of condor with accounting group changes would potentially result in oddities if cumin were to go forward with the current data/assumption. It seems like I'm back to square zero with this BZ. More thoughts anyone?
See also Bug 812403 Bug 812407
MRG-Grid is in maintenance and only customer escalations will be considered. This issue can be reopened if a customer escalation associated with it occurs.