profile
viewpoint

sphinx-contrib/confluencebuilder 160

Confluence Markup Builder Plugin for Sphinx

jdknight/phpbb-3.1-recaptcha 2

reCAPTCHA for phpBB v3.1.6 to v3.1.9

jdknight/sphinx-alice-theme 1

Provides the Alice theme for Sphinx projects.

jdknight/t2ds 1

Tribes 2 Dedicated Server

jdknight/ums.ccml 0

[obsolete] Custom Category Media Library for Universal Media Server and PS3 Media Server

issue commentsphinx-contrib/confluencebuilder

Edit on Github/Bitbucket link

It may be ideal to add a feature will an external "Edit" reference to a document's source. Looks like a common enough feature, especially with the predominate ReadTheDocs theme.

Flagged as an enhancement. You (and anyone else) is free to try to contribute such a feature to this extension -- I would be willing to help review/etc. to get this feature in for others to use. Some recommendations if a feature is planned would be as follows:

  • It would be nice to ensure such a feature was generic to what source management is being used (I assume this is considered since both GitHub and BitBucket are being referenced; but just want to ensure other populate tools (like GitLab) or even custom environments with unique source environments (e.g. non-Git) can easily set a reference location).
  • It may be good to investigate how ConfluenceNavigationNode is used in the implementation, since it somewhat relates to the implementation which could be made for this feature.

Note that a current workaround, if desired, would be to take advantage of the confluence-header-file option. A configuration could use this to add a notice/link to indicate that the pages are not really intented to be edited locally (for example).

sp1thas

comment created time in 5 days

issue commentsphinx-contrib/confluencebuilder

Support as target of intersphinx

@Holi0317, it may be safe to say this extension does not properly work with the sphinx.ext.intersphinx extension. I cannot say I have used the intersphinx extension myself, but maybe it would be possible to generate a compatible objects.inv file on a full process event (although, I only have done a quick pass at the front-end documentation without knowing the full effort involved).

One possible limitation that might exist is the inability to support the intersphinx_mapping configuration, since this extension is limited to adding files as attachments on pages -- so there may not be a graceful way to link to an objects.inv file.

Holi0317

comment created time in 5 days

issue commentsphinx-contrib/confluencebuilder

jira_issue directive with html builder

The directive implementations introduced by this extension are specifically designed for this extension. If the content being generated uses the directives provided in this extension but also want to handle other builder types, there are ways to get this to work. The current solution available is to use the only directive, which would allow you to exclude the custom directives from this extension. For example:

.. only:: confluence and singleconfluence

    .. jira_issue:: TEST-123

Although, I can agree this does not look pretty and a bit annoying if you want to build against the standard builders (html, latex and text). This extension should see if there is a way to gracefully handle standard builders to suppress the content in these nodes.

Note that the directives introduced are not really designed to support the standard builder types (let alone any other builder types -- would be out of the scope for this extension). There is flexibility for other extensions to override the node implementations (if desired) -- this extension only registers the internal nodes if they are not already registered (for advanced cases/external extensions to work with).

Another workaround, if you want to avoid editing the content itself, would be to suppress or manipulate the node content yourself (in a manner similar to what you mentioned above). For example, to ignore the jira_issue directives in the html builder, a user could do the following in their configuration:

from docutils import nodes
from sphinxcontrib.confluencebuilder.nodes import jira_issue

def setup(app):
    def visit_ignore(self, node):
        raise nodes.SkipNode
    app.add_node(jira_issue,
        html=(visit_ignore, None))

One can even be more bold an try to create content based off the node itself, but note that the node implementations are subject to change (e.g. there will be some future changes to address an issue with the JIRA-based implementation and the singleconfluence builder; 860d6e82f412ea02a515cd4583a60db5b1dc95aa).

Cielquan

comment created time in 9 days

issue closedsphinx-contrib/confluencebuilder

RFC: new implementation header

@tonybaloney, I am pondering on updating the default header format for this extension. An existing example (pulled from translator.py) is the following:

# -*- coding: utf-8 -*-
"""
    :copyright: Copyright 2016-2019 by the contributors (see AUTHORS file).
    :copyright: Copyright 2018 by the Sphinx team (sphinx-doc/sphinx#AUTHORS)
    :license: BSD-2-Clause, see LICENSE for details.
"""

I am hoping to possibly change it to the following (for the above example):

# -*- coding: utf-8 -*-
# Copyright 2016-2019 Confluence Builder for Sphinx Contributors (see AUTHORS).
# Copyright 2018 by the Sphinx team (sphinx-doc/sphinx#AUTHORS)
# Licensed under BSD-2-Clause (see LICENSE).

Any objections/comments?

closed time in 16 days

jdknight

delete branch sphinx-contrib/confluencebuilder

delete branch : feature/support-inheritance-diagrams

delete time in 16 days

push eventsphinx-contrib/confluencebuilder

James Knight

commit sha 8912f2718790db68944a0aab04ef5da1dbf8d807

refactor builders to share doctree preparation implementation There is a series of builder calls which are being duplicated between the standard builder and the single builder. These calls are responsible for manipulating a prepared doctree instance before processing -- such as replacing math blocks with images. Instead of duplicating these calls, introduce a new shared `_prepare_doctree_writing` call which any builder can use to ready a doctree instance. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 01f97a67b98d598a6f5a542869f8542d08fd931b

builder: handle sphinx.ext.inheritance_diagram nodes Provide support for an internal Sphinx extension `inheritance_diagram` by pre-processing diagrams and replaced with respective images. Typically, node support from `sphinx.ext.inheritance_diagram` would be added to the builder; however, this extension renders graphs during the translation phase (which is not ideal for how assets are managed in this extension). Instead, this implementation just traverses for inheritance diagrams, generates renderings and replaces the nodes with image nodes (which in turn will be handled by the existing image-based implementation). Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha ebdf5bf561e7dd49e91c7b66a9dfdc5ff838698d

doc: listing sphinx.ext.inheritance_diagram as a supported extension Adding the internal extension `sphinx.ext.inheritance_diagram` to the list of supported extensions in the markup document. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 9ab9e8c04246c73d901ef9965e0f3445d1638e4d

builder: remove inheritance diagram nodes on error Removes inheritance diagram nodes in the event that they cannot be processed. The failure cases will generate warnings for the user to act on, and the removal of the nodes will allow a document to continue to be built without generating an "unknown node" error. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 6e6edbb64260ea09858eb844dd46c79c7697267e

Merge pull request #335 from sphinx-contrib/feature/support-inheritance-diagrams builder: handle sphinx.ext.inheritance_diagram nodes

view details

push time in 16 days

PR merged sphinx-contrib/confluencebuilder

builder: handle sphinx.ext.inheritance_diagram nodes

Provide support for an internal Sphinx extension inheritance_diagram by pre-processing diagrams and replaced with respective images. Typically, node support from sphinx.ext.inheritance_diagram would be added to the builder; however, this extension renders graphs during the translation phase (which is not ideal for how assets are managed in this extension).

Instead, this implementation just traverses for inheritance diagrams, generates renderings and replaces the nodes with image nodes (which in turn will be handled by the existing image-based implementation).

This pull request also refactors some shared implementation between the standard builder and the single builder. These calls are responsible for manipulating a prepared doctree instance before processing -- such as replacing math blocks with images. Refactoring this ahead of time allows the _replace_inheritance_diagram call be easily be invoked by all builder types.

See also #308.

+82 -27

0 comment

3 changed files

jdknight

pr closed time in 16 days

delete branch sphinx-contrib/confluencebuilder

delete branch : bugfix/handle-new-attachment-parsing

delete time in 17 days

push eventsphinx-contrib/confluencebuilder

James Knight

commit sha afe03c6edb7627ae39599802cb7b3e64bf495d80

storage: do not inject newline inside attachment tag It has been observed that (in at least) Confluence Cloud that when a newline is injected in the `ri:attachment` tag, typically only when `ri:content-title` is used, that Confluence will report a 500 error when publishing. This commit removes the suffix injection (from an explicit newline to an implicit empty/none) and publish events appear to work as expected. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 0fde922973a3d068dc67e696ad4ee20a1fb27e9d

test: adjust for new attachment formatting The format for attachments has changed in a recent commit [1]; adjusting the expected test cases to match the new formatting. [1]: afe03c6edb7627ae39599802cb7b3e64bf495d80 Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha afb81003c19f2edbce37263f20dc02184955d62c

Merge pull request #334 from sphinx-contrib/bugfix/handle-new-attachment-parsing storage: do not inject newline inside attachment tag

view details

push time in 17 days

PR merged sphinx-contrib/confluencebuilder

storage: do not inject newline inside attachment tag

It has been observed that (in at least) Confluence Cloud that when a newline is injected in the ri:attachment tag, typically only when ri:content-title is used, that Confluence will report a 500 error when publishing. This commit removes the suffix injection (from an explicit newline to an implicit empty/none) and publish events appear to work as expected.

See also #317.

+6 -12

0 comment

4 changed files

jdknight

pr closed time in 17 days

push eventsphinx-contrib/confluencebuilder

James Knight

commit sha 9ab9e8c04246c73d901ef9965e0f3445d1638e4d

builder: remove inheritance diagram nodes on error Removes inheritance diagram nodes in the event that they cannot be processed. The failure cases will generate warnings for the user to act on, and the removal of the nodes will allow a document to continue to be built without generating an "unknown node" error. Signed-off-by: James Knight <james.d.knight@live.com>

view details

push time in 17 days

issue commentsphinx-contrib/confluencebuilder

NotImplementedError: unknown node: inheritance_diagram

Initial support for this extension is being introduced in #335.

For this example:

.. inheritance-diagram:: sphinx.ext.inheritance_diagram.InheritanceDiagram

Should render as following (with additional changes to inheritance_node_attrs):

image

Note that only partial capabilities can be supported with these diagrams. For example, image map (links on each node) do not appear to be supported in Confluence at this time.

jannismain

comment created time in 17 days

PR opened sphinx-contrib/confluencebuilder

builder: handle sphinx.ext.inheritance_diagram nodes

Provide support for an internal Sphinx extension inheritance_diagram by pre-processing diagrams and replaced with respective images. Typically, node support from sphinx.ext.inheritance_diagram would be added to the builder; however, this extension renders graphs during the translation phase (which is not ideal for how assets are managed in this extension).

Instead, this implementation just traverses for inheritance diagrams, generates renderings and replaces the nodes with image nodes (which in turn will be handled by the existing image-based implementation).

This pull request also refactors some shared implementation between the standard builder and the single builder. These calls are responsible for manipulating a prepared doctree instance before processing -- such as replacing math blocks with images. Refactoring this ahead of time allows the _replace_inheritance_diagram call be easily be invoked by all builder types.

See also #308.

+80 -27

0 comment

3 changed files

pr created time in 17 days

PR opened sphinx-contrib/confluencebuilder

storage: do not inject newline inside attachment tag

It has been observed that (in at least) Confluence Cloud that when a newline is injected in the ri:attachment tag, typically only when ri:content-title is used, that Confluence will report a 500 error when publishing. This commit removes the suffix injection (from an explicit newline to an implicit empty/none) and publish events appear to work as expected.

See also #317.

+6 -12

0 comment

4 changed files

pr created time in 17 days

delete branch sphinx-contrib/confluencebuilder

delete branch : refactor-translator

delete time in 17 days

push eventsphinx-contrib/confluencebuilder

James Knight

commit sha 9c7d64b3f086ec74bd7773a246c0dad4ee563fb0

translator: move implementation Moving the translator implementation into its own folder. This is to help prepare for planned changes where more than just a storage-format translator is provided by this extension. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 0219050ff8509ca1d5aaae6169d9ed9b12e67dc1

translator: refactor storage-format implementation into own translator Refactoring the existing translator to split the implementation between a base translator (`ConfluenceBaseTranslator`) and a new storage format-specific translator (`ConfluenceStorageFormatTranslator`). This is to help prepare for prospect changes where a new translator aims to support the Atlassian Document format. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 3d42b90102c8b5c54e84bf15311310151b5aa0a0

Merge pull request #329 from sphinx-contrib/refactor-translator translator: refactor translator

view details

push time in 17 days

PR merged sphinx-contrib/confluencebuilder

translator: refactor translator

Refactoring the existing translator to split the implementation between a base translator (ConfluenceBaseTranslator) and a new storage format-specific translator (ConfluenceStorageFormatTranslator). This is to help prepare for prospect changes where a new translator aims to support the Atlassian Document format.

+318 -264

0 comment

4 changed files

jdknight

pr closed time in 17 days

issue commentsphinx-contrib/confluencebuilder

publishing fails for multiple documents referencing same image

Found it.

It appears to be an issue with how Confluence parses the elements inside an ac:image tag. When assets are shared between multiple pages, only a single asset is published (into the root document). This requires the attachment markup to point to the page which holds the attachment. The original implementation would be structured as follows:

<ac:image>
<ri:attachment ri:filename="confluence.png"><ri:page ri:content-title="ztest" />
</ri:attachment>
</ac:image>

However, this now results in a 500 error. By removing the newline found inside ri:attachment, the publish event will succeed:

<ac:image>
<ri:attachment ri:filename="confluence.png"><ri:page ri:content-title="ztest" /></ri:attachment>
</ac:image>

I will adjust all the markup building attachments to no longer inject a newline character (which will require updating a series of test logic as well).

g-simmons2

comment created time in 17 days

Pull request review commentsphinx-contrib/confluencebuilder

translator: refactor translator

+# -*- coding: utf-8 -*-+"""+:copyright: Copyright 2016-2020 Sphinx Confluence Builder Contributors (AUTHORS)+:license: BSD-2-Clause (LICENSE)+"""++from ..exceptions import ConfluenceError

All relative imports related to this change request have been switched to absolute imports.

Over time, I will try to replace other relative imports in this extension.

jdknight

comment created time in 17 days

push eventsphinx-contrib/confluencebuilder

Jesse Tan

commit sha 202b91dfdd696586e964162c16b0113547629dbe

Fix images with * extension in singleconfluence builder Signed-off-by: Jesse Tan <j.tan@activevideo.com>

view details

Jared Curtis

commit sha 5fa4a514343a138247f274ff580db781dc408b25

ISSUE-313 POC of adding confluence metadata labels to pages This commit introduces a new directive `confluence_metadata` that has a parameter `labels`. These labels are added to the api JSON payload when creating or updating a page. Any labels added directly within Confluence will be maintained when publishing. resolves #313 Signed-off-by: Jared Curtis <jcurtis@xmatters.com>

view details

James Knight

commit sha 91cd379be3e436f6c79d6a2749c36cc8a3a76d1e

publisher: ignore label-fetch on dry-run Page information for a verbose dry-run is fetching label information (`metadata.labels`) without it being used to provide feedback on a dry-run. Adjusting the request to exclude this information. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 7dd59626f5bb400217a6f895ba7de921f2081b65

directives: refactor metadata directive The initial implementation of ConfluenceMetadataDirective most likely used the existing JIRA directives as a reference for implementation. The JIRA directive implementation uses a base directive to help deal with various types of JIRA directive definition. The metadata directive also defined its own base directive; however, (at this time) there does not appear to be a need for a base directive as there is only a single use for this type. Refactoring the implementation now to be a bit smaller. This change also sorts the directive to the top of the page. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 282d0c61df307772a7e8387ca26c345b4b6e28fa

rework label feature restrictor The initial implementation for page label support uses the macro-restrictor feature to disable its use; however, this feature is not a macro. At the same time, label capabilities could be disabled by an administrator as well. Therefore, it would still be ideal if a publisher had the ability to prevent an attempt to adjust labels on a page. The first part of this change tweaks the advanced configuration item `confluence_adv_restricted_macros` which will be renamed to `confluence_adv_restricted` to be more generic. Since this is an advanced/undocumented feature, there is less concern for configuration changes between revisions of this extension (however, it may be ideal to note the change in the changelog when a new release is made). With the restriction feature being more generic, we can use the simple tag/quirk list to help disable the label interaction. The original tag created was named `confluence_metadata`; however, this will be changed to `labels` to be more specific on what is being restricted. The final change will deal with where the restrictions take place. The original implementation would only disable accepting the new label content at the page-level. This would still result in the publish attempt to query for labels and attempt to re-set labels (which is not really required and may cause an API failure if labels are restricted). Instead, the translator will also accept new label information when processing a document, but the restriction flag will be used to prevent a publishing event from query and attempting to set label information. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 9195baac4b2fde93aebbf996a96ddd85e1c751b7

refactor labels to provided by builder The original label implementation would have a publisher pull label information for a page. In an attempt to have the publisher implementation find this information, this commit adjusts the store call to have the builder provide this information. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 9b40ccbfcf2055c4c1806cab7ec225f5bf919c7b

allow label appending to be configurable The original label support would always append labels on an existing page. In select cases, a user may wish to clear any legacy labels on a published set. This commit introduced the `confluence_append_labels` option (enabled by default) which will decide whether or not labels will be appended to completely re-written. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 5d784cea2d875c4b27b5ba51016dfb3e30fc9b0d

doc: document new append labels option Provides user documentation outlining the capabilities provided through the recently added `confluence_append_labels` option. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 860d6e82f412ea02a515cd4583a60db5b1dc95aa

support per-document labels The following adjusts the label mechanics to have the builder implementation process all prospect metadata information for a document instead of passing metadata information between a translator and builder via configuration options. This change is being made to first prevent the translator from manipulating the configuration context (which is not necessarily ideal). The original request for label support outlined a desired to have a per-page label assignment. This commit brings this capability by now tracking metadata information at a per-document level (instead of a single last-read metadata to be applied to all pages). Note that this change does prevent the ability for a user to apply a "global" label set to all pages, which was implicitly capable before. A future commit can be made to allow setting global labels via a configuration option. Note this change also introduces some corrections/improvements to the metadata node processing. First, this change provides a more flexible parsing of label data provide from a document -- this includes supporting multilines of labels and dealing with additional whitespaces. Second, a correction has been made to ensure node information can be properly shared when assembling a single document for the `singleconfluence` builder. The directive now populates the attribute container which allows stored information to be copied between a cloned node. The implementation issue exists in the existing JIRA-based implementation, which this implementation appears to be based off of (corrections to the JIRA implementation should be made in the future). Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha a32c2944d378e130b02ba8e428f71e07ca656ef6

introduce global labels The original label support for this extension would accept a single metadata directive to apply label information to all published pages. This was later adjusted to have individual directives only configure labels for specific documents they were contained in. While this may be ideal for most users, individuals wanting to apply a shared label for all published documents required alternative means (e.g. includes). This commit introduces the ability to configure a shared/global label to be applied to each published document. When a user configures `confluence_global_labels`, a list of string elements, each element will used as a label to add to each published document. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 788493df2631d8250f4f86e5f58398cecc0a0cb7

doc: provide information on new label capabilities Provides user documentation outlining the capabilities provided through the recently added `confluence_global_labels` option and `confluence_metadata` directive. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha fed91343da1add5e6eccc14d9557c02faf832511

test: correct restrictor tests A recent change [1] which adjusts the implementation of restricted features did not have respective changes made to the testing implementation; correcting. [1]: 282d0c61df307772a7e8387ca26c345b4b6e28fa Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 2242a01eeac51ebeb66c8cd4ad469f4c59791026

Merge pull request #332 from jaredcurtis/feature/labels ISSUE-313 POC of adding confluence metadata labels to pages

view details

James Knight

commit sha b4df2afe6ba362596fbddf994c44422145f3b7d3

publisher: introduce the only-new feature Adding a new feature which allows users to configure this extension to restrict changing existing content on a Confluence space. When `confluence_publish_onlynew` is set to `True`, only new pages/attachments can be added to a target space. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 4178d3b9154ccb8751eb1c8b52fc9b41182f2cb6

doc: document only-new feature Adding to the configuration document the recently added only-new feature. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha dbd75441243db34caacd4d8d7dd4f4b2f8f46454

Merge pull request #327 from sphinx-contrib/feature/onlynew publisher: introduce the only-new feature

view details

James Knight

commit sha bf4b7ede09dbff8d113f30b57cc40d759f5428a0

Merge pull request #311 from jessetan/singleconfluence-image-star Fix images with * extension in singleconfluence builder

view details

James Knight

commit sha 9c7d64b3f086ec74bd7773a246c0dad4ee563fb0

translator: move implementation Moving the translator implementation into its own folder. This is to help prepare for planned changes where more than just a storage-format translator is provided by this extension. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 0219050ff8509ca1d5aaae6169d9ed9b12e67dc1

translator: refactor storage-format implementation into own translator Refactoring the existing translator to split the implementation between a base translator (`ConfluenceBaseTranslator`) and a new storage format-specific translator (`ConfluenceStorageFormatTranslator`). This is to help prepare for prospect changes where a new translator aims to support the Atlassian Document format. Signed-off-by: James Knight <james.d.knight@live.com>

view details

push time in 17 days

issue commentsphinx-contrib/confluencebuilder

Support for templates

@zcicala, the answer you are looking depends on what you are considering a template/layout for your use case.

What this extension attempts to provide is a translation between reStructuredText/Sphinx markup to markup which is supported by Confluence. How the markup is rendered/styled is typically managed by the theme configured in the Confluence space on the Confluence instance being published to. Dealing with Confluence themes will most likely never be part of this extension's world since installation/configuration of themes are for elevated users in a Confluence instance.

If you are looking for looking for templating content (i.e. not look-and-feel), you may want to investigate using reStructuredText's include and replace directives (for example, consult this answer on StackOverflow). You may be able to find more examples online by searching for "reStructuredText templating" -- if you attempt to search for "Sphinx templating", you will most likely only find look-and-feel-related content. That being said, templating content is not really something this extension manages (it mainly deals with parsing/translation and not actual content building).

I hope this information helps.

zcicala

comment created time in 18 days

issue commentsphinx-contrib/confluencebuilder

Sphinx Page Contents not working

@shivav, indeed there is an issue when attempting to use reStructuredText's contents directive. Typically, most users have been using Sphinx's toctree instead; however this extension should be attempting to support both types of table-of-contents capabilities.

Will try to find a solution.

Note that the contents directive should work at this time with the local option (if the desire is only for local page headings only):

.. contents::
   :local:
shivav

comment created time in 18 days

issue commentsphinx-contrib/confluencebuilder

Unsupported Confluence API call

@svantis, a 500 series error from a Confluence instance can mean multiple things. Unfortunately, to get the explicit error (if any), would be to consult the logs on the instance itself (which may not always be available for most users).

Typically though, the primary reason why a 500 error has been observed in the past is when there is an attempt to make a parent page a child of child page. For example, if you had a container page on a space called parent and also have a page in your documentation set called parent, this could put you in a situation where this extension will attempt to move a page into an invalid state. This may be the case since you have been able to publish while setting a prefix value.

Other than that, I do not see much else that could provide a hint at what the issue is. You could attempt to invoke the build request with more verbose messages (appending -vvv on the command line) and seeing if it reveals anything helpful.

svantis

comment created time in 18 days

pull request commentsphinx-contrib/confluencebuilder

Fix images with * extension in singleconfluence builder

Sorry for the long delay here; thanks for the fix.

The whole "preparation" phase is incorrect in the single-builder (which you address here for images by moving post_process_images), I will need to move over _replace_math_blocks as well.

jessetan

comment created time in 18 days

push eventsphinx-contrib/confluencebuilder

Jesse Tan

commit sha 202b91dfdd696586e964162c16b0113547629dbe

Fix images with * extension in singleconfluence builder Signed-off-by: Jesse Tan <j.tan@activevideo.com>

view details

James Knight

commit sha bf4b7ede09dbff8d113f30b57cc40d759f5428a0

Merge pull request #311 from jessetan/singleconfluence-image-star Fix images with * extension in singleconfluence builder

view details

push time in 18 days

PR merged sphinx-contrib/confluencebuilder

Fix images with * extension in singleconfluence builder

If an image uses * as an extension, the non-single confluence builder finds a file with the correct extension automatically (#217). This does not work with the singleconfluence builder, it produces the following error:

Exception occurred:
  File "<some path>/confluencebuilder/sphinxcontrib/confluencebuilder/util.py", line 34, in hashAsset
    with open(asset, 'rb') as file:
FileNotFoundError: [Errno 2] No such file or directory: '<some path>/image.*' 

This PR shuffles some lines to make this work in the singleconfluence builder and adds a test.

+97 -2

0 comment

3 changed files

jessetan

pr closed time in 18 days

issue closedsphinx-contrib/confluencebuilder

feature request: do not overwrite existing pages

Hello,

I can't find an option which check if a page in a confluence space already exists and avoids an unwanted overwrite ( maybe it could skip with a warning message ) . At the moment a publish will just overwrite anything even if was manually written.

Thanks

closed time in 18 days

extremoburo

issue commentsphinx-contrib/confluencebuilder

feature request: do not overwrite existing pages

With the recent merge of #327 into master, the configuration option confluence_publish_onlynew should provide a capability to prevent overwriting existing pages on publication. This feature should also be made available next stable release.

extremoburo

comment created time in 18 days

delete branch sphinx-contrib/confluencebuilder

delete branch : feature/onlynew

delete time in 18 days

push eventsphinx-contrib/confluencebuilder

James Knight

commit sha b4df2afe6ba362596fbddf994c44422145f3b7d3

publisher: introduce the only-new feature Adding a new feature which allows users to configure this extension to restrict changing existing content on a Confluence space. When `confluence_publish_onlynew` is set to `True`, only new pages/attachments can be added to a target space. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 4178d3b9154ccb8751eb1c8b52fc9b41182f2cb6

doc: document only-new feature Adding to the configuration document the recently added only-new feature. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha dbd75441243db34caacd4d8d7dd4f4b2f8f46454

Merge pull request #327 from sphinx-contrib/feature/onlynew publisher: introduce the only-new feature

view details

push time in 18 days

PR merged sphinx-contrib/confluencebuilder

publisher: introduce the only-new feature

Adding a new feature which allows users to configure this extension to restrict changing existing content on a Confluence space. When confluence_publish_onlynew is set to True, only new pages/attachments can be added to a target space.

+57 -0

0 comment

3 changed files

jdknight

pr closed time in 18 days

issue commentsphinx-contrib/confluencebuilder

Support for labels on pages

This feature is now available on master through the confluence_global_labels configuration option and the confluence_metadata directive. Thanks for the contributions made to help making this feature available for everyone. This feature should also be made available next stable release.

edthamm

comment created time in 18 days

push eventsphinx-contrib/confluencebuilder

James Knight

commit sha c2ec846fd7692bab1bb1a392787751a9a16a8cc8

assets: provided fallback for asset paths Asset-based nodes processed by this extension will either provide a URI to a relative or absolute path. Part of the asset manager's process will attempt to determine the absolute path of a resource for future work. In the case for a relative path, a relative path is assumed to be located alongside the source content; however, this is not always the case for extensions which generate assets into the build output directory but only provide a relative path to the asset. To help deal with this case, when a relative path based off a documentation's source directory cannot be found, the process will fallback to a path based off the user-defined output directory. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 3add59663c69802778639d7421a2d825316e9780

correct hook with multiple builders For the standard builder in this extension, the `doctree-resolved` event is observed to help populate images which may be generated when a doctree has been resolved. When the single builder was introduced in this extension, the builder attribute (`app.builder`) no longer appears to be always initialized. Before type-checking the builder being used, hook on the `builder-inited` event to ensure the builder has been initialized. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha f31382a6b83e491bde331061183f20ee46feb8c3

rest: define user agent for request calls Define a user agent string for all request calls generated by this extension. This is solely to help prevent issues observed in CONFCLOUD-69720 [1] (while should already be resolved on Confluence Cloud). [1]: https://jira.atlassian.com/browse/CONFCLOUD-69720 Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 78ed581a4fe3715c868ee5e1c558d99c8af54c8b

Merge pull request #325 from sphinx-contrib/feature/define-user-agent rest: define user agent for request calls

view details

James Knight

commit sha 7105c7c2b809296fda50565b358e6d1a3f5c14d4

test: adjust c-domains check for new formatting Sphinx v3+ appears to adjust the positioning of the dereference operator. Adjusting the C-domains check to accommodate this. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 9f3b3871fcb7ba994723cc8815144f1d3d486b94

tox: manage supported sphinx versions Adjusting the tox configuration to test for the more recent releases of Sphinx. Since this extension aims to support a least five latest releases of Sphinx, dropping tests for some older versions. Note, that Sphinx v1.8.x series will still be tested against since it is the only version still supported on Python 2, which will continue to have support for at least a couple of more months. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha b356238178fcd5a1baabe9ec0359777e6c7378b5

.travis.yml: adjusted for new sphinx versions The tox configuration has been adjusted with a new version of Sphinx versions to test against. Adjusting the automated building to invoke these accordingly. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 045da56536896a30f024f41d36002e3d05dbccab

Merge pull request #324 from sphinx-contrib/bugfix/correct-hook-with-multiple-builders correct hook with multiple builders

view details

James Knight

commit sha 1468544748b44f77788e473ed47a1a89bea9db85

Merge pull request #326 from sphinx-contrib/bugfix/fallback-asset-path assets: provided fallback for asset paths

view details

James Knight

commit sha a4978cb5ec1d6ebb9adb729dd84d6455d2fafa8c

Merge pull request #328 from sphinx-contrib/test-additional-sphinx-versions test additional sphinx versions

view details

Jared Curtis

commit sha 5fa4a514343a138247f274ff580db781dc408b25

ISSUE-313 POC of adding confluence metadata labels to pages This commit introduces a new directive `confluence_metadata` that has a parameter `labels`. These labels are added to the api JSON payload when creating or updating a page. Any labels added directly within Confluence will be maintained when publishing. resolves #313 Signed-off-by: Jared Curtis <jcurtis@xmatters.com>

view details

James Knight

commit sha 91cd379be3e436f6c79d6a2749c36cc8a3a76d1e

publisher: ignore label-fetch on dry-run Page information for a verbose dry-run is fetching label information (`metadata.labels`) without it being used to provide feedback on a dry-run. Adjusting the request to exclude this information. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 7dd59626f5bb400217a6f895ba7de921f2081b65

directives: refactor metadata directive The initial implementation of ConfluenceMetadataDirective most likely used the existing JIRA directives as a reference for implementation. The JIRA directive implementation uses a base directive to help deal with various types of JIRA directive definition. The metadata directive also defined its own base directive; however, (at this time) there does not appear to be a need for a base directive as there is only a single use for this type. Refactoring the implementation now to be a bit smaller. This change also sorts the directive to the top of the page. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 282d0c61df307772a7e8387ca26c345b4b6e28fa

rework label feature restrictor The initial implementation for page label support uses the macro-restrictor feature to disable its use; however, this feature is not a macro. At the same time, label capabilities could be disabled by an administrator as well. Therefore, it would still be ideal if a publisher had the ability to prevent an attempt to adjust labels on a page. The first part of this change tweaks the advanced configuration item `confluence_adv_restricted_macros` which will be renamed to `confluence_adv_restricted` to be more generic. Since this is an advanced/undocumented feature, there is less concern for configuration changes between revisions of this extension (however, it may be ideal to note the change in the changelog when a new release is made). With the restriction feature being more generic, we can use the simple tag/quirk list to help disable the label interaction. The original tag created was named `confluence_metadata`; however, this will be changed to `labels` to be more specific on what is being restricted. The final change will deal with where the restrictions take place. The original implementation would only disable accepting the new label content at the page-level. This would still result in the publish attempt to query for labels and attempt to re-set labels (which is not really required and may cause an API failure if labels are restricted). Instead, the translator will also accept new label information when processing a document, but the restriction flag will be used to prevent a publishing event from query and attempting to set label information. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 9195baac4b2fde93aebbf996a96ddd85e1c751b7

refactor labels to provided by builder The original label implementation would have a publisher pull label information for a page. In an attempt to have the publisher implementation find this information, this commit adjusts the store call to have the builder provide this information. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 9b40ccbfcf2055c4c1806cab7ec225f5bf919c7b

allow label appending to be configurable The original label support would always append labels on an existing page. In select cases, a user may wish to clear any legacy labels on a published set. This commit introduced the `confluence_append_labels` option (enabled by default) which will decide whether or not labels will be appended to completely re-written. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 5d784cea2d875c4b27b5ba51016dfb3e30fc9b0d

doc: document new append labels option Provides user documentation outlining the capabilities provided through the recently added `confluence_append_labels` option. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 860d6e82f412ea02a515cd4583a60db5b1dc95aa

support per-document labels The following adjusts the label mechanics to have the builder implementation process all prospect metadata information for a document instead of passing metadata information between a translator and builder via configuration options. This change is being made to first prevent the translator from manipulating the configuration context (which is not necessarily ideal). The original request for label support outlined a desired to have a per-page label assignment. This commit brings this capability by now tracking metadata information at a per-document level (instead of a single last-read metadata to be applied to all pages). Note that this change does prevent the ability for a user to apply a "global" label set to all pages, which was implicitly capable before. A future commit can be made to allow setting global labels via a configuration option. Note this change also introduces some corrections/improvements to the metadata node processing. First, this change provides a more flexible parsing of label data provide from a document -- this includes supporting multilines of labels and dealing with additional whitespaces. Second, a correction has been made to ensure node information can be properly shared when assembling a single document for the `singleconfluence` builder. The directive now populates the attribute container which allows stored information to be copied between a cloned node. The implementation issue exists in the existing JIRA-based implementation, which this implementation appears to be based off of (corrections to the JIRA implementation should be made in the future). Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha a32c2944d378e130b02ba8e428f71e07ca656ef6

introduce global labels The original label support for this extension would accept a single metadata directive to apply label information to all published pages. This was later adjusted to have individual directives only configure labels for specific documents they were contained in. While this may be ideal for most users, individuals wanting to apply a shared label for all published documents required alternative means (e.g. includes). This commit introduces the ability to configure a shared/global label to be applied to each published document. When a user configures `confluence_global_labels`, a list of string elements, each element will used as a label to add to each published document. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 788493df2631d8250f4f86e5f58398cecc0a0cb7

doc: provide information on new label capabilities Provides user documentation outlining the capabilities provided through the recently added `confluence_global_labels` option and `confluence_metadata` directive. Signed-off-by: James Knight <james.d.knight@live.com>

view details

push time in 18 days

push eventsphinx-contrib/confluencebuilder

Jared Curtis

commit sha 5fa4a514343a138247f274ff580db781dc408b25

ISSUE-313 POC of adding confluence metadata labels to pages This commit introduces a new directive `confluence_metadata` that has a parameter `labels`. These labels are added to the api JSON payload when creating or updating a page. Any labels added directly within Confluence will be maintained when publishing. resolves #313 Signed-off-by: Jared Curtis <jcurtis@xmatters.com>

view details

James Knight

commit sha 91cd379be3e436f6c79d6a2749c36cc8a3a76d1e

publisher: ignore label-fetch on dry-run Page information for a verbose dry-run is fetching label information (`metadata.labels`) without it being used to provide feedback on a dry-run. Adjusting the request to exclude this information. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 7dd59626f5bb400217a6f895ba7de921f2081b65

directives: refactor metadata directive The initial implementation of ConfluenceMetadataDirective most likely used the existing JIRA directives as a reference for implementation. The JIRA directive implementation uses a base directive to help deal with various types of JIRA directive definition. The metadata directive also defined its own base directive; however, (at this time) there does not appear to be a need for a base directive as there is only a single use for this type. Refactoring the implementation now to be a bit smaller. This change also sorts the directive to the top of the page. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 282d0c61df307772a7e8387ca26c345b4b6e28fa

rework label feature restrictor The initial implementation for page label support uses the macro-restrictor feature to disable its use; however, this feature is not a macro. At the same time, label capabilities could be disabled by an administrator as well. Therefore, it would still be ideal if a publisher had the ability to prevent an attempt to adjust labels on a page. The first part of this change tweaks the advanced configuration item `confluence_adv_restricted_macros` which will be renamed to `confluence_adv_restricted` to be more generic. Since this is an advanced/undocumented feature, there is less concern for configuration changes between revisions of this extension (however, it may be ideal to note the change in the changelog when a new release is made). With the restriction feature being more generic, we can use the simple tag/quirk list to help disable the label interaction. The original tag created was named `confluence_metadata`; however, this will be changed to `labels` to be more specific on what is being restricted. The final change will deal with where the restrictions take place. The original implementation would only disable accepting the new label content at the page-level. This would still result in the publish attempt to query for labels and attempt to re-set labels (which is not really required and may cause an API failure if labels are restricted). Instead, the translator will also accept new label information when processing a document, but the restriction flag will be used to prevent a publishing event from query and attempting to set label information. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 9195baac4b2fde93aebbf996a96ddd85e1c751b7

refactor labels to provided by builder The original label implementation would have a publisher pull label information for a page. In an attempt to have the publisher implementation find this information, this commit adjusts the store call to have the builder provide this information. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 9b40ccbfcf2055c4c1806cab7ec225f5bf919c7b

allow label appending to be configurable The original label support would always append labels on an existing page. In select cases, a user may wish to clear any legacy labels on a published set. This commit introduced the `confluence_append_labels` option (enabled by default) which will decide whether or not labels will be appended to completely re-written. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 5d784cea2d875c4b27b5ba51016dfb3e30fc9b0d

doc: document new append labels option Provides user documentation outlining the capabilities provided through the recently added `confluence_append_labels` option. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 860d6e82f412ea02a515cd4583a60db5b1dc95aa

support per-document labels The following adjusts the label mechanics to have the builder implementation process all prospect metadata information for a document instead of passing metadata information between a translator and builder via configuration options. This change is being made to first prevent the translator from manipulating the configuration context (which is not necessarily ideal). The original request for label support outlined a desired to have a per-page label assignment. This commit brings this capability by now tracking metadata information at a per-document level (instead of a single last-read metadata to be applied to all pages). Note that this change does prevent the ability for a user to apply a "global" label set to all pages, which was implicitly capable before. A future commit can be made to allow setting global labels via a configuration option. Note this change also introduces some corrections/improvements to the metadata node processing. First, this change provides a more flexible parsing of label data provide from a document -- this includes supporting multilines of labels and dealing with additional whitespaces. Second, a correction has been made to ensure node information can be properly shared when assembling a single document for the `singleconfluence` builder. The directive now populates the attribute container which allows stored information to be copied between a cloned node. The implementation issue exists in the existing JIRA-based implementation, which this implementation appears to be based off of (corrections to the JIRA implementation should be made in the future). Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha a32c2944d378e130b02ba8e428f71e07ca656ef6

introduce global labels The original label support for this extension would accept a single metadata directive to apply label information to all published pages. This was later adjusted to have individual directives only configure labels for specific documents they were contained in. While this may be ideal for most users, individuals wanting to apply a shared label for all published documents required alternative means (e.g. includes). This commit introduces the ability to configure a shared/global label to be applied to each published document. When a user configures `confluence_global_labels`, a list of string elements, each element will used as a label to add to each published document. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 788493df2631d8250f4f86e5f58398cecc0a0cb7

doc: provide information on new label capabilities Provides user documentation outlining the capabilities provided through the recently added `confluence_global_labels` option and `confluence_metadata` directive. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha fed91343da1add5e6eccc14d9557c02faf832511

test: correct restrictor tests A recent change [1] which adjusts the implementation of restricted features did not have respective changes made to the testing implementation; correcting. [1]: 282d0c61df307772a7e8387ca26c345b4b6e28fa Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 2242a01eeac51ebeb66c8cd4ad469f4c59791026

Merge pull request #332 from jaredcurtis/feature/labels ISSUE-313 POC of adding confluence metadata labels to pages

view details

push time in 18 days

PR merged sphinx-contrib/confluencebuilder

ISSUE-313 POC of adding confluence metadata labels to pages

This commit introduces a new directive confluence_metadata that has a parameter labels. These labels are added to the api JSON payload when creating or updating a page. Any labels added directly within Confluence will be maintained when publishing.

resolves #313

Signed-off-by: Jared Curtis jcurtis@xmatters.com

+273 -20

1 comment

15 changed files

jaredcurtis

pr closed time in 18 days

issue closedsphinx-contrib/confluencebuilder

Support for labels on pages

As Developer I want to be able to tag certain pages of my documentation so that they can easily be found through filters and overview pages.

I have recently started writing quite a bit of documentation in sphinx and this feature would help me and my colleagues a great deal.

My initial idea is to add a custom directive .. labels:

All labels directive occurrences within a page are joined for the final set of labels. Same would happen for the singleconfluence builder.


I would be willing to implement this myself although I must warn you that I have not created directives before.

I have seen that there is currently an issue with the new style editor and that issue of course takes precedence over such a minor enhancement.

Please let me know what you think. Cheers

closed time in 18 days

edthamm

pull request commentsphinx-contrib/confluencebuilder

ISSUE-313 POC of adding confluence metadata labels to pages

@jaredcurtis, thanks for the initial labeling implementation. I was able to take some time and try to include some additional capabilities. The plan is to merge this changes in.

If you have additional comments/concerns about the additional changes, please indicate so.

jaredcurtis

comment created time in 18 days

push eventjaredcurtis/confluencebuilder

James Knight

commit sha 91cd379be3e436f6c79d6a2749c36cc8a3a76d1e

publisher: ignore label-fetch on dry-run Page information for a verbose dry-run is fetching label information (`metadata.labels`) without it being used to provide feedback on a dry-run. Adjusting the request to exclude this information. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 7dd59626f5bb400217a6f895ba7de921f2081b65

directives: refactor metadata directive The initial implementation of ConfluenceMetadataDirective most likely used the existing JIRA directives as a reference for implementation. The JIRA directive implementation uses a base directive to help deal with various types of JIRA directive definition. The metadata directive also defined its own base directive; however, (at this time) there does not appear to be a need for a base directive as there is only a single use for this type. Refactoring the implementation now to be a bit smaller. This change also sorts the directive to the top of the page. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 282d0c61df307772a7e8387ca26c345b4b6e28fa

rework label feature restrictor The initial implementation for page label support uses the macro-restrictor feature to disable its use; however, this feature is not a macro. At the same time, label capabilities could be disabled by an administrator as well. Therefore, it would still be ideal if a publisher had the ability to prevent an attempt to adjust labels on a page. The first part of this change tweaks the advanced configuration item `confluence_adv_restricted_macros` which will be renamed to `confluence_adv_restricted` to be more generic. Since this is an advanced/undocumented feature, there is less concern for configuration changes between revisions of this extension (however, it may be ideal to note the change in the changelog when a new release is made). With the restriction feature being more generic, we can use the simple tag/quirk list to help disable the label interaction. The original tag created was named `confluence_metadata`; however, this will be changed to `labels` to be more specific on what is being restricted. The final change will deal with where the restrictions take place. The original implementation would only disable accepting the new label content at the page-level. This would still result in the publish attempt to query for labels and attempt to re-set labels (which is not really required and may cause an API failure if labels are restricted). Instead, the translator will also accept new label information when processing a document, but the restriction flag will be used to prevent a publishing event from query and attempting to set label information. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 9195baac4b2fde93aebbf996a96ddd85e1c751b7

refactor labels to provided by builder The original label implementation would have a publisher pull label information for a page. In an attempt to have the publisher implementation find this information, this commit adjusts the store call to have the builder provide this information. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 9b40ccbfcf2055c4c1806cab7ec225f5bf919c7b

allow label appending to be configurable The original label support would always append labels on an existing page. In select cases, a user may wish to clear any legacy labels on a published set. This commit introduced the `confluence_append_labels` option (enabled by default) which will decide whether or not labels will be appended to completely re-written. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 5d784cea2d875c4b27b5ba51016dfb3e30fc9b0d

doc: document new append labels option Provides user documentation outlining the capabilities provided through the recently added `confluence_append_labels` option. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 860d6e82f412ea02a515cd4583a60db5b1dc95aa

support per-document labels The following adjusts the label mechanics to have the builder implementation process all prospect metadata information for a document instead of passing metadata information between a translator and builder via configuration options. This change is being made to first prevent the translator from manipulating the configuration context (which is not necessarily ideal). The original request for label support outlined a desired to have a per-page label assignment. This commit brings this capability by now tracking metadata information at a per-document level (instead of a single last-read metadata to be applied to all pages). Note that this change does prevent the ability for a user to apply a "global" label set to all pages, which was implicitly capable before. A future commit can be made to allow setting global labels via a configuration option. Note this change also introduces some corrections/improvements to the metadata node processing. First, this change provides a more flexible parsing of label data provide from a document -- this includes supporting multilines of labels and dealing with additional whitespaces. Second, a correction has been made to ensure node information can be properly shared when assembling a single document for the `singleconfluence` builder. The directive now populates the attribute container which allows stored information to be copied between a cloned node. The implementation issue exists in the existing JIRA-based implementation, which this implementation appears to be based off of (corrections to the JIRA implementation should be made in the future). Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha a32c2944d378e130b02ba8e428f71e07ca656ef6

introduce global labels The original label support for this extension would accept a single metadata directive to apply label information to all published pages. This was later adjusted to have individual directives only configure labels for specific documents they were contained in. While this may be ideal for most users, individuals wanting to apply a shared label for all published documents required alternative means (e.g. includes). This commit introduces the ability to configure a shared/global label to be applied to each published document. When a user configures `confluence_global_labels`, a list of string elements, each element will used as a label to add to each published document. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 788493df2631d8250f4f86e5f58398cecc0a0cb7

doc: provide information on new label capabilities Provides user documentation outlining the capabilities provided through the recently added `confluence_global_labels` option and `confluence_metadata` directive. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha fed91343da1add5e6eccc14d9557c02faf832511

test: correct restrictor tests A recent change [1] which adjusts the implementation of restricted features did not have respective changes made to the testing implementation; correcting. [1]: 282d0c61df307772a7e8387ca26c345b4b6e28fa Signed-off-by: James Knight <james.d.knight@live.com>

view details

push time in 18 days

PR opened sphinx-contrib/confluencebuilder

translator: refactor translator

Refactoring the existing translator to split the implementation between a base translator (ConfluenceBaseTranslator) and a new storage format-specific translator (ConfluenceStorageFormatTranslator). This is to help prepare for prospect changes where a new translator aims to support the Atlassian Document format.

+318 -264

0 comment

4 changed files

pr created time in 2 months

create barnchsphinx-contrib/confluencebuilder

branch : refactor-translator

created branch time in 2 months

delete branch sphinx-contrib/confluencebuilder

delete branch : test-additional-sphinx-versions

delete time in 2 months

push eventsphinx-contrib/confluencebuilder

James Knight

commit sha 7105c7c2b809296fda50565b358e6d1a3f5c14d4

test: adjust c-domains check for new formatting Sphinx v3+ appears to adjust the positioning of the dereference operator. Adjusting the C-domains check to accommodate this. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 9f3b3871fcb7ba994723cc8815144f1d3d486b94

tox: manage supported sphinx versions Adjusting the tox configuration to test for the more recent releases of Sphinx. Since this extension aims to support a least five latest releases of Sphinx, dropping tests for some older versions. Note, that Sphinx v1.8.x series will still be tested against since it is the only version still supported on Python 2, which will continue to have support for at least a couple of more months. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha b356238178fcd5a1baabe9ec0359777e6c7378b5

.travis.yml: adjusted for new sphinx versions The tox configuration has been adjusted with a new version of Sphinx versions to test against. Adjusting the automated building to invoke these accordingly. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha a4978cb5ec1d6ebb9adb729dd84d6455d2fafa8c

Merge pull request #328 from sphinx-contrib/test-additional-sphinx-versions test additional sphinx versions

view details

push time in 2 months

PR merged sphinx-contrib/confluencebuilder

test additional sphinx versions

Adjusting the tox/Travis CI configuration to test for the more recent releases of Sphinx. Since this extension aims to support a least five latest releases of Sphinx, dropping tests for some older versions.

Note that Sphinx v1.8.x series will still be tested against since it is the only version still supported on Python 2, which will continue to have support for at least a couple of more months.

+44 -24

0 comment

5 changed files

jdknight

pr closed time in 2 months

delete branch sphinx-contrib/confluencebuilder

delete branch : bugfix/fallback-asset-path

delete time in 2 months

push eventsphinx-contrib/confluencebuilder

James Knight

commit sha c2ec846fd7692bab1bb1a392787751a9a16a8cc8

assets: provided fallback for asset paths Asset-based nodes processed by this extension will either provide a URI to a relative or absolute path. Part of the asset manager's process will attempt to determine the absolute path of a resource for future work. In the case for a relative path, a relative path is assumed to be located alongside the source content; however, this is not always the case for extensions which generate assets into the build output directory but only provide a relative path to the asset. To help deal with this case, when a relative path based off a documentation's source directory cannot be found, the process will fallback to a path based off the user-defined output directory. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 1468544748b44f77788e473ed47a1a89bea9db85

Merge pull request #326 from sphinx-contrib/bugfix/fallback-asset-path assets: provided fallback for asset paths

view details

push time in 2 months

PR merged sphinx-contrib/confluencebuilder

assets: provided fallback for asset paths

Asset-based nodes processed by this extension will either provide a URI to a relative or absolute path. Part of the asset manager's process will attempt to determine the absolute path of a resource for future work. In the case for a relative path, a relative path is assumed to be located alongside the source content; however, this is not always the case for extensions which generate assets into the build output directory but only provide a relative path to the asset. To help deal with this case, when a relative path based off a documentation's source directory cannot be found, the process will fallback to a path based off the user-defined output directory.

+16 -3

0 comment

2 changed files

jdknight

pr closed time in 2 months

delete branch sphinx-contrib/confluencebuilder

delete branch : bugfix/correct-hook-with-multiple-builders

delete time in 2 months

push eventsphinx-contrib/confluencebuilder

James Knight

commit sha 3add59663c69802778639d7421a2d825316e9780

correct hook with multiple builders For the standard builder in this extension, the `doctree-resolved` event is observed to help populate images which may be generated when a doctree has been resolved. When the single builder was introduced in this extension, the builder attribute (`app.builder`) no longer appears to be always initialized. Before type-checking the builder being used, hook on the `builder-inited` event to ensure the builder has been initialized. Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 045da56536896a30f024f41d36002e3d05dbccab

Merge pull request #324 from sphinx-contrib/bugfix/correct-hook-with-multiple-builders correct hook with multiple builders

view details

push time in 2 months

PR merged sphinx-contrib/confluencebuilder

correct hook with multiple builders

For the standard builder in this extension, the doctree-resolved event is observed to help populate images which may be generated when a doctree has been resolved. When the single builder was introduced in this extension, the builder attribute (app.builder) no longer appears to be always initialized. Before type-checking the builder being used, hook on the builder-inited event to ensure the builder has been initialized.

+4 -2

0 comment

1 changed file

jdknight

pr closed time in 2 months

PR opened sphinx-contrib/confluencebuilder

test additional sphinx versions

Adjusting the tox/Travis CI configuration to test for the more recent releases of Sphinx. Since this extension aims to support a least five latest releases of Sphinx, dropping tests for some older versions.

Note that Sphinx v1.8.x series will still be tested against since it is the only version still supported on Python 2, which will continue to have support for at least a couple of more months.

+44 -24

0 comment

5 changed files

pr created time in 2 months

create barnchsphinx-contrib/confluencebuilder

branch : test-additional-sphinx-versions

created branch time in 2 months

delete branch sphinx-contrib/confluencebuilder

delete branch : feature/define-user-agent

delete time in 2 months

push eventsphinx-contrib/confluencebuilder

James Knight

commit sha f31382a6b83e491bde331061183f20ee46feb8c3

rest: define user agent for request calls Define a user agent string for all request calls generated by this extension. This is solely to help prevent issues observed in CONFCLOUD-69720 [1] (while should already be resolved on Confluence Cloud). [1]: https://jira.atlassian.com/browse/CONFCLOUD-69720 Signed-off-by: James Knight <james.d.knight@live.com>

view details

James Knight

commit sha 78ed581a4fe3715c868ee5e1c558d99c8af54c8b

Merge pull request #325 from sphinx-contrib/feature/define-user-agent rest: define user agent for request calls

view details

push time in 2 months

PR merged sphinx-contrib/confluencebuilder

rest: define user agent for request calls

Define a user agent string for all request calls generated by this extension. This is solely to help prevent issues observed in CONFCLOUD-69720 [1] (while should already be resolved on Confluence Cloud).

[1]: https://jira.atlassian.com/browse/CONFCLOUD-69720

+4 -1

0 comment

1 changed file

jdknight

pr closed time in 2 months

issue commentsphinx-contrib/confluencebuilder

Failure with automatic generated images, eg. blockdiag, seqdiag, actdiag

@MarkusPoh and @RiccardoManfrin, thanks for the feedback. I was able to test against the sphinxcontrib-blockdiag which changes introduced in #326 (similar to the workaround mentioned in these comments). I believe this may resolve any case where an extension generates an asset into the build output directory and defines a relative path for a node. If you have any comments on the matter, feel free to comment. If all is good, this should be made available in the next stable release.

MarkusPoh

comment created time in 2 months

issue commentsphinx-contrib/confluencebuilder

any support for the new confluence editor

(see also #325)

mapperkids

comment created time in 2 months

issue commentsphinx-contrib/confluencebuilder

feature request: do not overwrite existing pages

Was able to take a look at this in #327. Do you believe this cover what you are looking for?

extremoburo

comment created time in 2 months

PR opened sphinx-contrib/confluencebuilder

publisher: introduce the only-new feature

Adding a new feature which allows users to configure this extension to restrict changing existing content on a Confluence space. When confluence_publish_onlynew is set to True, only new pages/attachments can be added to a target space.

+58 -0

0 comment

3 changed files

pr created time in 2 months

PR opened sphinx-contrib/confluencebuilder

assets: provided fallback for asset paths

Asset-based nodes processed by this extension will either provide a URI to a relative or absolute path. Part of the asset manager's process will attempt to determine the absolute path of a resource for future work. In the case for a relative path, a relative path is assumed to be located alongside the source content; however, this is not always the case for extensions which generate assets into the build output directory but only provide a relative path to the asset. To help deal with this case, when a relative path based off a documentation's source directory cannot be found, the process will fallback to a path based off the user-defined output directory.

+16 -3

0 comment

2 changed files

pr created time in 2 months

PR opened sphinx-contrib/confluencebuilder

rest: define user agent for request calls

Define a user agent string for all request calls generated by this extension. This is solely to help prevent issues observed in CONFCLOUD-69720 [1] (while should already be resolved on Confluence Cloud).

[1]: https://jira.atlassian.com/browse/CONFCLOUD-69720

+4 -1

0 comment

1 changed file

pr created time in 2 months

PR opened sphinx-contrib/confluencebuilder

correct hook with multiple builders

For the standard builder in this extension, the doctree-resolved event is observed to help populate images which may be generated when a doctree has been resolved. When the single builder was introduced in this extension, the builder attribute (app.builder) no longer appears to be always initialized. Before type-checking the builder being used, hook on the builder-inited event to ensure the builder has been initialized.

+4 -2

0 comment

1 changed file

pr created time in 2 months

create barnchsphinx-contrib/confluencebuilder

branch : feature/onlynew

created branch time in 2 months

create barnchsphinx-contrib/confluencebuilder

branch : bugfix/fallback-asset-path

created branch time in 2 months

create barnchsphinx-contrib/confluencebuilder

branch : feature/define-user-agent

created branch time in 2 months

issue commentsphinx-contrib/confluencebuilder

Can't Update Confluence Page

Note that this issue system is mainly for issues when interacting with a Confluence instance using the Sphinx Confluence Builder extension. It would be recommended to consult Atlassian's developer community for help in these cases.

That being said, it is most likely either one of the following issues from the information provided:

  • You are attempting to move a page identified with the value 774636582 from a space that was not named PS to a space named PS. It is unsupported using Atlassian REST API (to my knowledge) to change pages between spaces.
  • The space key value is case-sensitive. The above example is using a space key PS; however, if you are attempting to update a page on a space named ps, this will not work (see also CONFSERVER-40303).
RajatDoshi

comment created time in 2 months

issue commentsphinx-contrib/confluencebuilder

any support for the new confluence editor

@mapperkids, out of curiosity, do you still see this issue?

Was beginning to look at supporting a new translator when it was observed that the validation set could still be published to Confluence Cloud. This makes me assume the Atlassian still supports the storage format for new documents.

Some additional searching led me to the following issue:

CONFCLOUD-69720 Using REST API to update a page fails with a misleading error message if no user-agent is provided

This issue (along with other Q&A pages) shows that users are experiencing the "Content body cannot be converted to new editor format" error (mentioning in this initial issue comment) is an indication of Confluence not handling a request without a user agent. It looks to be fixed, hence the inquiry to see if this issue can still be experienced. I do have a pending change which will include a user agent value (just in case a specific Confluence version make still have this issue).

mapperkids

comment created time in 2 months

issue commentsphinx-contrib/confluencebuilder

Clean prefixes

@adityamj, I assume the difference between the published validation set versus your setup is that the "root" pages in the validation set are actually manually created pages. These manually created pages serve as the containers (confluence_parent_page) where the Sphinx-generated content is stored in -- hence why there is no prefix appended to those pages.

At this time, there is not an immediate solution for you other than manually creating the parent pages yourself or (as you have suggested) manually tweaking the root page's title after publication. This extension could introduce an option such as confluence_ignore_titlefix_on_master to help deal with this scenario. Curious though, if this documentation set is producing a a root title page master- and is configured with a prefix master-, is this example set not defining a default title inside the master_doc?

adityamj

comment created time in 3 months

issue commentsphinx-contrib/confluencebuilder

Multiple sphinx docs projects using same parent page on Confluence?

@danielloader, you may be interesting in the confluence_purge_from_master option, which will help target any configured purging based on each project's master document (instead of a specific container).

Although, if you are looking towards a having a single root space/container which can hold multiple flat-styled (non-hierarchical) documents, I can only advise to not enable purging after possibly purging on a first project publication.

If I have misunderstood your request, please feel free to follow up with more information.

danielloader

comment created time in 3 months

more