Search functionality on registryEntries (journalpost)

[Thomas Sødring]

On 12/06/2016 03:55 PM, Petter Reinholdtsen wrote:
> [Thomas Sødring]
>> I am beginning to think that there is a need for an additional
>> interface, one called *innsyn*.
> This might be a good idea, but I am not convinced.  Why do you believe a
> separate interface is useful?  I would expect the people using the
> normal interface to have the same needs as the people wanting to search
> for documents interesting from a freedom of information point of view,
> and thus it would make sense to make the normal interface search
> powerful enough for an additional interface to not make sense.
The "normal" interface is already specified, and it should allow for
flexible search capabilities as it based on the OData format. I don't
think that the interface supports advanced searches across and within
organisations/collections, which is something we probably want. I think
it supports search within a single collection/organisation, so  the 
records are assigned to one organisation (or collection).

The following request should result in a unique object

http://localhost:8092/noark5v4/saksmappe/2013-883

but in an "insynn" core it will result in multiple case files associated
with many different organisations so we will need to specify the
organisation.

 http://localhost:8092/noark5v4/organisation/974760746/saksmappe/2013-883 

The standard does not specify how queries for multiple organisations can
be implemented. Nor should it, as the organisational association of a
user should be taken care of automatically.

So I guess we could solve the issue by mapping ownership of objects via
users to organisation.

Currently, ownership is handled based on the logged in user and the
assigned roles,  but when using the core in "innsyn" mode, the
organisational information associated with the logged in user at query
time is not there and that is why I think we need an additional interface.

Now if there is another way of thinking and solving this, I am all ears!
This is why I wanted to see what you thought.

>
>> This would allow you to search records belonging to various
>> organisations stored in the core.
> What about entities without an organisation number?  I would like to be
> able to store information from before organisation numbers were
> introduced.  I've also seen separate groups within the same organisation
> creating their own mail journals (like the municipality of Oslo).
Entities without organisation could be assigned a default organisation,
the non-organisation. I guess the problem I see is that I think the
standard will assume unique objects, but in fact will get multiple objects.

Instead of using organisation number from bbreg, we could use UUIDs that
map a organisation or subset of organisation.
>
>> The import interface will just allow you to import data, so it
>> basically only supports POST requests.
> I suspect some kind of export interface will be needed too, to support
> feeding the FOI sites like oep.no with information.
>
The export format is specified in the main standard, chapter 6.13 I
think. That's for the entire database though. Integration with oep is
something we have to look at as well.

Thanks for you comments. I need to think about this a little more. I
think right now, you guys are most interested in seeing the POST
functionality, so you can play with uploading your existing objects into
the core.

Ownership of objects during import, I guess will be assigned to the
import-user. Organisational context is assumed by associating records
with fonds/series objects.

KDRS has a project at the moment where they want to see if they can get
a Noark 5 core produced that can allow municipalities and municipality
archives to provide search mechanisms for extractions. So this "innsyn"
functionality is definitely something that a number of people are
looking for

The question, that you rightly are asking, is can it not be handled via
the standard interface.  I need to think about that, but I think in
"innsyn" mode it might be difficult to reuse the standard interface.

 - Tom