Correct rel and _links for ny-arkiv?

[Petter Reinholdtsen]

[Thomas Sødring]
> Taking a look at this I think I've mixed up the rels for advertising
> arkivstrutur:
>
>  http://rel.kxml.no/noark5/v4/api/arkivstruktur/
>
> with the rel used when creating a new fonds object:
>
>  http://rel.kxml.no/noark5/v4/api/administrasjon/ny-arkiv/
>  http://rel.kxml.no/noark5/v4/api/arkivstruktur/ny-arkiv/
>
> It's an easy fix, but I'll do it as described below.

Ah, good.

> It's intentional, proper _links should be in place in 0.2. One of the
> things I understand a Noark core should do according to the standard
> is that it should return links of what the user is able to do based on
> access rights.

Yes.

> So I have to write a handler class that populates these links with
> correct values. This class also needs to interact with some
> role/action description service. As far as I can tell, that is not
> specified anywhere in Noark, nor should it be as it's very application
> and domain specific.

Well, they could have standardized on LDAP directory groups, as it is
the common way to do this across a lot of sites, at least as an optional
specification.  But I agree, it is hard to make a generic solution for
this.

> I will try and publish a working version of the 0.2 branch which has
> the shell of a handler that at least can give the self _links.  I have
> not used git that much before and am a little worried about how to
> merge 0.1 with 0.2 so that 0.2 has all the updates from 0.1. I could
> try a merge but I’m afraid that I’ll break the codebase in some
> way. You have commented that I "kill" codebases before. I think this
> might be one of those reasons I do that. It's easier to manually pull
> everything together and starting again than merging into a mess.

You should do this using a test branch based on 0.2, see below.  When
you want to merge 0.2 into master/0.1, you should follow the alternative
procedure based on the master branch.

> So any tips on how to merge 0.1 and 0.2 would be appreciated!

There are two ways to test if this is going to work without burning any
bridges.  It is a matter of taste if you want to do it one way or
another.  Way way, based on 0.1:

 1) do a test merge by creating a new branch based on 0.1:
    'git checkout master; git checkout -b testmerge'
 2) merge the 0.2 branch into this new test branch and clean up any
    merge conflicts:
    'git merge 0.2-REST-Interface'
    [clean up, finish with 'git commit']
 3) Once you are happy with the result in the testmerge branch, repeat
    the process using the master branch instead (or merge the testmerge
    branch into master, but this can cause problems if someone commited
    to the master branch while you tested).

If you want to base it on the 0.2 branch instead, do 'git checkout
0.2-REST-Interface; git checkout -b 'testmerge; git merge master'
instead.  You might want to consider 'git rebase' in this case, but it
is in general

There is also 'git cherry-pick' if you only want to merge selected
commits from the 0.2 branch into master.  This might make merging the
two branches a bit harder in the future, but we go from easy to
annoying, it is not really problematic. :)

-- 
Happy hacking
Petter Reinholdtsen