feature: include what field/component that triggered save

[lorang92]

Description

Adds two header values field and componentId when calling put on a data element (which in turns calls processWrite).
This enables app developers with some c# knowhow to get the header values from the HTTP-context when running data processing.

Related Issue(s)

• Slack discussion (internal link)

Verification

• Your code builds clean without any errors or warnings
• Manual testing done (required)
• Relevant automated test added (if you find this hard, leave it and we'll help out)
• All tests run green

Documentation

• User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

[olemartinorg]

While I'm not opposed to this quick-fix (I know we've discussed this for a long time, and there is certainly a need for it), I still think the question is a bit misunderstood. App developers want to know "which field changed here", but with repeating groups it can be an entire row at once. There is also no guarantee there won't be changes in app-frontend-react causing multiple values to change at the same time. Also, what if you have a spotty internet connection and some requests to save will fail, some will be delayed - that might make the backend miss the event it was looking for. Relying on getting the specific component ID that made the change, and trusting you'll always get that event, I think it's a recipe for subtle bugs in the future. The "proper" way (I think) should be to use a diffing tool in the backend to generate a list of what changed from before, and we already have the tools for that there.

[lorang92]

While I'm not opposed to this quick-fix (I know we've discussed this for a long time, and there is certainly a need for it), I still think the question is a bit misunderstood. App developers want to know "which field changed here", but with repeating groups it can be an entire row at once. There is also no guarantee there won't be changes in app-frontend-react causing multiple values to change at the same time. Also, what if you have a spotty internet connection and some requests to save will fail, some will be delayed - that might make the backend miss the event it was looking for. Relying on getting the specific component ID that made the change, and trusting you'll always get that event, I think it's a recipe for subtle bugs in the future. The "proper" way (I think) should be to use a diffing tool in the backend to generate a list of what changed from before, and we already have the tools for that there.

Most definitely see your point. These headers I think should be looked at as a "best effort" at telling the backend what was the cause of this put request, and might not be something we even document out a supported "feature". This solves a need now, and I agree some diffing tool would be better. But that requires more work. And more testing. And more time.

@nkylstad do you have have any thoughts on this? I do think @olemartinorg has a great point here. Since BRG technically does not go in production until 1. january, I guess they can live with some extra requests while we implement a better way to tell developers what changed "the proper way".

Or, should we merge this and leave it undocumented (or documented with a disclaimer)? Use at your own risk kind of thing. Any ideas, anyone?

[olemartinorg]

I agree that documenting this with a disclaimer (or not documenting it) will work. When there's a pressing need, this works better than nothing, I guess.

@DanRJ: I seem to remember something about you using our JSON diff tool in OED to figure out which data fields have changed in ProcessDataWrite? My memories of the exact code is fuzzy, but was that something that could easily be re-used or documented as a suggested way to solve the problem of "I want to know what just changed"?

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

83.3% Coverage
0.0% Duplication

[lorang92]

A diff might be something we should look into in the future as a good alternative. Might need some other changes in the backend for that to be viable. I'm merging this, seems harmless and solves real-world issues.