When the application is not preloaded then running Rspec doesn't know
Rails until the spec helper is loaded. So we can't use Rails to find the
path of the spec helper. This has been fixed before but the DFC Address
code was developed at the same time and missed.
We were aiming to use stable URLs to identify resources but the URL
helpers were still using dfc-v1.7 because that was the last and
overriding path of the mounted DFC Provider engine.
Using Spring was hiding an loading error. When you start Rspec, Rails
and its engines are not loaded yet. So our way to load the spec helper
via `Rails.root` did not work when you ran specs on their own without
loading Rails with Spring first.
We still have the scale stored in two places but in our current system
that's part of a unit's "id".
If the DFC adds that value to its standard then we can use it for lookup
and don't need to repeat it.
* https://github.com/datafoodconsortium/taxonomies/issues/7
We wanted to use our own context before but now I found a better way for
the connector to cache the context and therfore we can use the original
implementation again.
This protects us from the DFC website going down or the DFC updating
the context with breaking changes. We are in control of updating the
context now (opt-in to newer versions).
This is work in progress. The DFC Connector uses a more recent DFC
version and other endpoints still use the old serializers. We need to
update those endpoints as well and update the version number in the API
URL.
Services are usually not namespaced because they are part of the app.
This engine has an isolated namespace which means that we don't need to
separate with out own namespacing here.
We were just logging in any user without password or other verification
before. Now we verify the Keycloak signature and know that the person is
indeed logged in.
