Permissions

NOTE: calib constants get written to both experiment db and detector db, as permissions allow.

All databases will be world-readable.

Table of write-permissions:

• all write access requires a kerberos ticket, except the OPR accounts
• all configdb api's will use hutch/instrument in the api which will be used for authentication
• all cnf files will access ConfigDB using the opr-account style
• expert groups means unix groups like ps-xpp, psdataps-data
• there will be cross-hutch-expert protection: e.g. ps-xpp won't have permission to write to the TMO databases
• Murali has said experts may have to do an extra step (e.g. set an environment variable) in order use a different URL/end-point for expert-group access (Feb. 25, Murali says since we use kerberos everywhere, don't need different URL).

Calibration Database Access Patterns

• detectorsegment-specific calibrations will access run-dependent constants using detectorType_segmentSerialNumberString, where segmentSerialNumber is either read from the detector hardware by the daq (ideal, like epix) or managed administratively (more difficult)
• algorithmdetector-specific calibrations (e.g. geometry, hexanode roentdek algorithm, "pop" electron image inversion algorithm) will access run-dependent constants using algorithmTypedetectorType_serialNumberStringallSegmentSerialNumberString, where both halves of that field are administratively managed.
• if a detector has only one segment the segment-specific/detector-specific calibrations are the same (but we should only have one copy)
• could put segment hardware version number information as xtc payload
• this means that multi-segment detectors will need to do multiple database fetches (bad) but that detector segments can be shuffled around without changing the calib database (good)calibration constants should not be exposed to ami, but only used internally by the detector interface or the algorithm