Autoconvert - Limits, Conflicts, Better doc request?

Confluence Development Confluence Cloud
, , ,
1

Context of this post is the Autoconvert module in Confluence Cloud Connect (Autoconvert)

Questions we’re left with after reviewing the above:

  • Are there any docs on how macro autoconvert modules conflict with one another are resolved? For example, two different apps register https://example.com/{}
  • Same question for what happens when they conflict with smart links? Essentially where Atlassian are the ones to register https://example.com
  • Is there any way to make a {} matcher include / characters so we don’t have to create one per url path depth?
  • Can matchers be made case insensitive since URLs are often case insensitive, but matchers are not?

The above has led to this nonsense: https://markdown-macro-cloud-staging.herokuapp.com/atlassian-connect.json

2 Likes
2

@boris Good questions.

  • Are there any docs on how macro autoconvert modules conflict with one another are resolved? For example, two different apps register https://example.com/{}

Decided to give this a whirl myself, and at first, it appeared that the latest installed app won the conflict; however, after adding a third app that conflicted, it went back to the first. So, long story short, we’ll engage with the appropriate team to get more clarity on what we expect to happen. Same goes for the question re: smart links.

  • Is there any way to make a {} matcher include / characters so we don’t have to create one per url path depth?

I don’t believe there is currently a way to do that. I would also assume that keeping / out there as an explicit delimiter helps to insure precise pattern matches (as opposed to greedy matching). Do you have many cases in which depth is arbitrary?

  • Can matchers be made case insensitive since URLs are often case insensitive, but matchers are not?

I’d argue that most web servers treat paths and filenames as case sensitive; however, looking at your use case / descriptor, a developer may use .MD or .md suffix for their filename in a repo, for example… and that’s what you’re trying to solve for. I’ll also bring this up to the team to see if this is possible (or at least get it to feature request).

Thanks!

3 Likes
4

We’re mapping resources in a git repo, so depth is arbitrary. The current method requires us to do something like

Depth*Cases*Capitalization=property length and we need that length to be shorter than 200 properties

So we can trade off handling one for another. I think in the future, we may have more data on what people are entering, and we can tweak this descriptor.

1 Like
5

Do you have many cases in which depth is arbitrary?

We have the same use case for Bitbucket files. Currently we repeat auto converts to a certain path depth and hope it works for must users. As soon as someone has a deeper path, the copy and past feature will not work for our app.