deprecated|superseded visibility

[marqh]

I think that the change #110 has altered the behaviour of the registry with respect to deprecated and superseded status codes.

By setting the default visible status to accepted, any deprecated or superseded entities are not visible to anonymous browsing.

This appears at odds with https://github.com/UKGovLD/registry-core/wiki/Principles-and-concepts#status-and-life-cycle

and causes issues for some customers managing registries.

It looks simple to revert this change, but I want to explore the reasoning for the change before proposing an alteration. What was the desire that lead to this change? Did I instigate it with a request for altered behaviour?

If the change was targeted on the codebase, is there any capacity to patch an in situ service, or would a new release deployment be required?

many thanks mark (@der @simonoakesepimorphics )

[der]

Hi Mark. Please could you clarify what behaviour you are seeing.

By setting the default visible status to accepted that was precisely so that deprecated (and thus superseded) items are visible to anonymous browsing. As stated in Principles and Concepts:

Items with a code which is a specialisation of acccepted are visible in the normal listing of register members.

The reason for the change that was to reinstate that desired behaviour. An earlier change intended to hide submitted items (which I think might have been your issue) had an unintended effect of hiding deprecated items (at least as items, they started returning 404 incorrectly). See issue #104 .

If the change was targeted on the codebase, is there any capacity to patch an in situ service, or would a new release deployment be required?

Not sure what you mean by patching an in situ service.

For a java code change you can't patch a deployed war but you can deploy a new war to a running tomcat. The service would go down briefly while tomcat unpacks the new war but you wouldn't have to restart tomcat.

For changes to the templates you could hot patch those and velocity should reload them. So injecting a different status filter in the request from the UI could be done that way.

Note that for current versions of the UI there is the option to control the default visibility in the UI using the config.showStatus config property. Though again, changing that would require a restart of the service, the app.conf is not dynamically updatable.

[marqh]

Hello Dave

many thanks for the response

To clarify, I have been seeing deprecated|superseded entities only when logged in, not anonymously.

I thought this referenced change was the driver for this, but it seems from re-reading your response and re-examining the docs and code change, that this change was the inverse of how I read it, providing the behaviour that I want.

The key piece of information I was missing, is that there is also the option to control visibility via the app.conf setting. I had not realised this. I should have picked up the clue from the change, which described default behaviour. On checking, I discovered that this setting was indeed set to valid for the registry in question, a change that had slipped in unintentionally when conducting a UI update in the past.

Armed with this knowledge, I have addressed the issue by altering the app.conf setting, which only requires a restart, not any form of code patch (which I was pretty wary of attempting).

So, this is all very clear to me, and the issue reported to me has been fixed.

many thanks for the clear response, which has resolved this issue for me all the best mark