[GoalsActions] Fix user updating during project creation

[imnasnainaec]

• Fix Axios response interceptor
• Move update of user with a new userEdit from GoalsActions in the frontend to UserEditController in the backend

Fixes #691 , Fixes #692

---

This change is 

[johnthagen]

---

src/components/GoalTimeline/GoalsActions.tsx, line 73 at r1 (raw file):

    await Backend.createUserEdit()
      .then(async (userEditId: string) => {
        const LocalUser = LocalStorage.getCurrentUser();

localUser to match style guide.

[imnasnainaec]

Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @imnasnainaec and @johnthagen)

---

src/components/GoalTimeline/GoalsActions.tsx, line 73 at r1 (raw file):

Previously, johnthagen wrote…

localUser to match style guide.

But I was 2 for 2: #692 (comment)

Fixed.

[johnthagen]

@imnasnainaec I am still getting a forbidden when I execute the steps in #691 from a clean database

[imnasnainaec]

@imnasnainaec I am still getting a forbidden when I execute the steps in #691 from a clean database

@johnthagen Ah, I forgot to check the fix with a new user.

[imnasnainaec]

@imnasnainaec I am still getting a forbidden when I execute the steps in #691 from a clean database

@johnthagen Ah, I forgot to check the fix with a new user.

@johnthagen Rather, I didn't see the error because I was testing with an admin user.

[johnthagen]

---

src/backend/index.tsx, line 23 at r4 (raw file):

backendServer.interceptors.response.use(
  (resp) => {
    if (resp.data.__UpdatedUser) {

This is where silent conversion to boolean really bit us. I bet this was set to undefined rather than null or something, and so we never took this code path even though we meant to check for null rather than undefined?

[johnthagen]

---

src/components/GoalTimeline/GoalsActions.tsx, line 72 at r4 (raw file):

  return async (dispatch: ThunkDispatch<StoreState, any, GoalAction>) => {
    const user: User | null = LocalStorage.getCurrentUser();
    const projectId: string = LocalStorage.getProjectId();

Could we strip away these extra type annotations that can be inferred by the compiler/IDE per our style guide?

[johnthagen]

Reviewed 6 of 6 files at r3.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @imnasnainaec)

[johnthagen]

I have confirmed that this solves the issue I reported in #691

[imnasnainaec]

Reviewable status: 5 of 6 files reviewed, all discussions resolved (waiting on @johnthagen)

---

src/components/GoalTimeline/GoalsActions.tsx, line 72 at r4 (raw file):

Previously, johnthagen wrote…

Could we strip away these extra type annotations that can be inferred by the compiler/IDE per our style guide?

Done