* Remove the `render_author` method as it is unnecessary
* Add the necessary paths, clarify the param to wiki_provider path
* Rework the representers, merge upstream changes to the create contract
* Remove unnecessary mixin and make everything read-only
* Create Endpoint for POST /api/v3/wiki_page_links
* Incorporates @Kharonus feedback in testing multiple page link creation
This change is mostly wiring up things, but leaves some things open:
* we still need to use a proper create service (to be built)
* the modal needs to use a treeview to select the identifier
(requires fetching of a list of available wiki pages)
- https://community.openproject.org/work_packages/73354
- add confirmation dialog component
- add delete action and controller
- add action to permission
- add page link data to page info object
- add additional routes
- NOT ADDED: deletion service
* 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>
This creates inline page links the way they are intended to exist:
When a work package contains a link to a wiki page in its description,
these links should also be represented as inline wiki page links.
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
Effectively we only want to allow disabling the internal wiki
for now, but we'll have to answer certain usability questions
on what happens when a provider is deleted/disabled anyways, so
we'll make it technically possible to disable any provider, even
if we might not offer it for all of them out of the box.
The most likely starting scenario to have no wikis tab is that
the internal wikis are disabled and no external wiki is configured.
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.
Jan Sandbrink