BUG: 403 error from elog post after experiment switching

[amandashack]

Hutch python shows a 403 authorization error after if scientists change active experiments. This is because the opr accounts only have privilege to post to active experiments. I suggest every elog.post request checks the current experiment instead of relying on a cached experiment at initialization.

Context / environment

Observed scientists in the hutch run into this error multiple times over the last week

Steps to Reproduce (for bugs)

1. login to a hutch machine and start hutch python
2. change the active experiment
3. try elog.post
   See photos

Suggested Solution

[silkenelson]

I personally feel this is likely missing training of the scientists rather than a problem. It is not clear that only the elog-posting needs to know the current experiment. We are also reading the questionnaire at this point, eventually we might read cameras and other objects from the questionnaire at the beginning of the session. I have a real concern that 'fixing' this will only introduce problems later.
The scientists already have to restart the DAQ & eloggrabber.

[amandashack]

I could definitely be missing cases where this proposed fix would introduce other problems. If the assumption is that they will always restart hutch python any time the experiment is changed then maybe we could at least catch this error and provide a helpful output telling them to restart hutch python because the experiment changed rather than an unhelpful 403 error?

[silkenelson]

Yes, I am definitely on board with figuring out how to tell the scientists that the currently used experiments is not the current one. Question is: do we want to do this always in this case or only if the mismatch causes an issue for posting? What I refer to is that if a beamline scientist did start a hutch python session as himself, they would likely be able to continue posting.

[amandashack]

Sorry, I don't think I understand your last point "What I refer to is that if a beamline scientist did start a hutch python session as himself, they would likely be able to continue posting." That looks like the proposed fix I mention, but I think I am misunderstanding

[silkenelson]

If I would start a hutch-python session as myself, I can post to all elogs. This means that if I want to make a post after the experiment has changed, my post would succeed technically, but be in the previous experiments elog. This may (or may not be) what we want, so I guess I answered my own question: the user should likely be told that they are about to (try to) post to an old experiment which may not work (if they are the operator unless someone added the operator to the experiment which people should not do longterm).

[amandashack]

Definitely had not thought about this detail! My guess is they most likely want to post to the current experiment almost every time. If you want the ability to post to other elogs from hutch python than the current active experiment than an optional arg for doing that sound like it could work (but they will only be able to do it if they are not using the opr account).

[ZLLentz]

I think this actually calls for work in https://github.com/pcdshub/elog/blob/master/elog/elog.py to change/augment the behavior on the elog object. It shouldn't be so hard to implement things like:

• On post, check that the experiment hasn't changed, warn if it has
• If the user agrees, update what experiment the object is using
• etc.

[silkenelson]

@ZLLentz My concern is that this allows people not to restart the session and we also read data from e.g. the questionnaire (which I had all intentions to extend to e.g. remove reliance on files like camViewer.cfg and go to happi+questionnaire. I am still in favor of only adding a warning unless we come up with something that when a disagreement is found to make sure we reset anything in the session that might rely on the experiment (which might only be DAQ - taken care of independently, questionnaire & elog).
I will modify my statement: if we change experiment in the elog, we also need to figure out how to deal with the quesionnaire & whatever had been loaded from there and how to update this.