Uploaded image for project: 'Confluence Cloud'
  1. Confluence Cloud
  2. CONFCLOUD-69914

Labels and comments are missing from Creating a shared links

    • Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: Low Low
    • Page - Share

      Issue Summary

      Creating shared links not adding the labels and comments.

      Steps to Reproduce

      1. Step 1 Create a shared link and add Link, Title, Labels and Comment
      2. Step 2 Click on create and verify the page labels

      Expected Results

      Labels and comments should be added on the page.

      Actual Results

      • The label is missing, only the shared-links label is added
      • No comment is added to the page

      Workaround

      Manually add the label on the page using add label option.

      Also add the desired comment at the bottom of the page.

          Form Name

            [CONFCLOUD-69914] Labels and comments are missing from Creating a shared links

            Markus added a comment -

            It's just sad to see how this went down!

            I just tried and also wasn't able to "reproduce" the bug I had initially reported.

            In other words: this bug has been fixed in the meantime.

            Without updating this issue or, AFAIK, telling anybody about it.

            Moreover, this issue has now been closed with resolution "Cannot Reproduce".

            Hahaha...

            Don't get me wrong. I'm happy this is working again!

            But not only was Atlassian's response to this issue inappropriate, they sadly didn't even use the super-easy opportunity of saying "Hey guys, look, we fixed it for you!"

            That just shows that awareness of the relation between reported issues and development isn't where it should be. And that's not only to the detriment of end-users but in this case also directly to Atlassian.

            I know that this isn't an easy nut to crack. But Atlassian isn't some obscure one-person show either. If it were only this issue, you might consider it an outlier. But rather it seems to be a pattern observable in so many reported issues.

            Given that technically, in all likelihood,  this was easy to fix, it seems some process improvements would be required.

            Markus added a comment - It's just sad to see how this went down! I just tried and also wasn't able to "reproduce" the bug I had initially reported. In other words: this bug has been fixed in the meantime. Without updating this issue or, AFAIK, telling anybody about it. Moreover, this issue has now been closed with resolution "Cannot Reproduce". Hahaha... Don't get me wrong. I'm happy this is working again! But not only was Atlassian's response to this issue inappropriate, they sadly didn't even use the super-easy opportunity of saying "Hey guys, look, we fixed it for you!" That just shows that awareness of the relation between reported issues and development isn't where it should be. And that's not only to the detriment of end-users but in this case also directly to Atlassian. I know that this isn't an easy nut to crack. But Atlassian isn't some obscure one-person show either. If it were only this issue, you might consider it an outlier. But rather it seems to be a pattern observable in so many reported issues. Given that technically, in all likelihood,  this was easy to fix, it seems some process improvements would be required.

            This needs to be fixed, its such a pain in the ass to not have this feature. Can we get an ETA???

            Kele Nakamura added a comment - This needs to be fixed, its such a pain in the ass to not have this feature. Can we get an ETA???

            Markus added a comment -

            Hi Eric, thanks for your message - I really do appreciate it!

            I am running a small startup and I'm deeply involved in software development. So I really do understand the need to prioritize in light of limited resources.

            I totally don't expect all issues to be solved right away. My principle issue in this case was with communication, namely the effort it took to get the issue confirmed in the first place and then the impression that the issue will never be resolved because "as soon as possible" reads like "never" for low-priority issues in the "Long Term Backlog".

            To add something hopefully constructive:

            • adding labels works on the page created via the bookmarklet
              • so obviously there is a functional web interface for adding labels
            • presumably, the bookmarklet uses the same interface (I don't see a reason why it should use anything else)
              • I had a brief look at the page source but couldn't spot anything specific without going into the js
            • adding labels via the bookmarklet still worked a few months ago
              • so probably there was some change that broke it, maybe a change to the before mentioned interface?

            The point here is that it looks like this is an issue that may be quick and easy to fix. Of course, it may also not be. And for someone familiar with the implementation it should definitely be quick and easy to determine whether the fix is actually quick and easy. And then there is the particular nature of this issue, namely that something is not simply not working but that it seems to be working but is actually not, bringing about the risk of accruing damage over months without the users noticing. For those reasons, I would argue that if the initial technical investigation determines that the issue would be quick and easy to fix, it should be fixed even if there is little "customer support" for it yet. Namely because you don't want customer support to grow for this kind of issue.

            Obviously, this is more a business consideration than an engineering one. What I'm arguing is for the above considerations to be part of the function that determines issue priority with the rationale of avoiding negative consequences for customers before they occur. And from a communication perspective the tricky challenge is to give customers sufficient understanding that an issue will be dealt with eventually, as opposed to dying in the Long Term Backlog under a never-ending deluge of new issues.

            One final point: in case the present issue can't be fixed quickly and easily, the minimum interim solution is to update the bookmarklet by taking out or disabling the Labels field to keep users from sending labels to Nirvana, and to notify users about this change. That might also enlist further support on the ticket

            Markus added a comment - Hi Eric, thanks for your message - I really do appreciate it! I am running a small startup and I'm deeply involved in software development. So I really do understand the need to prioritize in light of limited resources. I totally don't expect all issues to be solved right away. My principle issue in this case was with communication, namely the effort it took to get the issue confirmed in the first place and then the impression that the issue will never be resolved because "as soon as possible" reads like "never" for low-priority issues in the "Long Term Backlog". To add something hopefully constructive: adding labels works on the page created via the bookmarklet so obviously there is a functional web interface for adding labels presumably, the bookmarklet uses the same interface (I don't see a reason why it should use anything else) I had a brief look at the page source but couldn't spot anything specific without going into the js adding labels via the bookmarklet still worked a few months ago so probably there was some change that broke it, maybe a change to the before mentioned interface? The point here is that it looks like this is an issue that may be quick and easy to fix. Of course, it may also not be. And for someone familiar with the implementation it should definitely be quick and easy to determine whether the fix is actually quick and easy. And then there is the particular nature of this issue, namely that something is not simply not working but that it seems to be working but is actually not, bringing about the risk of accruing damage over months without the users noticing. For those reasons, I would argue that if the initial technical investigation determines that the issue would be quick and easy to fix, it should be fixed even if there is little "customer support" for it yet. Namely because you don't want customer support to grow for this kind of issue. Obviously, this is more a business consideration than an engineering one. What I'm arguing is for the above considerations to be part of the function that determines issue priority with the rationale of avoiding negative consequences for customers before they occur. And from a communication perspective the tricky challenge is to give customers sufficient understanding that an issue will be dealt with eventually, as opposed to dying in the Long Term Backlog under a never-ending deluge of new issues. One final point: in case the present issue can't be fixed quickly and easily, the minimum interim solution is to update the bookmarklet by taking out or disabling the Labels field to keep users from sending labels to Nirvana, and to notify users about this change. That might also enlist further support on the ticket

            Thank you for voicing your frustration. As a developer working in Confluence Cloud and have used in Confluence in the past 6 years, I understand your point of view and sympathize with your need to be vocal and want to get the bug fixed right away. As a developer, I wish that I have the super power to make all issue can be resolved for all customers. That unfortunately only happens in the perfect world with unlimited man power.

            In reality, we are constrained by the limited resources and man power that we have. Our team receive tickets and feedback from customers from all over the world every single day. Saying yes to fix one issues mean we will not be able to fix issues from other customer. We decide to assign a priority number to each ticket where ticket has more customers subscribe to receive higher priority than the others. We have sprint planning where we would comb through the issues and assign people to the most urgent issue that needs to get fixed. This ticket is currently in our backlog and we are aware of the issue and the loss in value. We will do our best to prioritize this ticket into our upcoming sprint given that capacity allow.

            I also would like to address your point about "issues get fixed only after the damage is done". Confluence is a complex software with over 10 years worth of legacy code.  We try our best to detect bugs and issues before the customers experience it. However, we are not perfect. We appreciate the fact that our customers make us aware of the issues and be vocal about it.

            Again, I am stressing the fact that we are doing our best to get to all issues as best as we can. But like I said, we have the process to do things here and we are adhering to it

             

            Eric Le (Inactive) added a comment - Thank you for voicing your frustration. As a developer working in Confluence Cloud and have used in Confluence in the past 6 years, I understand your point of view and sympathize with your need to be vocal and want to get the bug fixed right away. As a developer, I wish that I have the super power to make all issue can be resolved for all customers. That unfortunately only happens in the perfect world with unlimited man power. In reality, we are constrained by the limited resources and man power that we have. Our team receive tickets and feedback from customers from all over the world every single day. Saying yes to fix one issues mean we will not be able to fix issues from other customer. We decide to assign a priority number to each ticket where ticket has more customers subscribe to receive higher priority than the others. We have sprint planning where we would comb through the issues and assign people to the most urgent issue that needs to get fixed. This ticket is currently in our backlog and we are aware of the issue and the loss in value. We will do our best to prioritize this ticket into our upcoming sprint given that capacity allow. I also would like to address your point about "issues get fixed only after the damage is done". Confluence is a complex software with over 10 years worth of legacy code.  We try our best to detect bugs and issues before the customers experience it. However, we are not perfect. We appreciate the fact that our customers make us aware of the issues and be vocal about it. Again, I am stressing the fact that we are doing our best to get to all issues as best as we can. But like I said, we have the process to do things here and we are adhering to it  

            Markus added a comment -

            Jake's post was not really voicing a concern. He has reported on an actual loss in value, a damage, incurred because an Atlassian product is not functioning the way it should and is advertised to. And that is a month after I had pointed out this specific risk and complained about Atlassian's inaction. All I got from the support person was essentially the statement that Atlassian considers issues as low-priority as long as there are not many people complaining about it. Which boils down to saying that issues get fixed only after the damage is done, even if the risk is known beforehand.

            I unfortunately don't have time for doing something more productive than ranting about this here. But this is a flawed policy that I've seen applied in several cases and should be improved at the appropriate level. I hope that someone from Atlassian gets on this quickly. Otherwise it would be best to try and raise general awareness for this situation.

            Markus added a comment - Jake's post was not really voicing a concern. He has reported on an actual loss in value, a damage, incurred because an Atlassian product is not functioning the way it should and is advertised to. And that is a month after I had pointed out this specific risk and complained about Atlassian's inaction. All I got from the support person was essentially the statement that Atlassian considers issues as low-priority as long as there are not many people complaining about it. Which boils down to saying that issues get fixed only after the damage is done, even if the risk is known beforehand. I unfortunately don't have time for doing something more productive than ranting about this here. But this is a flawed policy that I've seen applied in several cases and should be improved at the appropriate level. I hope that someone from Atlassian gets on this quickly. Otherwise it would be best to try and raise general awareness for this situation.

            Thanks for voicing your concern. I am cc-ing my dev manager in this thread and we will look into possibility of escalating this issue

            Eric Le (Inactive) added a comment - Thanks for voicing your concern. I am cc-ing my dev manager in this thread and we will look into possibility of escalating this issue

            Can someone at Atlassian take a look at this issue. It's really frustrating.

            We've been creating links for weeks with labels thinking they are added, only to find out now that there are none there and all the extra thought was wasted. Out links are now disorganized and hard to find because of this.

            Jake Bishop added a comment - Can someone at Atlassian take a look at this issue. It's really frustrating. We've been creating links for weeks with labels thinking they are added, only to find out now that there are none there and all the extra thought was wasted. Out links are now disorganized and hard to find because of this.

            Eric Le (Inactive) added a comment - - edited

            My apology. This ticket linked to product-fabric.atlassian.net is restricted to Atlassian employee access only and is used to track internally in our sprint board. When someone start working on that ticket, he/she will update this ticket accordingly. Please subscribe to this ticket  for any future update

            Eric Le (Inactive) added a comment - - edited My apology. This ticket linked to  product-fabric.atlassian.net  is restricted to Atlassian employee access only and is used to track internally in our sprint board. When someone start working on that ticket, he/she will update this ticket accordingly. Please subscribe to this ticket  for any future update

            Markus added a comment -

            I'd love to but get that I do not "have access to Jira on product-fabric.atlassian.net".

            If possible, please grant me access so that I can take a look.

            I saw that this is now in the "Long Term Backlog".

            I understand that this process takes a while and I'll happily give it a few days.

            But I'm seriously outraged by this issue and expect a timely solution, especially because a priori this should not be hard to fix.

            Markus added a comment - I'd love to but get that I do not "have access to Jira on product-fabric.atlassian.net ". If possible, please grant me access so that I can take a look. I saw that this is now in the "Long Term Backlog". I understand that this process takes a while and I'll happily give it a few days. But I'm seriously outraged by this issue and expect a timely solution, especially because a priori this should not be hard to fix.

            Markus added a comment - - edited

            I've raised this issue with Atlassian.

            This is NOT a minor issue, as currently indicated and should therefore not be treated as low priority!

            The reason for this is that:

            • adding labels in the provided field has been working flawlessly before, so many users may be using this feature
            • there is no feedback about the failed adding of labels and when using the "Share on Confluence" browser button described here, users will not usually see the page and will therefore remain oblivious to the fact that the labels they have carefully selected were not added
            • users may use this feature for weeks, assuming that they provide valuable meta-data that will help them find information later, before finding out that their effort was for nothing

            So please raise the classification of this issue!

            Markus added a comment - - edited I've raised this issue with Atlassian. This is NOT a minor issue, as currently indicated and should therefore not be treated as low priority! The reason for this is that: adding labels in the provided field has been working flawlessly before, so many users may be using this feature there is no feedback about the failed adding of labels and when using the "Share on Confluence" browser button described here , users will not usually see the page and will therefore remain oblivious to the fact that the labels they have carefully selected were not added users may use this feature for weeks, assuming that they provide valuable meta-data that will help them find information later, before finding out that their effort was for nothing So please raise the classification of this issue!

              Unassigned Unassigned
              nghuraiya@atlassian.com Neha Ghuraiya
              Affected customers:
              11 This affects my team
              Watchers:
              12 Start watching this issue

                Created:
                Updated:
                Resolved: