* Introduce the PageLinkQuery
* Update page link query and some copyright
* Adds PageLinkCollectionRepresenter
* Introduces the endpoint /work_packages/id/wiki_page_links
* MetadaService tests, most of it is a work of fiction
* Adds urns for page link type improve some tests
* Removes mentions to view_wiki_page_links permissions
* Adds a test for multiple providers and same identifiers
---
Co-authored-by: Jan Sandbrink <j.sandbrink@openproject.com>
Update the OAuth section for the XWiki provider. Since XWiki provides only public clients, there are no client secrets passed in between OP and XWiki. Thus, the UI is, for now, just a mock with a client ID.
Limitations on the page_info query aside, this already works
the way that I'd expect this to work once we implemented real interactions
with wiki providers.
The macro markup is currently rather simple and builds on top of the existing
syntax for wiki links. The main downside is that during editing, it's not quite
clear to which page a macro related.
This macro format should be a good first iteration and if we have more time for
improvement available before release, we could replace it with an HTML-ized macro
similar to <mention> that is also properly rendered in CKEditor. However, this requires
a substantial amount of additional effort and is thus not quite feasible for a first iteration.
* Adds view and manage permissions on work package wiki links plus api path for wiki links
* Adds provisional method named #author? for easy handling of the rendering process
* Adds linkable to the response, not polymorphic yet
* Adds provider to the PageLink resource. Barebones Provider Representer
* Rename link parameters, make author? into render_author? as more intention revealing, skip render if linkable is not a WP
Includes all relevant entities we want to support in the beginning,
but does not yet include services and code designed to expose those
entities in any way.
Marcello Rocha