Related links

• Summary page
• Submit form
• Administrator interface

New requirements and features

Blue: done

Extensions

• Human readable requestID
  
  • Suggestion #1: use European style date + nn for an incremental number per day - format = YYYYMMDDnn
  • Suggestion #2: use YYYWWnn where WW is the result of %W (i.e. week numbre in year as used for the S&C and Grid meeting annoucement - shorter, still clear)
  • Either case would have the advantage of being compact enough to be remembered and self explanatory as per the date of the request
     
• Add requestID back to the overview page and allow sorting by requestID
   
• We need better filters / selectors. This could be a long list of features
  
  • Goal: we should be able to combine selectors i.e. individual selectors should be set in such a way that we could perform AND and NOT operations.
  • Use case:
    
    • Filter request type embedding AND pwg=Heavy Flavor
    • Filter all requests type AND NOT pwg=Spin
    • Filter out the status='closed'  [this should be a default]
  • Comment: we should have the ability to negate fields such as "not a closed requests" (assuming killed and closed are not showed by default). In this particular case, it may equate to a twisted logic "only opened requests in any state < N" (easier implementation should decide / functionalities owuld be the same)
  • Suggestion: Thunderbird like selectors would be appropriate?
     
• Sorting: when sorting by priority, we have to make the 'closed' requests sorted in a different group and appear at the bottom.
  • Note: Perhaps there is a smarter way such as using groupings (group could be state and req.type, default grouping could be one for everything else than status=closed). But this idea may complicate the interface ... Groupings could however lead (or be consistent with) filters.
     
• Addition of a 'cloning' feature (create from a past request and modify little)
  • Suggestions:
    • 'clone' reads from original node ID, copy to new node ID as default field filled.
    • A new request ID need to be generated.
    • Be careful of the 'requester' now auto-filled (it may change) hence the precedence for the logic.
    • Status of a cloned request should not be copied but reset to new
    • Priority should be reset to 0
    • ... there may be other field to watch for ...
       
• Addition of sub-request feature(hence a master request)
  • ATTENTION: functional requirement should be restricted to similar requests. The feature should NOT become a way to sort un-related requests under the same flag and hence the same priority but a way to replicate a template and change only a few (to one) parameter)
  • Use case:
    • Two samples with two different event generators for comparisons
    • Multiple Pt bins (all the rest is the same apart perhaps for the number of events in each bin)
    • Change the decay mode, multiple samples
  • Functional requirement of a "master request":
    • All base parameters used for viewing the request summary should be copied to the master request (including priority)
    • A master request is considered closed whenever all sub-requests are done/closed. The status of the master request is is the least common denominator for all sub-requests
  • Suggested:
    • Approach #1: Generate a master request from a fully specified request, use cloning for adding more request of the same kind allowing (through a check box indicating which field would change) only a few fields modifications. As stated, number of events should always be modifiable.
    • Approach #2: Create a master request only filling a few field, indicates which one would change - initiate the cloning from the master request ensuring / validating the fields selected as changing for the sub-requests

Tuning

• The current requests were sorted by priorities in descending order whereas 100 is the lowest priority and 1 the highest. Sorting would need to be changed in descending order for EC priority.
• I found several issues as I was parsing a few jobs:
  • Chain options contained &amp; (see for example You do not have access to view this node.
  • The same happens for detector setup which becomes unreadable (what happened?)
• Change the default EC priority to 0

Presentation / information

• Gaussian sigma xyz - small text in form under box says "Z" for all three field - should be corrected
• There are no options to specify the Z vertex offset from Z=0. This should appear and be saved.
• Several fields require an number input bit it is not at all clear what the units should be (please, review and add)
• Similarly, an example input for each field would be helpful
• "Number of events" accepted a number 160000 but not 160k. It is suggested to allow for "k" and "M" to be allowed.