In-page references incorrectly moved to other space


  • Create new page

  • Create Requirement 'TESTREQ'

  • Create reference to requirement 'TESTREQ' on same page

  • move page to different space

  • rename the requirement 'TESTREQ' -> 'TESTREQRENAMED' on Requirements page
    -> the requirement is correctly renamed but the in-page reference to it is not and show up as broken (red)

When looking closely, one can see the the in-page reference after moving to a new space is still stored as cross-space reference even though the definition was moved along with it. It is not clear to me why this reference does not yet show up as broken right after moving the page (after all, it is already pointing to the old space where the requirement does not exist any more...)

In our case, there already exists quite a number of in-page references that were moved between spaces, so apart from fixing the moving algorithm itself, there should ideally also be a means of correctly handling or silently cleaning up such corrupted data.






Adrien Ragot (Old account)
September 12, 2017, 3:55 PM

Hi Norbert,

I confirm:

  • If you move back and forward, it will update the references.

  • There is no problem with renaming requirements after moving them to another space,

  • However, as you correctly raised in RY-186, references to requirements from another space aren't renamed properly. This will be fixed with the next release.

Also, I'm adding 2 limitations to the Scaffolding question (updated here):

  • If requirements or links are declared inside a Scaffolding template, then moving the page to another space won't move the requirements properly and links will be broken (except links which are on the same page).

  • Requirements or links inside a Scaffolding template can't be automatically renamed.

There won't be any solution to support that.

Thank you very much for all those bug reports which help make the product more reliable and consistent.

Norbert Nemec
September 12, 2017, 1:36 PM

I understand the root cause now.
Problem is, though, that we already have a number of pages that were moved and have such references pointing to the old space and need a way to clean this up with reasonable effort.
Perhaps, if I move the page back to the old space and then again forward to where it should be with the fixed version of RY, the references will become local?

Adrien Ragot (Old account)
September 12, 2017, 1:30 PM

Let me check. For me it was the same root cause:

  • The root problem was, the link to the requirement was modified to point to the old space. You can confirm this when you edit the page: The 'link' macro is appended with the old space's key.

  • Requirement Yogi doesn't choke on that because there's a "redirection requirement" in the old space: In place of the old requirement, there's a link to the new space, so people are redirected to the new one. This is why RY doesn't show the reference as broken.

I'll check whether it's possible to properly rename them, but since I've fixed the root cause, there's no reason for a bug to happen.

Norbert Nemec
September 12, 2017, 1:24 PM

Thanks for fixing this so quickly!

Did you fix the code for moving or that for renaming requirements? In other words: Will requirements that were previously moved to a different space become correctly renameable now?





Norbert Nemec






Fix versions


Matter of weeks