CenterForOpenScience
[ENG-2159] Sets Cookie for Registration Detail Ember Page
Purpose
There are a couple of bugs - one where the registration detail ember page was not provided with the cookie with a status message regarding the registration's approval/disproval and another where status messages set on cookies didn't have id fields leading to what looks like a translation error.
Changes
- Adds
idfields to status messages related to registrations (approval, embargo, public embargo, withdrawal) - Sets a cookie with a status message for the RegistrationDetail page on the Ember app
QA Notes
This can be tested through the UI. Follow the re-creation steps for the bug here and you should see a registration approval message on the registration detail page after a moderator on the registration has clicked through the approval link. The message will should no longer display the translation error detailed in ENG-2160 as that fix has been merged into ember_osf_web. In addition to registration approval messages, embargo, embargo termination, and retraction approval/rejection banner messages should be tested.
Documentation
N/A
Side Effects
N/A
Ticket
@UdayVarkhedkar Is this up-to-date with develop? Looks like those tests are still failing.
I think (h/t to Abram) that the Travis build is failing because the test relies on making a request to the ember app which it seems is not a part of the Travis environment. I'm looking into if we can effectively mock the requests to the ember app so the test can still work in Travis.
@UdayVarkhedkar Is this up-to-date with develop? Looks like those tests are still failing.
It is up to date with develop! I pulled develop and rebased this branch upon my local develop before asking you to restart Travis. All of the tests are passing locally so I think it's what I mentioned in my previous comment.
On Friday, after looking into why the test was failing in Travis (the lack of an ember-osf-web service) and trying to address that, I realized that mocking set_cookie wasn't actually an effective test because it is called in a process unrelated to what I was trying to test. In continuing to look into testing the status messages being written properly, and the osf_status being set, Abram and I got a point where we concluded that this likely could not be tested because it does not look like we can maintain session stability such that the session that the status message is pushed to is the same as the session the status message is popped from, even when trying to incorporate both into a single, albeit redirected, request.
In short, in order to test these changes effectively, we need to be able to retrieve the status message pushed upon events like registration approvals from the same session. It does not seem like we are able to do so, at least in a straightforward way, in our current testing environment. I've tested the changes multiple times locally without any issues and think, at this point, this PR continuing without tests would be best.