Links syntax fix

Summary

• Page properties (2 modified, 0 added, 0 removed)
• Objects (1 modified, 0 added, 0 removed)
  • ExtensionCode.ExtensionClass[0]

Details

Page properties

Author

...	...	@@ -1,1 +1,1 @@
1		-xwiki:XWiki.Admin
	1	+xwiki:XWiki.nikitapetrenko

Default language

...	...	@@ -1,0 +1,1 @@
	1	+en

ExtensionCode.ExtensionClass[0]

Description

...	...	@@ -19,7 +19,7 @@
19	19
20	20	The second mechanism is more generic, it consists in an extension right, that can be configured at any level (wiki, space or page) and define who can approve changes, when no explicit list of approvers is provided. So this right is never checked when the first mechanism is used.
21	21
22		-Note that some [[Approval Strategies>>#HApprovalstrategies]] might be adapted for only one of those mechanism.
	22	+Note that some [[Approval Strategies>>||anchor="HApprovalstrategies"]] might be adapted for only one of those mechanism.
23	23
24	24	{{version since="1.7"}}
25	25	A new administration option is available which enforces the fact that the approvers defined in the explicit lists do have also the approval right for the page they are defined for. The idea of this option is to allow to control who can be or not an approver by using the right.
...	...	@@ -31,7 +31,7 @@
31	31
32	32	In order to enable the delegation mechanism several things must be set in place:
33	33
34		-1. the XWiki user profile must be extended with one or several dedicated fields for defining the delegates (see the [[user profile documentation>>doc:Extension.User Module.User Profile Application.WebHome#HCustomizetheinformationtodisplayintheProfiletab]] for more information). Note that the new fields should be of type "List of users".
	34	+1. the XWiki user profile must be extended with one or several dedicated fields for defining the delegates (see the [[user profile documentation>>doc:Extension.User Module.User Profile Application.WebHome||anchor="#HCustomizetheinformationtodisplayintheProfiletab"]] for more information). Note that the new fields should be of type "List of users".
35	35	1. this or those fields must be filled for the different users
36	36	1. the delegation mechanism should be enabled in the administration, and the name of the new fields should be specified too
37	37
...	...	@@ -91,7 +91,7 @@
91	91
92	92	==== Limitations ====
93	93
94		-Note that right now some limitations exists for creating a page with some templates. The extension doesn't support templates which [[are using a hierarchy of pages>>doc:Extension.Administration Application#HUsingahierarchyofNestedPagesastemplate]], and template providers which are using [[something else than the "edit" action>>doc:Extension.Administration Application#HActiononCreate]].
	94	+Note that right now some limitations exists for creating a page with some templates. The extension doesn't support templates which [[are using a hierarchy of pages>>doc:Extension.Administration Application||anchor="#HUsingahierarchyofNestedPagesastemplate"]], and template providers which are using [[something else than the "edit" action>>doc:Extension.Administration Application||anchor="#HActiononCreate"]].
95	95
96	96	=== For requesting deletions ===
97	97
...	...	@@ -105,7 +105,7 @@
105	105
106	106	== Find change requests ==
107	107
108		-Lists of change requests are displayed in various places, using each time a [[Live Data>>doc:Extension.Live Data Macro.#HUserFeatures]] to allow an easy filtering and sorting of the results.
	108	+Lists of change requests are displayed in various places, using each time a [[Live Data>>doc:Extension.Live Data Macro.WebHome||anchor="#HUserFeatures"]] to allow an easy filtering and sorting of the results.
109	109
110	110	=== List of all change requests ===
111	111
...	...	@@ -227,7 +227,7 @@
227	227	=== Edit approvers ===
228	228
229	229	{{version since="1.2"}}
230		-If the [[minimum approvers configuration>>#HMinimumnumberofexplicitapprovers]] is set to a value higher than 0, then it's also possible to edit the approvers of a page directly inside a change request, through a Live Data action available in the list of file changes.
	230	+If the [[minimum approvers configuration>>||anchor="#HMinimumnumberofexplicitapprovers"]] is set to a value higher than 0, then it's also possible to edit the approvers of a page directly inside a change request, through a Live Data action available in the list of file changes.
231	231	This link will automatically open a modal to allow editing the list of approvers and save the changes directly in the new changes proposed in the change request.
232	232
233	233	Be aware that this feature applies different if the change is about a creation of a document or an edition of a document:
...	...	@@ -386,7 +386,7 @@
386	386	* **existing changes refreshed in a change request**: those events are triggered when a change request is refreshed, be it the entire change request or a specific document in it. People who watch the change request can receive the notification, and also people watching a refreshed document if it concerns a specific document,
387	387	* **the change request status has been updated**: those events are triggered when the status of a change request changed. People who watch the change request will receive it,
388	388	* **a new review has been made**: those events are triggered when a review has been performed on a change request. People who watch the change request will receive it
389		-* **a change request is stale**: those events are triggered when [[the dedicated scheduler>>#HSchedulers]] marks a change request as stale. People who watch the change request will receive it.
	389	+* **a change request is stale**: those events are triggered when [[the dedicated scheduler>>||anchor="#HSchedulers"]] marks a change request as stale. People who watch the change request will receive it.
390	390	* **a change request you are approver of is ready for review**: those events are triggered for new change request created as "ready for review", and for change request whose status changed to "ready for review". In both cases, the notifications only targets the explicit approvers.
391	391	* {{version since="1.17"}}**a comment is added**: those events are triggered whenever a new comment is added in a change request, be it a review comment, a global comment, or a diff comment.{{/version}}
392	392
...	...	@@ -401,7 +401,7 @@
401	401
402	402	A change request is itself an XWiki page which can be watched for events. We automatically add the change requests to the watched pages of some users following their preferences.
403	403
404		-A change request created by a user is automatically added to its list of watch pages, following its own [[autowatch configuration>>doc:Extension.Notifications Application.WebHome#HAutoWatch]].
	404	+A change request created by a user is automatically added to its list of watch pages, following its own [[autowatch configuration>>Extension.Notifications Application.WebHome||anchor="#HAutoWatch"]].
405	405
406	406	{{version since="1.4.5"}}
407	407	Explicit approvers of a page are now also automatically watching change request created for the pages they're approvers of, following their autowatch preferences. However, this does not apply for request for creating pages.
...	...	@@ -480,7 +480,7 @@
480	480
481	481	==== Require all approvers to approve ====
482	482
483		-This strategy is meant to be used when the extension is used with a predefined list of approvers for pages that are modified. It checks that all the approvers that are specified in the Approvers list of a change request have approved it, before authorizing the merge. However, if the change request does not rely on an explicit list of approvers, then the strategy automatically falls back to the [[Require only Approvals Strategy>>#HRequireonlyApprovals]].
	483	+This strategy is meant to be used when the extension is used with a predefined list of approvers for pages that are modified. It checks that all the approvers that are specified in the Approvers list of a change request have approved it, before authorizing the merge. However, if the change request does not rely on an explicit list of approvers, then the strategy automatically falls back to the [[Require only Approvals Strategy>>||anchor="#HRequireonlyApprovals"]].
484	484
485	485	=== Storage location ===
486	486
...	...	@@ -488,16 +488,16 @@
488	488
489	489	=== Merge user ===
490	490
491		-When configured, defines the user which will be used to actually perform the merge of all change requests: the rights will be checked on this user. By default the field is left blank, which means that the rights are checked with the user seeing the change request. For more information, check the [[documentation about mergers>>#HMergers]].
	491	+When configured, defines the user which will be used to actually perform the merge of all change requests: the rights will be checked on this user. By default the field is left blank, which means that the rights are checked with the user seeing the change request. For more information, check the [[documentation about mergers>>||anchor="#HMergers"]].
492	492
493	493	=== Duration to consider before notifying about stale change requests ===
494	494
495		-Defines the duration in days before a change request is considered as stale when it doesn't receive any activity. This configuration is used for [[the dedicated scheduler to detect stale change request>>#HDetectionandnotificationofstalechangerequests]].
	495	+Defines the duration in days before a change request is considered as stale when it doesn't receive any activity. This configuration is used for [[the dedicated scheduler to detect stale change request>>||anchor="#HDetectionandnotificationofstalechangerequests"]].
496	496	Note that putting 0 here will automatically disable this scheduler job. By default, the value is of 20 days.
497	497
498	498	=== Duration to consider before closing stale change requests ===
499	499
500		-Defines the duration in days before a stale change request is automatically closed. This configuration is used for [[the dedicated scheduler to close stale change request>>#HAutomaticclosingofstalechangerequests]].
	500	+Defines the duration in days before a stale change request is automatically closed. This configuration is used for [[the dedicated scheduler to close stale change request>>||anchor="#HAutomaticclosingofstalechangerequests"]].
501	501	Note that putting 0 here will automatically disable this scheduler job. By default, the value is of 5 days.
502	502
503	503	=== Use the creation date for stale change requests ===
...	...	@@ -510,7 +510,7 @@
510	510
511	511	=== Delegate Approvers ===
512	512
513		-As explained in the [[delegation mechanism>>#HDelegateApprovers]] it's possible to enable it, and the list of fields from XWikiUsers to consider for delegates must be also filled.
	513	+As explained in the [[delegation mechanism>>||anchor="#HDelegateApprovers"]] it's possible to enable it, and the list of fields from XWikiUsers to consider for delegates must be also filled.
514	514
515	515	=== Prevent authors to review their own change requests ===
516	516
...	...	@@ -518,7 +518,7 @@
518	518
519	519	=== Minimum number of explicit approvers ===
520	520
521		-Specifying a value here implies that explicit users approvers will be used (see the [[approvers documentation>>#HApprovers]]), and that it's mandatory to specify a minimum number of users approvers: this configuration does not apply on group of approvers.
	521	+Specifying a value here implies that explicit users approvers will be used (see the [[approvers documentation>>||anchor="#HApprovers"]]), and that it's mandatory to specify a minimum number of users approvers: this configuration does not apply on group of approvers.
522	522	Note that this option might be constraining since it will explicitly block creating a new page from a change request if the number of explicit user approvers is not respected.
523	523	By default no minimum is required.
524	524
...	...	@@ -565,7 +565,7 @@
565	565
566	566	The extension offers a mechanism to check that changes can be saved in a change request. It can be for checking compatibility of documents before adding them in an existing change requests, but it can also be to perform some custom checks on a filechange before the creation of a new change request.
567	567
568		-This mechanism is internally used to ensure to not add in same change request documents that are not sharing the same view rights (see [[the related documentation>>#HViewrightsynchronization]]). It can be extended so that external constraints are taken into account.
	568	+This mechanism is internally used to ensure to not add in same change request documents that are not sharing the same view rights (see [[the related documentation>>||anchor="#HViewrightsynchronization"]]). It can be extended so that external constraints are taken into account.
569	569
570	570	{{version since="1.6"}}
571	571	It's possible to decide the order of execution of those checkers by using the ##javax.component.Priority## annotation: the lower the value used, the higher the priority.
...	...	@@ -615,7 +615,7 @@
615	615
616	616	== Problems when using Change Request with XWiki Demo package ==
617	617
618		-You might experience some issues when using Change Request when [[installing a Standalone (Demo) Distribution>>documentation.xs.admin.installation.install-standalone-demo-distribution.WebHome]], and more specifically when editing first version of pages included in this distribution (e.g. ##Main.WebHome## or ##Sandbox.WebHome##).
	618	+You might experience some issues when using Change Request when [[installing a Standalone (Demo) Distribution>>documentation.xs.admin.installation.methods.install-standalone-demo-distribution]], and more specifically when editing first version of pages included in this distribution (e.g. ##Main.WebHome## or ##Sandbox.WebHome##).
619	619	For example, the Rendered diff feature might not work properly, or you might have problems when merging / resolving conflicts. You can follow the status of this limitation by checking this ticket: https://jira.xwiki.org/browse/CRAPP-219
620	620
621	621	== Rename of documents ==