MR: Pending ## Description The following discussion from !163093 should be addressed: - [ ] @cwoolley-gitlab started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163093#note_2166855901): (+4 comments) > **suggestion (non-blocking):** Early in the feature development for workspaces, there was some server-side logic that had a concept of calculating the `displayed_state` based on the combination of `actual_state` and `desired_state`. > > But we ended up removing that for some reason, I think because we thought it wasn't necessary anymore, and we could always just display the `actual_state` in the UI. Maybe @vtak remembers more, or we could dig into the commig/MR history. > > But based on all this logic here, it appears that hasn't turned out to be the case, and now we have all this domain logic living on the frontend. > > I would instead prefer that this logic be moved back to the backend, and just expose a new `displayed_state` field on the workspace via the GraphQL API. > > Not only to have the logic live on the backend instead of frontent, but also so it's available to any other API consumers other than the Vue client - e.g. reports, third party integrations, etc. > > If there's agreement on this, lets make a follow-up issue to do that. WDYT? ## Acceptance Criteria - [ ] Introduce concept of `displayed_state` on the backend `Workspace` model, and move all related calculations from frontend to backend. ## Technical Requirements TODO: Fill out or delete (optional) [If applicable, please list out any technical requirements for this feature/enhancement.] ## Design Requirements TODO: Fill out or delete (optional) [If applicable, please provide a link to the design specifications for this feature/enhancement.] ## Impact Assessment TODO: Fill out or delete (optional) [Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole.] ## User Story TODO: Fill out or delete (optional) [Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality.] <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://handbook.gitlab.com/handbook/engineering/development/dev/create/remote-development/#-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->