Set up master as protected branch #1
Comments
|
@shanear -- also add the team as admins so we can do this. As configured I can't make this change or assign issues. |
|
done |
paultag
pushed a commit
that referenced
this issue
May 11, 2016
The following bits are (or will) be needed:
- Signing requests will be needed later. Currently, it just causes
the CSS server to 500. So, make sure that's `false` in dev, for now.
- The nameId format we used to use (and the default in the underlying
omniauth-saml-va) is to use the email nameid-format, but CSS seems
to not know what an email is, and gives us an exception. So, we're
forced to use the nameid-format of
* `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`
The following nameid-format requests will fail and result in the
server laughing at us:
* `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`
* `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`
* `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`
* `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`
* `urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName`
* `urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName`
* `urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos`
* `urn:oasis:names:tc:SAML:2.0:nameid-format:entity`
The response to the request for an `unspecified` name appears to be
the user's domain-local active directory name. We used to get back
an email, so, uh, we might need to stop assuming we can get that
from the nameID, and see if we get it back from the server in the
form of its SAML response.
- The SPID we sent them is not `CASEFLOW` anymore, but rather (and
questionably) a URL. We should revert that back to `CASEFLOW` in
future.
This now introduces a set of code branches we'll have to maintain for
IAM and CSS. For now, this commit is just the changes for CSS, so this
will break IAM (this should avoid being landed until a followup commit
deals with that).
USA #1
tejans24
pushed a commit
that referenced
this issue
Aug 23, 2017
Ability to search for an appeal using veteran id (single appeal)
8 tasks
1 task
va-bot
pushed a commit
that referenced
this issue
Jan 13, 2020
Resolves #12949 ### Description In "Assign to Person" task assignment modals, we were offering inactive users ### Acceptance Criteria - [ ] Test suite passes. ### Testing Plan 1. Log in as translation team member #1, e.g. ORG_QUEUE_USER_1 2. Navigate to http://localhost:3000/organizations/translation, open a case (e.g. http://localhost:3000/queue/appeals/2e7d0f5b-f9eb-4767-9b41-40426d9b0562) 3. In task actions, go to "Assign to Person". You should see Translation team member #5. 4. Now make Translation team member #5 as inactive in the rails console: `User.find_by_css_id("ORG_QUEUE_USER_5").inactive!` 5. Repeat steps 1 through 3. You should no longer see Team Member 5. ### User Facing Changes BEFORE: <img width="1029" alt="Screen Shot 2020-01-13 at 9 54 00 AM" src="https://user-images.githubusercontent.com/1034221/72265627-ce6b9d80-35ea-11ea-8a78-5fa5fd7e2158.png"> AFTER: <img width="1070" alt="Screen Shot 2020-01-13 at 9 58 46 AM" src="https://user-images.githubusercontent.com/1034221/72265913-4f2a9980-35eb-11ea-846f-a4242d69edf1.png">
7 tasks
2 tasks
2 tasks
6 tasks
8 tasks
7 tasks
va-bot
pushed a commit
that referenced
this issue
Dec 22, 2021
### Description This code fixes two classes of problem with our email recipient logic. #2 was only testable and solvable after fixing #1, which is why they're both included in this PR. ### The Problem Summary: 1. Email Address Fallbacks: In master currently, if you convert (or schedule?) a hearing to virtual without entering an email address, it will fall back to an email address on the veteran record. This means practically: - There are situations where there would be a HearingEmailRecipient for an email that was not typed in by the coordinator at time of scheduling. - Our test data always has the email on the veteran, prod does not, so our tests were not reflecting the reality of prod. 2. Duplicate Hearing Email Recipients: In master currently, converting any `Legacy` hearing (Travel, or Video, or Central) to virtual where the Legacy hearing doesn't already have appellant and representative emails would cause that hearing to get 2 AppellantHearingEmailRecipients and 2 RepresentativeHearingEmailRecipients. - This is incorrect, we should only have one of each of these types per hearing. - This also puts the hearing in a 'stuck' state where it's not possible to edit the email/timezone for the appellant or representative recipients. - I expect to followup with a data cleanup PR. ### Part 1 - Email Address Fallbacks We expect a hearing to have HearingEmailRecipient if and only if the user has entered an email. Right now, we go and get an email from an external source even if they don't enter an email (see testing for reproduction) The Code Changed: - Everything in this PR that's not in `create_or_update_recipients` Acceptance Criteria - [ ] It's possible to schedule a hearing and view it without any HearingEmailRecipients appearing. Testing Plan - [ ] First, look at the existing behavior in master. Do this with an (AMA) hearing to avoid hitting the other bug. - `git checkout master` - Schedule a veteran, but don't enter an email address or timezone for either appellant or representative. - Once you've clicked "Schedule" refresh the page you land on (appeal details) so the hearing appears. - Go find the "View Hearing Details" link on that page, but don't click it. Get the hearing uuid out of that link. - Switch to the console now (without clicking that details link!) - `h = Hearing.find_by_uuid("[uuid from the link]")` - `h.email_recipients.count # This should be 0` - Okay, now in the UI click the "View Hearing Details" link and run in the console - `h = Hearing.find_by_uuid("[uuid from the link]")` - `h.email_recipients.count # This now shows 2/3 - Note that viewing the hearing details page create HearingEmailRecipients. This is incorrect behavior. - [ ] Now checkout this branch and repeat those steps. You should not see any HearingEmailRecipients created in the last few steps. Accessing the View Hearing Details link does NOT create HearingEmailRecipients any longer. ### Part 2 - Duplicate Hearing Email Recipients For Legacy Hearings that don't have appellant and representative emails/timezones, converting them to virtual and entering an email/timezone (required) will put the hearing in a stuck state right now. You can see the stuck state on the hearing details page, the email and timezone fields are grayed out. The Code Changed: - Look up recipients differently in `create_or_update_recipients` Acceptance Criteria - [ ] You can convert a LegacyHearing to Virtual and - [ ] It only has one AppellantHearingEmailRecipient and one RepresentativeHearingEmailRecipient. - [ ] The UI shows the emails and timezones as editable. Testing Plan - [ ] Do the following on `master` branch to see the problem, then check out this branch and do it again to verify the problem goes away. - `git checkout master` - Go to the hearing schedule, find a travel day (or legacy video, but travel is easier to find in the UI) - For that travel day "Edit Hearing Details" for one of the travel hearings. Make sure the bottom of the screen shows no emails entered. - Click the "Type" dropdown and select "Virtual". - Fill in the appellant email like: "[email protected]" - Fill in the appellant timezone like "Eastern" - Fill in the representative email like "[email protected]" - Fill in the representative timezone like "pacific" - Choose a time if required - Click "Schedule" - Note that if you're on `master` branch the next screen will not show the representative email and the email/timezone fields will be grayed out. This should be fixed on this branch - Also go into the console, and do this (on both master and branch) ``` lh = LegacyHearing.find_by(vacols_id: 410006) lh.email_recipients # There should NOT be two of each type (rep and appellant) ```
jshields13
pushed a commit
that referenced
this issue
Mar 15, 2022
…h' to all existing scripts (#17143) add "#!-/bin/bash" to the top of all scripts and also requested that i move the payee_code_update_script into the scripts folder.
45 tasks
7 tasks
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Settings >> BranchesThe text was updated successfully, but these errors were encountered: