Remove footer feature flag

[bjosttveit]

Description

Assuming v4 requires app-lib version >= 7.6.0, we can remove the featureflag check for footer.

Related Issue(s)

• Added API for fetching footer layout app-lib-dotnet#183

Verification/QA

• Manual functionality testing
  • I have tested these changes manually
  • Creator of the original issue (or service owner) has been contacted for manual testing (or will be contacted when released in alpha)
  • No testing done/necessary
• Automated tests
  • Unit test(s) have been added/updated
  • Cypress E2E test(s) have been added/updated
  • No automatic tests are needed here (no functional changes/additions)
  • I want someone to help me make some tests
• UU/WCAG (follow these guidelines until we have our own)
  • I have tested with a screen reader/keyboard navigation/automated wcag validator
  • No testing done/necessary (no DOM/visual changes)
  • I want someone to help me perform accessibility testing
• User documentation @ altinn-studio-docs
  • Has been added/updated
  • No functionality has been changed/added, so no documentation is needed
  • I will do that later/have created an issue
• Support in Altinn Studio
  • Issue(s) created for support in Studio
  • This change/feature does not require any changes to Altinn Studio
• Sprint board
  • The original issue (or this PR itself) has been added to the Team Apps project and to the current sprint board
  • I don't have permissions to do that, please help me out
• Labels
  • I have added a kind/* label to this PR for proper release notes grouping
  • I don't have permissions to add labels, please help me out

[olemartinorg]

And save 2 lines of code? 🤔 I'm not quite sure of the benefit of this. And as long as we don't have any other checks to make sure the backend version is supported, I'm not sure we should just pull out all the stops.

[bjosttveit]

And save 2 lines of code? 🤔 I'm not quite sure of the benefit of this. And as long as we don't have any other checks to make sure the backend version is supported, I'm not sure we should just pull out all the stops.

I thought we had agreed to have a minimum supported backend version? The feature flags are nothing more than a guard against this, so they serve no purpose if we do that.

[olemartinorg]

Possibly (I can't recall specifics), but I think we should implement some kind of sanity check in that case, and warn app developers in the frontend immediately if their backends are not updated.

And I also believe the feature flags from backend were supposed to be just that; flags that could be turned off. Although I guess for this specific feature it just guards against us calling an API endpoint that didn't exist in previous versions. So, what happens after this change - will older app-backends produce the 'unknown error' if the footer request fails? In that case, I agree that removing the feature flag check is a good thing.

[bjosttveit]

And I also believe the feature flags from backend were supposed to be just that; flags that could be turned off. Although I guess for this specific feature it just guards against us calling an API endpoint that didn't exist in previous versions.

Yes this one is hardcoded to true only to prevent old apps from getting 404 (as opposed to 204) in their logs.

will older app-backends produce the 'unknown error' if the footer request fails?

Not unless we also remove the treat 404 as ok logic for the footer as well, which we could very well do

[olemartinorg]

Not unless we also remove the treat 404 as ok logic for the footer as well, which we could very well do

Yep, do it! 🙌 Old backend = fatal error. That's much better than old backend = multiple fixed bugs/issues creeping back to the surface.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication

[olemartinorg]

Sorry, though I had approved it! 🚀

[olemartinorg]

Tested OK. Although our anonymous-stateless-app should fail, as it runs on nugets v6, that's not the fault of this PR. Turns out, as a stateless app, it circumvents ProcessWrapper and thus never really checks useApiErrorCheck() which is the one responsible for crashing an app once something like the footer request fails.