Comments
-
similar to this.
-
similar to this question.
-
seems that this problem is happening for many cloud users currently ...
-
Dear @Eileen Lundberg, for helping you we need more information. It can have a variation of reasons. Do you use Jira Cloud, which version number, happened the 'disappear' by a user action or by time? So long Thomas
-
Dear @Michael Go, the wish for having multiple assignee on one issue is very old. Best you have a look JRASERVER-1397. This would be the base of having a team review with built-in functionality. But Atlassian is currently not planing to implement it. If you search through the suggestions, you will find even newer ones…
-
Dear @kdukic, This can have two reasons: * the user has not the permission to see the agile board of 2nd project. Therefore go to 'config board' of the 2nd project's board and have a look on the 'general' tab. Does the user have rights for the project named at 'Shares'? * the 2nd project has a different permission scheme…
-
Then please mark as accepted, so that others can profit from this thread. Thanks Thomas
-
Yeah - which structure.
-
Dear @Biju Oommen, which proxy do you currently use? So long Thomas
-
Dear @TheLalaMan, was your question answered? Do you need more input? So long Thomas
-
Dear @Leander Costa, hey, @Nic Brough -Adaptavist- and me gave you an answer. Have you fixed your problem? Can we help you further? So long Thomas
-
Dear @DPA, to user one screen for all issue or not depends on your further configuration. If they are same, stay with one screen. If you plan to change the configuration for stories and bugs, differently, then it's better to have two screens. But be very sure to get rid of that duplicate SP field, so that there will be no…
-
Dear @Rafal Sojka, was your question solved meanwhile? Do you need more help? So long Thomas
-
Dear @Ankur Dayal, could you give my solution a try? Was it successful? So long Thomas
-
Dear @ronys, was your question answered? So long Thomas
-
Dear @hanlinbo, you didn't come back to this post. Have you solved it meanwhile? So long Thomas
-
Dear @Scott Federman, have you figured out my solution? Do you need more help? So long Thomas
-
Dear @Johanna Himes, was your question answered? Do you need more help? So long Thomas
-
Dear @Christophe Fruytier, your didn't answer yet - are there still questions? So long Thomas
-
Dear @manitgl, have you fixed your problem, meanwhile? So long Thomas
-
Dear @Kevin Gaspard, that seems to be easy. If you have one .md file per page, than you can just loop with a script over all files and fire one request. My estimation for that script would be 1-2 hours writing, including testing on a test environment, first. Then the import of 1000 pages will not take longer than a couple…
-
Dear @zunairf, if you search Atlassian pages, you can get some SDK for plugin development. But first have a look at JMEH, if they support what you need. So long Thomas
-
Then you can raise a suggestion at Atlassian and wait.
-
Dear @Londa Liau, as root user, edit the text block for the location of your Confluence Installation: cat << EOF | sudo tee /etc/systemd/system/confluence.service [Unit] Description=Atlassian Confluence Service After=syslog.target network.target [Service] Type=forking User=www-data Group=www-data ExecStart=<your path to…
-
The REST call POST https://myconfluence.com/rest/content The JSON payload: { "type":"page", "title":"A new page", "space":{"key":"ABC"}, "body":{" storage":{ "value":"place your .md content per page here", "representation":"storage" } } } Per new page, one call.
-
Dear @Kevin Gaspard, I do not know your format ".md", but I would give it a try with the REST API. So long Thomas
-
Dear @Kfir Goldwasser, I recommend to have for a staging environment same configuration as for prod. So you can quickly figure out, of an upgrade/other modification is working as expected and apply the changes to prod. If you have enough resources on the VM host system, create for each application an one instance. Reduces…
-
Not that I know. And be aware - even if the usernames are equal, for Jira they are different (internal ID). Otherwise, this would be a security breach.
-
Dear @Pavel Ihring, the alias should be same as how you connect to Jira/Confluence: https://server.com ----> alias = server.com:443 https://server.com:8443 -----> alias = server.com:8443 So long Thomas
-
Again, log on the Jira server and try a telnet <mailserver> <port> I it reachable? Also a timeout? So long Thomas
