• Icon: Suggestion Suggestion
    • Resolution: Obsolete
    • None
    • None
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.

      Background
      JIRA does not natively support the idea of field level security (JRA-1330), the most popular of which is the ability to the hide Time Tracking fields from customers (JRA-2364). We know that a lot of customers really want a way for JIRA to solve this kind of problem.

      View Ports
      Internally at Atlassian we have been throwing around the idea of what we call "View Ports". The idea behind this is that admins can configure an alternative view of the JIRA View Issue screen for different groups. One of the items that can be configured is the ability to choose what fields are shown in the View Port.

      Example Scenario
      You have a company that specialises in custom development solutions and have 10 internal staff members with 200 external customers. You want to manage all your issues in one JIRA project but you do not want to expose the time tracking fields to your customers.

      View Port Solution
      1. Admin creates a JIRA group for all the 'external customers'.
      2. Admin then creates a View Port for this group only.
      3. Admin configures the View Port to show all fields except time tracking.

      When anyone in the 'external customers' group logs into a specific url, they are taken to this View Port. They will not be able to login into the normal JIRA system.

      Comments Please
      We'd love to get your feedback in this solution and if it would work for your company.

            [JRACLOUD-27613] Alternative JIRA Views

            I need this desperately! I don't think all users need to see time tracking.

            Joris Weimar added a comment - I need this desperately! I don't think all users need to see time tracking.

            Today another user asked for this feature. They want to use JIRA but want different teams to see different fields.
            Just for you to know.

            Emre Toptancı [OBSS] added a comment - Today another user asked for this feature. They want to use JIRA but want different teams to see different fields. Just for you to know.

            @Atlassian
            No matter what we use JIRA for, there are almost always two parties involved. Service provider and service consumer (or customer). When there is more than one party, there will always be some information that needs to be hid from customer. Service Desk is a solution that solves only a small portion of this problem. The need to hide some fields from some users in the conventional JIRA interface is critical.

            The initial idea of viewports was a promising one yet you decided not to implement it. Believe me guys, Service Desk can not meet those needs. You say it is very hard to implement this feature since it would require large portions of JIRA to be rewritten. You know what: You should start immediately!!!

            JIRA is moving to an upper league these days. We, as a partner, are positioning JIRA for all kinds of needs: Request management, project & portfolio management, service desk, audits, etc... you name it. Believe me when I say this feature is needed desparately. This is more important than Service Desk or Portfolio. There is no version of future that JIRA can go on without this feature forever. Sooner or later you will have to implement this. The sooner it is done the less damage. (We are currently implementing a very large scale Atlassian project and we suffered a lot because of this. I can not put enough emphasis on how important this is.)

            Emre Toptancı [OBSS] added a comment - @Atlassian No matter what we use JIRA for, there are almost always two parties involved. Service provider and service consumer (or customer). When there is more than one party, there will always be some information that needs to be hid from customer. Service Desk is a solution that solves only a small portion of this problem. The need to hide some fields from some users in the conventional JIRA interface is critical. The initial idea of viewports was a promising one yet you decided not to implement it. Believe me guys, Service Desk can not meet those needs. You say it is very hard to implement this feature since it would require large portions of JIRA to be rewritten. You know what: You should start immediately!!! JIRA is moving to an upper league these days. We, as a partner, are positioning JIRA for all kinds of needs: Request management, project & portfolio management, service desk, audits, etc... you name it. Believe me when I say this feature is needed desparately. This is more important than Service Desk or Portfolio. There is no version of future that JIRA can go on without this feature forever. Sooner or later you will have to implement this. The sooner it is done the less damage. (We are currently implementing a very large scale Atlassian project and we suffered a lot because of this. I can not put enough emphasis on how important this is.)

            Gebsun added a comment -

            Hello guys,

            The mentioned Hide Time Tracking plugin is now a mature product and time tracking information is not visible in JIRA UI (for users without 'work on issues' permission).
            In case of any problems you can raise an issue at https://gebsun.atlassian.net/browse/HTT

            Regards,
            Gebsun

            Gebsun added a comment - Hello guys, The mentioned Hide Time Tracking plugin is now a mature product and time tracking information is not visible in JIRA UI (for users without 'work on issues' permission). In case of any problems you can raise an issue at https://gebsun.atlassian.net/browse/HTT Regards, Gebsun

            Gandalf added a comment -

            @Alexander: Many thanks for the info. It's indeed possible that this plugin is still early stage and that it does not yet cover all aspects.
            In fact, this type of plugin was expected to be developed by Atlassian (Jira) in order to provide a solution for "hiding time tracking fields". It's a pity this has to be performed by a third party.

            Gandalf added a comment - @Alexander: Many thanks for the info. It's indeed possible that this plugin is still early stage and that it does not yet cover all aspects. In fact, this type of plugin was expected to be developed by Atlassian (Jira) in order to provide a solution for "hiding time tracking fields". It's a pity this has to be performed by a third party.

            @Jean-Jacques I would advise you against using this new plugin at all in its current state. It just seems to work, but actually everything is still visible in change history, activity streams etc etc.

            Alex Shchagin added a comment - @Jean-Jacques I would advise you against using this new plugin at all in its current state. It just seems to work, but actually everything is still visible in change history, activity streams etc etc.

            Gandalf added a comment -

            @Ronald, we're indeed in the same boat and facing exactly the same situation.
            Let's hope that Atlassian (Jira) will surprise us by quickly enabling this long awaited plugin. Just want to stay positive after all.

            Gandalf added a comment - @Ronald, we're indeed in the same boat and facing exactly the same situation. Let's hope that Atlassian (Jira) will surprise us by quickly enabling this long awaited plugin. Just want to stay positive after all.

            We're in the same boat. There's a lot of things we like about Jira and we haven't found a replacement.
            The need to hide time tracking doesn't affect all our projects so for the moment we're putting up with the missing functionality.

            Ronald Vallenduuk added a comment - We're in the same boat. There's a lot of things we like about Jira and we haven't found a replacement. The need to hide time tracking doesn't affect all our projects so for the moment we're putting up with the missing functionality.

            Gandalf added a comment -

            @Ronald Vallenduuk...thanks for your reply.
            You indeed pointed out the different options and we looked/tried all of them.
            Leaving Jira behind is indeed an option, all the others are not. But I must also say, on a positive note, we've a lot of satisfaction with other Jira features and Jira in general with Confluence, Bit Bucket and so on. But this "hide time tracking fields" is indeed the cause of lots of frustration on our side. Did you find another solution?

            Gandalf added a comment - @Ronald Vallenduuk...thanks for your reply. You indeed pointed out the different options and we looked/tried all of them. Leaving Jira behind is indeed an option, all the others are not. But I must also say, on a positive note, we've a lot of satisfaction with other Jira features and Jira in general with Confluence, Bit Bucket and so on. But this "hide time tracking fields" is indeed the cause of lots of frustration on our side. Did you find another solution?

            @Jean-Jacques Courtens: Thank you. I will check out the plugin. Hope it will fit our needs.

            Tobias Schenke [commsult AG] added a comment - @Jean-Jacques Courtens: Thank you. I will check out the plugin. Hope it will fit our needs.

            Jean-Jacques, I wouldn't count on it. They've been coming up with excuses for 10 years; that should tell you how much they value this feature.
            You have a few options:

            • Switch from ondemand to onpremise and get a plugin. Of course this comes with all the headache and cost that made you go for ondemand in the first place, so not an option.
            • Double-book keeping; create two versions of each project, one internal and one external. Lots of extra admin overhead so no real option.
            • Don't let customers in Jira. They will have less visibility and your team will have to copy all their comments from email to Jira. No real option.
            • That leaves... find another solution and leave Jira behind.

            Ronald Vallenduuk added a comment - Jean-Jacques, I wouldn't count on it. They've been coming up with excuses for 10 years; that should tell you how much they value this feature. You have a few options: Switch from ondemand to onpremise and get a plugin. Of course this comes with all the headache and cost that made you go for ondemand in the first place, so not an option. Double-book keeping; create two versions of each project, one internal and one external. Lots of extra admin overhead so no real option. Don't let customers in Jira. They will have less visibility and your team will have to copy all their comments from email to Jira. No real option. That leaves... find another solution and leave Jira behind.

            Gandalf added a comment -

            Hello,
            Is there finally hope to solve a long awaited feature?
            Hiding "time tracking fields" in Jira for external users is a major request for many Jira users.

            I see that a new plugin has been made available for the download instance: https://marketplace.atlassian.com/plugins/com.gebsun.plugins.jira.hidetimetracking .

            This ability has been requested for more than 10 years ago (check the history of related issues to time tracking). Jira (Atlassian) came up with, for sure, many great features but never solved the real need.

            I'm convinced, if this plugin works as described, this would be appreciated by many many Jira users.

            Looking forward to the quick responsiveness of Jira Team to make this plugin available in "on demand".

            Cheers

            Gandalf added a comment - Hello, Is there finally hope to solve a long awaited feature? Hiding "time tracking fields" in Jira for external users is a major request for many Jira users. I see that a new plugin has been made available for the download instance: https://marketplace.atlassian.com/plugins/com.gebsun.plugins.jira.hidetimetracking . This ability has been requested for more than 10 years ago (check the history of related issues to time tracking). Jira (Atlassian) came up with, for sure, many great features but never solved the real need. I'm convinced, if this plugin works as described, this would be appreciated by many many Jira users. Looking forward to the quick responsiveness of Jira Team to make this plugin available in "on demand". Cheers

            Hi Edwin, thanks for the answer regarding the Field Security Plugin, but once again, it seems that Atlassian is ignoring On-Demand customers who are paying several thousands of dollars per year, but still miss a critical functionality which is being able to hide time tracking. As long as we don't have this feature, we cannot work with our customers in JIRA or JIRA Agile, which is, by the way, the exact opposite of how we need to work in Agile... The customer must be part of the team.

            So, how can we work with your product then??

            Normand Carbonneau added a comment - Hi Edwin, thanks for the answer regarding the Field Security Plugin, but once again, it seems that Atlassian is ignoring On-Demand customers who are paying several thousands of dollars per year, but still miss a critical functionality which is being able to hide time tracking. As long as we don't have this feature, we cannot work with our customers in JIRA or JIRA Agile, which is, by the way, the exact opposite of how we need to work in Agile... The customer must be part of the team. So, how can we work with your product then??

            edwin added a comment -

            Anders, Normand, Peter, Bernhard, Jean-Jacques, Patrick,

            Thanks for your comments. I can appreciate that you may be disappointed the closure of this issue. Making decisions like these are always difficult for us, and definitely not a part of the job that we enjoy. If we had an infinite amount of capacity, we would love to do every feature request in this tracker. However, the reality is that we are always constrained to balance the different competing priorities of the product.

            At this stage, we are closing this issue because we cannot see that this issue will resolved in our foreseeable future given other priorities. We believe being up front and clear about this is a better embodiment of our values than to keep this request open.

            As for workarounds to hide time tracking information, there is the Field Security Plugin developed by Quisapps available in the marketplace that can hide time tracking information (and custom fields).

            Edwin Wong
            JIRA Service Desk Product Manager

            edwin added a comment - Anders, Normand, Peter, Bernhard, Jean-Jacques, Patrick, Thanks for your comments. I can appreciate that you may be disappointed the closure of this issue. Making decisions like these are always difficult for us, and definitely not a part of the job that we enjoy. If we had an infinite amount of capacity, we would love to do every feature request in this tracker. However, the reality is that we are always constrained to balance the different competing priorities of the product. At this stage, we are closing this issue because we cannot see that this issue will resolved in our foreseeable future given other priorities. We believe being up front and clear about this is a better embodiment of our values than to keep this request open. As for workarounds to hide time tracking information, there is the Field Security Plugin developed by Quisapps available in the marketplace that can hide time tracking information (and custom fields). Edwin Wong JIRA Service Desk Product Manager

            Patrick Ford added a comment - - edited

            Resolution Obsolete? Obsolete = "no longer produced or used; out of date." Nice try. Feels a little more like Won't Fix which is a completely inappropriate way to respond to years of feedback regarding the usefulness of this feature. This is extremely discouraging and while I don't think it's a trivial development effort, I don't think it would be that difficult to implement. A little less time trying to monetize this opportunity by developing new products and little more time worrying that you're going to lose market share to a provider that understand the value of this feature.

            Like Jean-Jacques, I'm a long time Jira user. I don't want to move off the platform but there's a lot of pressure to provide our customers with direct access to our PM tool (less time tracking).

            You've received a lot of very specific feedback over the years in regards to this topic. Please don't make us feel like we're wasting our breath... Check out this set of Values I found from a company that would never respond as you have: https://www.atlassian.com/company/about/values

            Patrick Ford added a comment - - edited Resolution Obsolete? Obsolete = "no longer produced or used; out of date." Nice try. Feels a little more like Won't Fix which is a completely inappropriate way to respond to years of feedback regarding the usefulness of this feature. This is extremely discouraging and while I don't think it's a trivial development effort, I don't think it would be that difficult to implement. A little less time trying to monetize this opportunity by developing new products and little more time worrying that you're going to lose market share to a provider that understand the value of this feature. Like Jean-Jacques, I'm a long time Jira user. I don't want to move off the platform but there's a lot of pressure to provide our customers with direct access to our PM tool (less time tracking). You've received a lot of very specific feedback over the years in regards to this topic. Please don't make us feel like we're wasting our breath... Check out this set of Values I found from a company that would never respond as you have: https://www.atlassian.com/company/about/values

            Gandalf added a comment -

            I can't agree more with the previous comments and share the disappointment. We're also building software in SaaS and we perfectly understand technical difficulties. But we also know that there is always a technical solution. In my honest opinion, hiding the time tracking fields (in views, history, API...) is not as complex as you are expressing it. It's I believe a very important feature when willing to use Jira as a collaboration tool with people outside your organization (customers, consultants...).
            This issue is open since more than 10 years, it's not that you couldn't take this request into account in all the enhancement you performed on Jira since then.

            Don't get me wrong, we still believe Jira is a great tool with some nice enhancements. If we are insisting and angry, is because we don't want to change our jira environment. But make no mistake, if we encounter a tool with the minimum requirements including hiding the time tracking features...we will change!

            Gandalf added a comment - I can't agree more with the previous comments and share the disappointment. We're also building software in SaaS and we perfectly understand technical difficulties. But we also know that there is always a technical solution. In my honest opinion, hiding the time tracking fields (in views, history, API...) is not as complex as you are expressing it. It's I believe a very important feature when willing to use Jira as a collaboration tool with people outside your organization (customers, consultants...). This issue is open since more than 10 years, it's not that you couldn't take this request into account in all the enhancement you performed on Jira since then. Don't get me wrong, we still believe Jira is a great tool with some nice enhancements. If we are insisting and angry, is because we don't want to change our jira environment. But make no mistake, if we encounter a tool with the minimum requirements including hiding the time tracking features...we will change!

            I understand that atlassian want's to push Service Desk and for most people this will solve the problem with time time tracking fields, but not for me.
            In my project setup our customers can look into our agile boards. external developers work on our boards and can view jira tasks.
            That means they all see the timetracking fields an the time booked. We use Tempo, Jira Agile and Service Desk.
            But I do not see Service Desk as a solution for hiding time tracking fields. We use the Jira Field Security Plugin for that purpose, but this plugin patches Jira which is not very nice. We rather would like a softer way of doing that.

            Bernhard Gruenewaldt added a comment - I understand that atlassian want's to push Service Desk and for most people this will solve the problem with time time tracking fields, but not for me. In my project setup our customers can look into our agile boards. external developers work on our boards and can view jira tasks. That means they all see the timetracking fields an the time booked. We use Tempo, Jira Agile and Service Desk. But I do not see Service Desk as a solution for hiding time tracking fields. We use the Jira Field Security Plugin for that purpose, but this plugin patches Jira which is not very nice. We rather would like a softer way of doing that.

            Peter added a comment -

            So the solution to my JIRA problem is to buy a different product? How is that a resolution? With Service Desk, we have to spend hardware resources on it, train an admin, train users and customers all in the sake of not actually fixing the original problem. This is NOT resolved as this was in my mind a large deficiency with JIRA. I need field level security in my issue tracking tool, I don't use JIRA as a service desk and trying to shoehorn my issue tracking into Service Desk is not an option just for field level security

            Peter added a comment - So the solution to my JIRA problem is to buy a different product? How is that a resolution? With Service Desk, we have to spend hardware resources on it, train an admin, train users and customers all in the sake of not actually fixing the original problem. This is NOT resolved as this was in my mind a large deficiency with JIRA. I need field level security in my issue tracking tool, I don't use JIRA as a service desk and trying to shoehorn my issue tracking into Service Desk is not an option just for field level security

            Edwin, I understand that you addressed the "Viewports" issue with JIRA Service Desk, but for Time Tracking, if JRA-2364 is closed, what is the alternative for us? How can we hide everything related to time tracking from customers having access to a project?
            Can you explain a little bit what is the plan from Atlassian to address this problem?

            Thanks, Normand

            Normand Carbonneau added a comment - Edwin, I understand that you addressed the "Viewports" issue with JIRA Service Desk, but for Time Tracking, if JRA-2364 is closed, what is the alternative for us? How can we hide everything related to time tracking from customers having access to a project? Can you explain a little bit what is the plan from Atlassian to address this problem? Thanks, Normand

            I just must say that this makes me sad. We have been waiting for a solution to JRA-2364 for a looooong time and two years back Atlassian pointed to this issue instead. To now read that you plan to never ever solve it is discouraging to say the least. JIRA will thereby never be a complete solution for projects where customers are involved. I understand that there are technical difficulties, but I thought you had skills enough to manage also complex problems within Atlassian.

            Anders Ingestedt added a comment - I just must say that this makes me sad. We have been waiting for a solution to JRA-2364 for a looooong time and two years back Atlassian pointed to this issue instead. To now read that you plan to never ever solve it is discouraging to say the least. JIRA will thereby never be a complete solution for projects where customers are involved. I understand that there are technical difficulties, but I thought you had skills enough to manage also complex problems within Atlassian.

            edwin added a comment -
            Atlassian Status as of 26 February 2014

            "Viewports" was a concept we explored that could provide the ability for admins to partition the view of a ticket into "end users" and "insiders". The intention was to allow admins to tailor an interface to JIRA that encourages end users to create, view and collaborate on requests, while your internal teams take advantage of the full power of JIRA to process these issues. We had hoped that this solution would also help customers who wanted to hide time tracking fields as per JRA-2364 (Hide Time Tracking estimates from certain users).

            Your feedback on Viewport and the specific needs for hiding time tracking made it clear that generic Viewport wasn't the best way to solve customers' problems. There were two very different use cases:
            1) Using JIRA to power their service desk operations. This idea evolved into JIRA Service Desk.
            2) Hiding time tracking fields (usually because external consultants or customers were collaborating in JIRA, but everything except time tracking information)

            Service Desk:
            One of the key parts of JIRA Service Desk is the Customer Portal, which implements much of the original concepts of Viewport, but tailored for the service desk use case. Using the Customer Portal you can build customer / end-user oriented views of issue types - you can hide fields, rename fields, re-map workflow statuses. You can effectively give a different view of your issue to different audiences. With the recent release of JIRA Service Desk 1.2, you can also lock out your Customer Portal users from being able to log in to JIRA altogether.

            If you've been waiting for "Viewports", I recommend you give JIRA Service Desk a try. Service Desk is much more than what Viewport started out as - there are queues, reports, service level agreements, knowledge base integration and much more in development.

            At this stage, we will close off this issue, as we will unlikely revisit shipping "Viewports" as originally described in this issue. Thank you to everyone who has contributed to this issue.

            Time Tracking:
            A deeper look into time tracking with customers and their use cases revealed that just hiding the standard JIRA time tracking fields from the UI would not be enough. They needed to be inaccessible through REST APIs, change history, and a number of other areas. There were other fields that customers needed hidden that were "related" to time tracking. So a simple solution of hiding time tracking from View Issue would still be expensive to develop, add more complexity to JIRA, and not actually solve the full problem. Due to this, at this time we are leaving JRA-2364 closed.

            Edwin Wong
            JIRA Service Desk Product Manager

            edwin added a comment - Atlassian Status as of 26 February 2014 "Viewports" was a concept we explored that could provide the ability for admins to partition the view of a ticket into "end users" and "insiders". The intention was to allow admins to tailor an interface to JIRA that encourages end users to create, view and collaborate on requests, while your internal teams take advantage of the full power of JIRA to process these issues. We had hoped that this solution would also help customers who wanted to hide time tracking fields as per JRA-2364 (Hide Time Tracking estimates from certain users). Your feedback on Viewport and the specific needs for hiding time tracking made it clear that generic Viewport wasn't the best way to solve customers' problems. There were two very different use cases: 1) Using JIRA to power their service desk operations. This idea evolved into JIRA Service Desk. 2) Hiding time tracking fields (usually because external consultants or customers were collaborating in JIRA, but everything except time tracking information) Service Desk : One of the key parts of JIRA Service Desk is the Customer Portal, which implements much of the original concepts of Viewport, but tailored for the service desk use case. Using the Customer Portal you can build customer / end-user oriented views of issue types - you can hide fields, rename fields, re-map workflow statuses. You can effectively give a different view of your issue to different audiences. With the recent release of JIRA Service Desk 1.2, you can also lock out your Customer Portal users from being able to log in to JIRA altogether. If you've been waiting for "Viewports", I recommend you give JIRA Service Desk a try. Service Desk is much more than what Viewport started out as - there are queues, reports, service level agreements, knowledge base integration and much more in development. At this stage, we will close off this issue, as we will unlikely revisit shipping "Viewports" as originally described in this issue. Thank you to everyone who has contributed to this issue. Time Tracking : A deeper look into time tracking with customers and their use cases revealed that just hiding the standard JIRA time tracking fields from the UI would not be enough. They needed to be inaccessible through REST APIs, change history, and a number of other areas. There were other fields that customers needed hidden that were "related" to time tracking. So a simple solution of hiding time tracking from View Issue would still be expensive to develop, add more complexity to JIRA, and not actually solve the full problem. Due to this, at this time we are leaving JRA-2364 closed. Edwin Wong JIRA Service Desk Product Manager

            MattS added a comment -

            Ronald, why do you think nothing happened? JIRA Service Desk got created for a start. Atlassian, a status update on this one would be very useful

            MattS added a comment - Ronald, why do you think nothing happened? JIRA Service Desk got created for a start. Atlassian, a status update on this one would be very useful

            This thing is unbelievable. The original request goes back 11 years. Then this ticket was created 2 years ago and still nothing happens.
            How on earth can you ignore a top 10 customer request for more than a decade?
            Gonna have to start looking for an alternative solution.
            The only option I've come across sofar in all these threads is double bookkeeping but unless there is a way to automate it that's no viable solution. It would just add too much overhead for the team.

            Ronald Vallenduuk added a comment - This thing is unbelievable. The original request goes back 11 years. Then this ticket was created 2 years ago and still nothing happens. How on earth can you ignore a top 10 customer request for more than a decade? Gonna have to start looking for an alternative solution. The only option I've come across sofar in all these threads is double bookkeeping but unless there is a way to automate it that's no viable solution. It would just add too much overhead for the team.

            I add my voice to this one. Being able to hide time tracking from customers is a MUST HAVE, even 2 years later...

            Normand Carbonneau added a comment - I add my voice to this one. Being able to hide time tracking from customers is a MUST HAVE, even 2 years later...

            2 years gone. This idea is still nowhere. In the meantime, time tracking fields still cannot be hidden from "external" users. Why is the suggestion of Thorbjorn not implemented completely eludes me.

            Cristian Caprar added a comment - 2 years gone. This idea is still nowhere. In the meantime, time tracking fields still cannot be hidden from "external" users. Why is the suggestion of Thorbjorn not implemented completely eludes me.

            yes Thorbjorn. It really is that simple an I also hope, that they will implement some group- or user-bound permissions for time-tracking.

            Bernhard Gruenewaldt added a comment - yes Thorbjorn. It really is that simple an I also hope, that they will implement some group- or user-bound permissions for time-tracking.

            Why not simply add a permission under "Time tracking permissions" in the permission scheme that says "View time tracking information", and if you don't have this permission, the time tracking control is not loaded or is void of information when viewing an issue?

            Thorbjørn Sigberg added a comment - Why not simply add a permission under "Time tracking permissions" in the permission scheme that says "View time tracking information", and if you don't have this permission, the time tracking control is not loaded or is void of information when viewing an issue?

            É importante a implementação dessas melhorias. Isto ajudaria o gerenciamento dos administradores JIRA.

            Quando ficará pronta?

            Luiz Felipe added a comment - É importante a implementação dessas melhorias. Isto ajudaria o gerenciamento dos administradores JIRA. Quando ficará pronta?

            Check my comment on https://blogs.atlassian.com/2013/11/insight-jira-service-desks-pricing-model/#comment-122275 and please vote and add any additional comments here: JSD-201

            Deleted Account (Inactive) added a comment - Check my comment on https://blogs.atlassian.com/2013/11/insight-jira-service-desks-pricing-model/#comment-122275 and please vote and add any additional comments here: JSD-201

            This is exactly what a customer of ours needs right now. The fact that their customers can see all the Time Tracking information, is not something that is acceptable. Right now I am looking into a workaround, but hiding the Activity Stream gadget is not possible for a certain group. The only possible thing seems to disable it, for everyone.

            Jannik Luyten added a comment - This is exactly what a customer of ours needs right now. The fact that their customers can see all the Time Tracking information, is not something that is acceptable. Right now I am looking into a workaround, but hiding the Activity Stream gadget is not possible for a certain group. The only possible thing seems to disable it, for everyone.

            I'd love to see this feature.

            On a different note, I'm not sure if it would resolve our particular situation:

            We don't want some of our users (external QA, mainly) to see our versions (our Project Road Map), but there is no way to keep the road map working and restrict its visibility to some allowed users (or exclude some others).

            Would that feature help us with this problem?

            Fernando Claros added a comment - I'd love to see this feature. On a different note, I'm not sure if it would resolve our particular situation: We don't want some of our users (external QA, mainly) to see our versions (our Project Road Map), but there is no way to keep the road map working and restrict its visibility to some allowed users (or exclude some others). Would that feature help us with this problem?

            We're on the same boat. We do let clients in but don't want them to see all time estimations.

            Tomasz Banas added a comment - We're on the same boat. We do let clients in but don't want them to see all time estimations.

            We have the same problem as Niklas. We are letting the customers in to JIRA, but we do not like to share the time spent information. View Ports does not seem to solve this problem in a good way. I would much rather see the original problem of field level security solved.

            Anders Ingestedt added a comment - We have the same problem as Niklas. We are letting the customers in to JIRA, but we do not like to share the time spent information. View Ports does not seem to solve this problem in a good way. I would much rather see the original problem of field level security solved.

            Hiding field using plug or Javascript is not an option!
            This is not secure enough, since neither Issue Navigator nor XML-view or export hides it.
            I mean we sell solutions and peace of mind based on value vs. charging hours...
            We want transparency in general, but not in all aspects!

            Niklas Gotting added a comment - Hiding field using plug or Javascript is not an option! This is not secure enough, since neither Issue Navigator nor XML-view or export hides it. I mean we sell solutions and peace of mind based on value vs. charging hours... We want transparency in general, but not in all aspects!

            David, it is not allowed for On-Demand users...

            Normand Carbonneau added a comment - David, it is not allowed for On-Demand users...

            niklas.cambio, rmazurkiewicz and al other only wanting to hide a field: You could 'soft-hide' a field (in the UI) using the CUTE for JIRA Plugin. This is only based on Javasript and hides the field in the UI, not in XML-view or export. But this would be enough for most of you I guess. You could also implement a check to hide the field only for users that a part of a specific gourp (in LDAP/JIRA internal) if you whish to.

            We are working on a how to for this case I might post a link here soon...

            Edit: currently this addon is only allowed for download users, no On-Demonad.

            David Toussaint [Communardo] added a comment - - edited niklas.cambio , rmazurkiewicz and al other only wanting to hide a field : You could 'soft-hide' a field (in the UI) using the CUTE for JIRA Plugin. This is only based on Javasript and hides the field in the UI, not in XML-view or export . But this would be enough for most of you I guess. You could also implement a check to hide the field only for users that a part of a specific gourp (in LDAP/JIRA internal) if you whish to. We are working on a how to for this case I might post a link here soon... Edit: currently this addon is only allowed for download users, no On-Demonad.

            AGREE - We all need is to be able to hide those f... time tracking fields. Nothing more, nothing less. JRA-2364

            Add permissions for those 3 little fields is too complex???

            Radosław Mazurkiewicz added a comment - AGREE - We all need is to be able to hide those f... time tracking fields. Nothing more, nothing less. JRA-2364 Add permissions for those 3 little fields is too complex???

            Niklas Gotting added a comment - - edited

            For our Company, transparency with Customers is a key component. For that reason our setup have been to use one Project the whole way from Bug issue, through Solution issue, followed by a Delivery issue. However with today's limitation that Time tracking including both estimated hours and real hours can't be protected from Customer viewing, we must separate Solution issues in a separate project.
            Bummer

            Niklas Gotting added a comment - - edited For our Company, transparency with Customers is a key component. For that reason our setup have been to use one Project the whole way from Bug issue, through Solution issue, followed by a Delivery issue. However with today's limitation that Time tracking including both estimated hours and real hours can't be protected from Customer viewing, we must separate Solution issues in a separate project. Bummer

            onkeldom added a comment -

            Oh f*** yes! This feature (or the old Field level security) would make my life as a JIRA admin sooooo much easier. +1 form me, hope to see this feature soon!

            onkeldom added a comment - Oh f*** yes! This feature (or the old Field level security) would make my life as a JIRA admin sooooo much easier. +1 form me, hope to see this feature soon!

            Gandalf added a comment -

            I Agree @Bernard, Atlassian has quite some impressive tools and for sure a lot of customers.
            But as shared a lot of times, this issue is open since more than 10 years (at least the original issue). Atlassian is for sure working out a fantastic feature but what I currently need (and I know for sure, lot's of customers too) is to be able to hide those f... time tracking fields.
            Hiding time tracking fields was the original request, nothing more, nothing less.
            We all understand development complexities, priorities and so on...

            But common...10 years, jira agile as @Normand Carbonneau is saying...we're far from it!!!

            I'm following this issue since more than 2 years now...I had a little hope in Jully 2013...and today...we simply don't know what, how, when.

            I believe this is my major concern with Jira!! and in the end maybe a deal breaker.

            Gandalf added a comment - I Agree @Bernard, Atlassian has quite some impressive tools and for sure a lot of customers. But as shared a lot of times, this issue is open since more than 10 years (at least the original issue). Atlassian is for sure working out a fantastic feature but what I currently need (and I know for sure, lot's of customers too) is to be able to hide those f... time tracking fields. Hiding time tracking fields was the original request, nothing more, nothing less. We all understand development complexities, priorities and so on... But common...10 years, jira agile as @Normand Carbonneau is saying...we're far from it!!! I'm following this issue since more than 2 years now...I had a little hope in Jully 2013...and today...we simply don't know what, how, when. I believe this is my major concern with Jira!! and in the end maybe a deal breaker.

            Customer collaboration over contract negotiation ^^
            But we all know how hard it is to implement every feature the customer wishes for. And atlassian has a loooot of customers ^^

            Bernhard Grünewaldt added a comment - Customer collaboration over contract negotiation ^^ But we all know how hard it is to implement every feature the customer wishes for. And atlassian has a loooot of customers ^^

            No news from Atlassian for all that time... And they call it JIRA Agile .
            Hey Atlassian, please read the Agile and SCRUM definitions... Remember, Deliver often by small increments, etc...

            Normand Carbonneau added a comment - No news from Atlassian for all that time... And they call it JIRA Agile . Hey Atlassian, please read the Agile and SCRUM definitions... Remember, Deliver often by small increments, etc...

            Max Doppler added a comment - - edited

            Daily Users: 200 - 240 (50% of it only rarely)
            Active Users: 1.000
            Issues: 45.000 (~17.000 per year)
            Projects: 120

            But the problem was due to large dashboards fewer users.

            Max Doppler added a comment - - edited Daily Users: 200 - 240 (50% of it only rarely) Active Users: 1.000 Issues: 45.000 (~17.000 per year) Projects: 120 But the problem was due to large dashboards fewer users.

            @Marcel:
            I have a hosted version with a 500 User license. And actual 400 users in use together with approximately 60 projects.
            We just did a first installation test on our dev-system and will test the plugin in detail the next weeks on the production system.
            And I really need to hide Time Tracking fields, because of our companies data privacy statements ...

            @Max: Thx for the hint with the performance. I will also look into that. How many users/projects did you have in your installation?

            Bernhard Grünewaldt added a comment - @Marcel: I have a hosted version with a 500 User license. And actual 400 users in use together with approximately 60 projects. We just did a first installation test on our dev-system and will test the plugin in detail the next weeks on the production system. And I really need to hide Time Tracking fields, because of our companies data privacy statements ... @Max: Thx for the hint with the performance. I will also look into that. How many users/projects did you have in your installation?

            @Marcel Lange:
            Note that the original issue (JRA-1330) was reported in 2003, so do not expect anything soon...

            Anders Ingestedt added a comment - @Marcel Lange: Note that the original issue ( JRA-1330 ) was reported in 2003, so do not expect anything soon...

            Max Doppler added a comment - - edited

            We also had the Field Security Plugin in use. Unfortunately we had to remove that with an increasing number of users, because JIRA was no more accessable several times a day. This is due to a bug in the plug-in related with large dashboards. Also with us was suffering the JIRA performance because the plugin does not spread the work across multiple CPUs. We therefore hope that Atlassian will soon offer a proper solution.

            Max Doppler added a comment - - edited We also had the Field Security Plugin in use. Unfortunately we had to remove that with an increasing number of users, because JIRA was no more accessable several times a day. This is due to a bug in the plug-in related with large dashboards. Also with us was suffering the JIRA performance because the plugin does not spread the work across multiple CPUs. We therefore hope that Atlassian will soon offer a proper solution.

            Marcel Lange added a comment - - edited

            @Bernhard Grünewaldt: Big THX for the plugin hint. I'll give it a try. Do you have the hosted version of jira or do you run the application on your own mashine?

            Marcel Lange added a comment - - edited @Bernhard Grünewaldt: Big THX for the plugin hint. I'll give it a try. Do you have the hosted version of jira or do you run the application on your own mashine?

            Gandalf added a comment -

            @Marcel Lange:
            good luck to have an expected date...Atlassian is screwing up to deliver this feature in appropriated time and especially on his lack of being able to hide time tracking fields

            Gandalf added a comment - @Marcel Lange: good luck to have an expected date...Atlassian is screwing up to deliver this feature in appropriated time and especially on his lack of being able to hide time tracking fields

            @Marcel,
            I am also waiting for this. We decided at our company to use this plugin until Jira provides a built in solution:
            https://marketplace.atlassian.com/plugins/com.quisapps.jira.jfs
            It costs some money. But it works fine with my Jira 5.2.4 installation.

            @Atlassian: Please provide information about the releasedate of Viewport Plugin, thx.
            https://www.atlassian.com/viewport

            Bernhard Grünewaldt added a comment - @Marcel, I am also waiting for this. We decided at our company to use this plugin until Jira provides a built in solution: https://marketplace.atlassian.com/plugins/com.quisapps.jira.jfs It costs some money. But it works fine with my Jira 5.2.4 installation. @Atlassian: Please provide information about the releasedate of Viewport Plugin, thx. https://www.atlassian.com/viewport

            We need this feature very fast in our hosted solution! Are there any timings for that Feature?

            Marcel Lange added a comment - We need this feature very fast in our hosted solution! Are there any timings for that Feature?

            @Atlassian
            Seriously, guys, we really need this feature...how long we have to wait?

            Alena Zhytnytska added a comment - @Atlassian Seriously, guys, we really need this feature...how long we have to wait?

            I mean this issue was created mar/12 and the movie was announced Jul/13.

            So the movie production takes 1year+

            @Atlassian - where is the software ???

            rmazurkiewicz added a comment - I mean this issue was created mar/12 and the movie was announced Jul/13. So the movie production takes 1year+ @Atlassian - where is the software ???

            Agree with Jean-Jacques!

            And Atlassian are creating tools to manage development with Agile/SCRUM methodologies
            Multiple, small and incremental deliveries to have constant feedback from the customers... Do you remember Atlassian?

            I just hope we won't have a huge new application that is great, but that is not addressing our real initial needs...

            Normand Carbonneau added a comment - Agree with Jean-Jacques! And Atlassian are creating tools to manage development with Agile/SCRUM methodologies Multiple, small and incremental deliveries to have constant feedback from the customers... Do you remember Atlassian? I just hope we won't have a huge new application that is great, but that is not addressing our real initial needs...

            Gandalf added a comment -

            @Radek Mazurkiewicz, the issue regarding "hiding time tracking fields" is almost open since 10 years!
            View Port would normally solve this.
            In the end, View port could be a great enhancement with lots of enhancements. As user I have the feeling that we will receive a R&R (Rolls Royce) where initially we expected much sooner to have a simple Lada to hide the time tracking fields as most of the information could be public to our customers.

            Gandalf added a comment - @Radek Mazurkiewicz, the issue regarding "hiding time tracking fields" is almost open since 10 years! View Port would normally solve this. In the end, View port could be a great enhancement with lots of enhancements. As user I have the feeling that we will receive a R&R (Rolls Royce) where initially we expected much sooner to have a simple Lada to hide the time tracking fields as most of the information could be public to our customers.

            We had to wait one year to watch nice movie on https://www.atlassian.com/viewport

            rmazurkiewicz added a comment - We had to wait one year to watch nice movie on https://www.atlassian.com/viewport

            Gandalf added a comment -

            @Jira: any news regarding delivery date of this long awaited feature (hiding time tracking fields)?
            Is it still for this century?

            Sorry to be ironic...but this issue has such an old history....

            Gandalf added a comment - @Jira: any news regarding delivery date of this long awaited feature (hiding time tracking fields)? Is it still for this century? Sorry to be ironic...but this issue has such an old history....

            Highly interested in this solution! We'd immediately try it out if there was a version..
            Any info on a possible release date?

            Rembert Gantke added a comment - Highly interested in this solution! We'd immediately try it out if there was a version.. Any info on a possible release date?

            My Kro added a comment - - edited

            As seen in JRA-33804 the ability of any reporter to enter an "Original Estimate" remains a problem for us. When designing our JIRA system the documentation led us to believe that the visibility of Original Estimate on Create Issue screen was controlled by the Work on Issues permissions. Atlassian's response to this was to change the documentation rather than address the underlying need, leaving us with an awkward deployment of our system.

            It would be good if this new Viewport design is able to address this need. To restate; we want global read access to the time-tracking values, but visibility and editability on the Create Issue screen should be limited to specific roles.

            To be truly honest though, a much simpler solution would be to add an "Estimate Issues" permission.

            My Kro added a comment - - edited As seen in JRA-33804 the ability of any reporter to enter an "Original Estimate" remains a problem for us. When designing our JIRA system the documentation led us to believe that the visibility of Original Estimate on Create Issue screen was controlled by the Work on Issues permissions. Atlassian's response to this was to change the documentation rather than address the underlying need, leaving us with an awkward deployment of our system. It would be good if this new Viewport design is able to address this need. To restate; we want global read access to the time-tracking values, but visibility and editability on the Create Issue screen should be limited to specific roles. To be truly honest though, a much simpler solution would be to add an "Estimate Issues" permission.

            Is there any date for the release of Viewport Plugin?

            Bernhard Grünewaldt added a comment - Is there any date for the release of Viewport Plugin?

            atlassian.com/viewport

            Jon Verville added a comment - atlassian.com/viewport

            This kind of approach would work for us. We want to let customers to open tickets and comment but same time hide all work logs and estimates from the customers view. Work logs (and their comments) are after all something that is for internal usage only.

            Tero Heikkinen added a comment - This kind of approach would work for us. We want to let customers to open tickets and comment but same time hide all work logs and estimates from the customers view. Work logs (and their comments) are after all something that is for internal usage only.

            +1. A valid point!

            On Wed, Jun 5, 2013 at 9:22 PM, Normand Carbonneau (JIRA) <


            Regards,
            Arnold Chang

            Arnold Chang added a comment - +1. A valid point! On Wed, Jun 5, 2013 at 9:22 PM, Normand Carbonneau (JIRA) < – Regards, Arnold Chang

            Andreas Wente added a comment - - edited

            .

            Andreas Wente added a comment - - edited .

            dchisholm added a comment -

            View Ports do not solve our needs completely. I have team managers that want to restrict access to fields to our internal team members who otherwise need complete access to all JIRA features. Field permissions are a general user issue - not just an "external users" issue.

            The only way I see this truly working is if the View Ports architecture replaces all the functionality of the current UI. Then the View Port app can implement field level permissions, while backwards compatibility is maintained with the current UI. Eventually the current app becomes a backend engine, and the current UI is phased out by providing a migration tool to move configurations into the View Port app.

            dchisholm added a comment - View Ports do not solve our needs completely. I have team managers that want to restrict access to fields to our internal team members who otherwise need complete access to all JIRA features. Field permissions are a general user issue - not just an "external users" issue. The only way I see this truly working is if the View Ports architecture replaces all the functionality of the current UI. Then the View Port app can implement field level permissions, while backwards compatibility is maintained with the current UI. Eventually the current app becomes a backend engine, and the current UI is phased out by providing a migration tool to move configurations into the View Port app.

            Gandalf added a comment -

            I totally agree with "Normand Carbonneau"...very good question indeed!
            As I said in a previous comment...10 years since the original issue was raised regarding time tracking ;(;(;(;(

            Gandalf added a comment - I totally agree with "Normand Carbonneau"...very good question indeed! As I said in a previous comment...10 years since the original issue was raised regarding time tracking ; (; (; (; (

            I like that question . Why Atlassian is not exposing their time entries to all of us if they consider hiding time entries is not important?

            Normand Carbonneau added a comment - I like that question . Why Atlassian is not exposing their time entries to all of us if they consider hiding time entries is not important?

            Andreas Wente added a comment - - edited

            Hi,
            we use JIRA for about 6 month now. We just opened it for our customers and guess what.....
            ... we need to hide time tracking information from them. I also think viewports are not a proper solution for that, because our customer need access to all other features of JIRA. So I think field level security is the only answer to that.

            @Shihab: Where do you log your time working on this issue?

            Andreas Wente added a comment - - edited Hi, we use JIRA for about 6 month now. We just opened it for our customers and guess what..... ... we need to hide time tracking information from them. I also think viewports are not a proper solution for that, because our customer need access to all other features of JIRA. So I think field level security is the only answer to that. @Shihab: Where do you log your time working on this issue?

            View ports do not sound like a sufficient answer to restricting access to time tracking. The feature may be useful in some other extent, but restricting access to time tracking means just removing that one aspect, not removing all the other functionality from JIRA for certain end users.

            I'm new to JIRA and I am a little shocked that such a feature is either all on or all off. I'd love to use it, but I cannot expose that information to every user.

            William Howell added a comment - View ports do not sound like a sufficient answer to restricting access to time tracking. The feature may be useful in some other extent, but restricting access to time tracking means just removing that one aspect, not removing all the other functionality from JIRA for certain end users. I'm new to JIRA and I am a little shocked that such a feature is either all on or all off. I'd love to use it, but I cannot expose that information to every user.

            Patrick Ford added a comment - - edited

            Viewports looks like an interesting feature and I'm looking forward to having it as a option but I feel like this solution doesn't fulfill the requirements outlined in previous, now closed tasks. In some ways I think discussing viewports is a deflection because there is so much resistance to implementing a very straightforward request. I don't mean to imply that the implementation is simple but the requests itself is.

            My organization would like the ability to specify whether time tracking & worklog are viewable for specific groups. That's it. So if we were to create a group and not grant the group access to time tracking they would not see...(some of these have been pulled directly from previous comments)

            1. Time spent field in any gadget
            2. Worklog entries in activity stream
            3. Time tracking in right column of the issue page
            4. Worklog tab on issue page
            5. Worklogs within the history tab on the issue page
            6. Worklogs within the activity tab on the issue page
            7. Worked time on the people page of the project page
            8. The search result list (where the user can manually add the column)?
            9. In Greenhopper, when you wish to include the time tracking information for the developers?
            10. When receiving email-notifications when the change includes updated time tracking data?
            11. When accessing Jira via the WebService/REST apis?
            12. Different export types
            13. SOAP
            14. Basically anywhere actual hours (time spent) is displayed

            It would be helpful to have a better understanding of whether this option will ever be available in Jira. If no, I'll look for another solution, if yes - give me a timeframe. If the above requirements aren't clear I'd be happy to explain further. Jira has been an excellent product but the absence of this single feature has keep my company from considering other products such as GreenHopper, Confluence, and Stash. We just feel like we can't go all in b/c we know that we'll have to switch to a different product at some point in order to allow our clients direct access to the platform we use to manage projects.

            Give me some good news........please.

            Patrick Ford added a comment - - edited Viewports looks like an interesting feature and I'm looking forward to having it as a option but I feel like this solution doesn't fulfill the requirements outlined in previous, now closed tasks. In some ways I think discussing viewports is a deflection because there is so much resistance to implementing a very straightforward request. I don't mean to imply that the implementation is simple but the requests itself is. My organization would like the ability to specify whether time tracking & worklog are viewable for specific groups. That's it. So if we were to create a group and not grant the group access to time tracking they would not see...(some of these have been pulled directly from previous comments) 1. Time spent field in any gadget 2. Worklog entries in activity stream 3. Time tracking in right column of the issue page 4. Worklog tab on issue page 5. Worklogs within the history tab on the issue page 6. Worklogs within the activity tab on the issue page 7. Worked time on the people page of the project page 8. The search result list (where the user can manually add the column)? 9. In Greenhopper, when you wish to include the time tracking information for the developers? 10. When receiving email-notifications when the change includes updated time tracking data? 11. When accessing Jira via the WebService/REST apis? 12. Different export types 13. SOAP 14. Basically anywhere actual hours (time spent) is displayed It would be helpful to have a better understanding of whether this option will ever be available in Jira. If no, I'll look for another solution, if yes - give me a timeframe. If the above requirements aren't clear I'd be happy to explain further. Jira has been an excellent product but the absence of this single feature has keep my company from considering other products such as GreenHopper, Confluence, and Stash. We just feel like we can't go all in b/c we know that we'll have to switch to a different product at some point in order to allow our clients direct access to the platform we use to manage projects. Give me some good news........please.

            I could not add any better ideas to JJ's. Hope you really listen to your customers and get it improved shortly.
            Cheers!

            Arnold Chang added a comment - I could not add any better ideas to JJ's. Hope you really listen to your customers and get it improved shortly. Cheers!

            I fully agree with Jean-Jacques: it is definitely necessary to give a real Jira access to some customer employees - for example when they are involved in QA. Not granting access to Jira is huge impact on the workflow.
            But exposing the timetracking to them is an even worse impact - this time on the whole business relation with the customer.

            We all are in IT business so we all know: sometimes it's hard, but there is always a solution!

            In our projects we do not support field security as well, but we generate different views for different user groups on the presentation layer.

            As far as I understand, the Viewport is not of that kind, it is an external/limited access to use some basic Jira features, right? If this includes that these users do not count against the licenced users, it is good idea as well!

            Cheers
            BR

            Bernd Rudolf added a comment - I fully agree with Jean-Jacques: it is definitely necessary to give a real Jira access to some customer employees - for example when they are involved in QA. Not granting access to Jira is huge impact on the workflow. But exposing the timetracking to them is an even worse impact - this time on the whole business relation with the customer. We all are in IT business so we all know: sometimes it's hard, but there is always a solution! In our projects we do not support field security as well, but we generate different views for different user groups on the presentation layer. As far as I understand, the Viewport is not of that kind, it is an external/limited access to use some basic Jira features, right? If this includes that these users do not count against the licenced users, it is good idea as well! Cheers BR

            Gandalf added a comment -

            @shihab
            viewport seems indeed to include some interesting features like you described in you latest comment although they seem to be secondary to a long awaited feature which is "possibility to hide the time tracking fields"!
            I had the chance to meet different jira users and they all confirm that they need such a feature in order to truly open their jira environment to customer.
            This topic is open since more than 10 years (started with the discussion about security fields #jira-1330) and even today there is still no solution to it
            It's quite surprising (and concerning) that Atlassian, after such a long period, can still not find a proper solution to solve hthis fundamental request.
            Common guys, you do such a terrific job in order to provide us with a great tool but leaving us with a bitter taste regarding hiding time tracking tracking.
            Don't get me wrong, I understand technical impediments which in this case is time and effort needed to solve issues which on paper seems to be easy but have a deep impact in the source code. But on the other hand we all know that in the end a technical solution can be provided if Atlassian is willing to.
            I'm convinced a whole bunch of jira customer would be grateful once this issue will be solved once and for all...

            Cheers,

            JJ

            Gandalf added a comment - @shihab viewport seems indeed to include some interesting features like you described in you latest comment although they seem to be secondary to a long awaited feature which is "possibility to hide the time tracking fields"! I had the chance to meet different jira users and they all confirm that they need such a feature in order to truly open their jira environment to customer. This topic is open since more than 10 years (started with the discussion about security fields #jira-1330) and even today there is still no solution to it It's quite surprising (and concerning) that Atlassian, after such a long period, can still not find a proper solution to solve hthis fundamental request. Common guys, you do such a terrific job in order to provide us with a great tool but leaving us with a bitter taste regarding hiding time tracking tracking. Don't get me wrong, I understand technical impediments which in this case is time and effort needed to solve issues which on paper seems to be easy but have a deep impact in the source code. But on the other hand we all know that in the end a technical solution can be provided if Atlassian is willing to. I'm convinced a whole bunch of jira customer would be grateful once this issue will be solved once and for all... Cheers, JJ

            Esther turner added a comment - - edited

            I need a solution for hiding time tracking fields from Certain User groups and based on the last comment, the ViewPort solution described above will not work. Is there an alternative solution we can expect in the near term?

            Esther turner added a comment - - edited I need a solution for hiding time tracking fields from Certain User groups and based on the last comment, the ViewPort solution described above will not work. Is there an alternative solution we can expect in the near term?

            shihab added a comment -

            Hey,

            Viewport will allow you to tailor an interface to JIRA that encourages your end users to create, view and collaborate on requests, while your internal teams take advantage of the full power of JIRA to process these issues.

            The Viewport interface has been designed from the ground up with the aim to provide an optimal experience for users - and as it is a distinct interface to JIRA, we are able to hide fields, rename fields, re-map statuses and the like.

            am, we believe that Viewport will actually make use cases such as using JIRA as a support system even more appealing as it will allow admins tailor JIRA to sound more like a support system.

            • Hide fields that don't make sense to those that are making requests or data that you don't want to reveal to them, like time tracking, the issue assignee, or issue labels
            • Instead of "Summary" you will be able do ask your users to "Describe the problem you are experiencing"
            • You will be able to add custom descriptions to fields and link out external systems or documentation
            • You can present clear calls to action for your end user, so you might have "Support Ticket" as your issue type, but create issue templates for "Report a system fault", "Request a password reset", etc and have the correct issue information pre-populated for your support team.
            • You could internally have statuses such as "Waiting for Developer" but still present an "In Progress" status for your customer.

            We think Viewport will enable you to craft solutions like this for a variety of use cases including customer support, internal IT service desk, change management - as well as those outside of software development like purchase order approvals and office admin requests.

            sascha.meyer/ncarbonneau: If your QA team or your customers/clients do really need full access to JIRA and features like full JQL searching, dashboards, rapid boards or reports - but you just need to hide a few fields from them in all possible places in JIRA - then unfortunately Viewport will not solve this problem in the near term.

            Cheers,

            -Shihab

            shihab added a comment - Hey, Viewport will allow you to tailor an interface to JIRA that encourages your end users to create, view and collaborate on requests, while your internal teams take advantage of the full power of JIRA to process these issues. The Viewport interface has been designed from the ground up with the aim to provide an optimal experience for users - and as it is a distinct interface to JIRA, we are able to hide fields, rename fields, re-map statuses and the like. am , we believe that Viewport will actually make use cases such as using JIRA as a support system even more appealing as it will allow admins tailor JIRA to sound more like a support system. Hide fields that don't make sense to those that are making requests or data that you don't want to reveal to them, like time tracking, the issue assignee, or issue labels Instead of "Summary" you will be able do ask your users to "Describe the problem you are experiencing" You will be able to add custom descriptions to fields and link out external systems or documentation You can present clear calls to action for your end user, so you might have "Support Ticket" as your issue type, but create issue templates for "Report a system fault", "Request a password reset", etc and have the correct issue information pre-populated for your support team. You could internally have statuses such as "Waiting for Developer" but still present an "In Progress" status for your customer. We think Viewport will enable you to craft solutions like this for a variety of use cases including customer support, internal IT service desk, change management - as well as those outside of software development like purchase order approvals and office admin requests. sascha.meyer / ncarbonneau : If your QA team or your customers/clients do really need full access to JIRA and features like full JQL searching, dashboards, rapid boards or reports - but you just need to hide a few fields from them in all possible places in JIRA - then unfortunately Viewport will not solve this problem in the near term. Cheers, -Shihab

            Shihab,

            regarding the comments of Sascha and Normand:

            As a ViewPort Administrator, I would expect to be able define in JIRA a strict subset of fields and data for a group of "outsiders" e.g. by using "ViewPort enhanced" JQL (I think the tricky part would be to limit also on a value level e.g. access to the field of assignable users but only for a subset of users, not to users within JIRA).

            And based on this subset, you could provide standard JQL to an "outsider" within ViewPort because they would operate entirely on a subset of data.

            BTW:
            I don't know if I'm happy about the fact that you plan to open up JIRA for new target groups within the company.... Why? My concerns: Atlassian is losing the sight of existing customer base and especially their use-cases (Software Development with customer integration, JIRA as a support system, Project Management etc.), currently struggling with missing features in the daily JIRA ...business.

            -AM-

            Deleted Account (Inactive) added a comment - Shihab, regarding the comments of Sascha and Normand: As a ViewPort Administrator, I would expect to be able define in JIRA a strict subset of fields and data for a group of "outsiders" e.g. by using "ViewPort enhanced" JQL (I think the tricky part would be to limit also on a value level e.g. access to the field of assignable users but only for a subset of users, not to users within JIRA). And based on this subset, you could provide standard JQL to an "outsider" within ViewPort because they would operate entirely on a subset of data. BTW: I don't know if I'm happy about the fact that you plan to open up JIRA for new target groups within the company.... Why? My concerns: Atlassian is losing the sight of existing customer base and especially their use-cases (Software Development with customer integration, JIRA as a support system, Project Management etc.), currently struggling with missing features in the daily JIRA ...business. -AM-

            Hi Shihab,

            Thanks for the comments. Here is my main use case:
            We have two types of projects with different customers around the world. We have fix bid projects and T&M projects. For T&M projects, we can give complete access to our development project in JIRA to the customer, including time tracking because the customer is paying based on the number of hours, so, it makes sense.

            But for fix bid projects, we cannot allow the customer to see the number of hours. So, actually, we have to create 2 different projects: one internal for our development process, and another one exposed to the customer without any time tracking.

            And like Sascha, our customers are used to JQL and everything in JIRA, so, they need it. Hope it helps clarify our needs.

            Thanks, Normand

            Normand Carbonneau added a comment - Hi Shihab, Thanks for the comments. Here is my main use case: We have two types of projects with different customers around the world. We have fix bid projects and T&M projects. For T&M projects, we can give complete access to our development project in JIRA to the customer, including time tracking because the customer is paying based on the number of hours, so, it makes sense. But for fix bid projects, we cannot allow the customer to see the number of hours. So, actually, we have to create 2 different projects: one internal for our development process, and another one exposed to the customer without any time tracking. And like Sascha, our customers are used to JQL and everything in JIRA, so, they need it. Hope it helps clarify our needs. Thanks, Normand

            Thanks for your responses to my post!

            I think I have to clarify our use case.

            We are developing software for our customers and have three major roles working on an issue

            • Product Management
            • Development
            • QA

            Every role needs to have the fully JIRA functionality like Dashboards and JQL, but we are only using the time tracking for development puposes. This is why we only want to have the time tracking visible for devekopers. Moreover our works council demands us to have it only visible for the development department and not for others like QA.

            I understand thart ViewPort will not cover our use case - or am I wrong?

            Regards,
            SaM

            Sascha Meyer added a comment - Thanks for your responses to my post! I think I have to clarify our use case. We are developing software for our customers and have three major roles working on an issue Product Management Development QA Every role needs to have the fully JIRA functionality like Dashboards and JQL, but we are only using the time tracking for development puposes. This is why we only want to have the time tracking visible for devekopers. Moreover our works council demands us to have it only visible for the development department and not for others like QA. I understand thart ViewPort will not cover our use case - or am I wrong? Regards, SaM

            shihab added a comment -

            Hey guys,

            Thanks for your thoughts on the issue!

            Viewport is about tailoring the JIRA experience for users that need to create and track their request. The main goal of Viewport is to make it possible for administrators to define an "outsider" or "end user" class of users on a project and simplify the interaction the end users have with JIRA - from the user interface through to email notifications.

            We're trying to help teams do more with JIRA - IT helpdesk requests, finance approvals, HR processes and even office administration can be mapped to JIRA projects with appropriate issue types and workflows. Viewport enables these teams to provide an easy way for their end users to create and track their requests so that the teams servicing the requests can use the power of JIRA to manage the issues.

            One of the features of Viewport that we're planning on providing is the ability to hide internal fields from the view of "outsiders" or "end users" - fields like time tracking. JRA-1330 is about hiding fields from every possible spot in JIRA for a certain class of users, whereas with Viewport, end users can be restricted to only have access to JIRA through the Viewport interface - they will not have access to JIRA features such as JQL searching or dashboards.

            We do plan on delivering value incrementally with an MVP first. Many of the aspects of Viewport are interrelated so it's not possible for us to ship the ability to "hide time-tracking" without some of the other capabilities. If you would like to get involved in the early access program for Viewport and try out early builds of the plugin, please sign up on www.atlassian.com/viewport - we'll be reaching out to those that have signed up once we're closer to an early milestone of Viewport.

            Cheers,

            -Shihab

            shihab added a comment - Hey guys, Thanks for your thoughts on the issue! Viewport is about tailoring the JIRA experience for users that need to create and track their request. The main goal of Viewport is to make it possible for administrators to define an "outsider" or "end user" class of users on a project and simplify the interaction the end users have with JIRA - from the user interface through to email notifications. We're trying to help teams do more with JIRA - IT helpdesk requests, finance approvals, HR processes and even office administration can be mapped to JIRA projects with appropriate issue types and workflows. Viewport enables these teams to provide an easy way for their end users to create and track their requests so that the teams servicing the requests can use the power of JIRA to manage the issues. One of the features of Viewport that we're planning on providing is the ability to hide internal fields from the view of "outsiders" or "end users" - fields like time tracking. JRA-1330 is about hiding fields from every possible spot in JIRA for a certain class of users, whereas with Viewport, end users can be restricted to only have access to JIRA through the Viewport interface - they will not have access to JIRA features such as JQL searching or dashboards. We do plan on delivering value incrementally with an MVP first. Many of the aspects of Viewport are interrelated so it's not possible for us to ship the ability to "hide time-tracking" without some of the other capabilities. If you would like to get involved in the early access program for Viewport and try out early builds of the plugin, please sign up on www.atlassian.com/viewport - we'll be reaching out to those that have signed up once we're closer to an early milestone of Viewport. Cheers, -Shihab

            I totally agree with you Stijn.

            I was not talking about a patch. I also want a solid architecture for these new views.
            But I was more thinking to release these views with less features at first, and then building new features each release instead of trying to come up with 50 features upfront.

            This way, we can start using it quicker!

            Normand Carbonneau added a comment - I totally agree with you Stijn. I was not talking about a patch. I also want a solid architecture for these new views. But I was more thinking to release these views with less features at first, and then building new features each release instead of trying to come up with 50 features upfront. This way, we can start using it quicker!

            stijn added a comment -

            Not really following your view (pun intended) on this.
            Imo they are being pragmatic: if you look at some of the fixes proposed in the original 'hide timetracking' issue's comments it's obvious that tracking is baked deeply into Jira so there's no way to quickly fix this in a nice way.
            So instead of a quick hack that does a single thing that's useful for some but not for everyone,
            Atlassian wants to fix it properly once and for all in a way that is more extendible and better suited for all customers.
            In my experience, if you have a company writing software that follows the first principle you get a piece of cr*p built out of hacks which in the end causes all kind of nasty bugs..
            In the second case, you get something that is usable and fixable, and satisfies more needs in the end.

            stijn added a comment - Not really following your view (pun intended) on this. Imo they are being pragmatic: if you look at some of the fixes proposed in the original 'hide timetracking' issue's comments it's obvious that tracking is baked deeply into Jira so there's no way to quickly fix this in a nice way. So instead of a quick hack that does a single thing that's useful for some but not for everyone, Atlassian wants to fix it properly once and for all in a way that is more extendible and better suited for all customers. In my experience, if you have a company writing software that follows the first principle you get a piece of cr*p built out of hacks which in the end causes all kind of nasty bugs.. In the second case, you get something that is usable and fixable, and satisfies more needs in the end.

            Totally agree with Sascha and JJ.

            Have you guys at Atlassian already heard about something named AGILE?
            It means that you deliver business value at first and very quick to the customer and then add other features in an incremental method. And the features that will be delivered in the next sprint are decided, well in the world where I work, by the customer, based on what he needs.
            So, funny flashy things that developers want to implement are very often left to the bottom of the list because they... are not important and do not add any business value!

            And the features the customer wants because they represent BUSINESS VALUE, are on the top of the list and delivered quickly, because in the real world, if the customer does not have what he needs, he is not going to be one of my customer anymore.

            You at Atlassian have a GREAT tool to know which features are on top of the list, it is the number of votes. Actually, it gives us the feeling that we are deciding something by voting, but if I look at the number of years top voted issues are staying there, I must admit that customers do not have a great power for Atlassian... Unfortunately...

            Please give us the tools we need to do our work EVERY DAY. Each hour we spend trying to figure out workarounds is time we do not spend in our business. You have a great product, but these important features that you ignore for years are generating a lot of frustration for your customers.

            Thanks.

            Normand Carbonneau added a comment - Totally agree with Sascha and JJ. Have you guys at Atlassian already heard about something named AGILE ? It means that you deliver business value at first and very quick to the customer and then add other features in an incremental method. And the features that will be delivered in the next sprint are decided, well in the world where I work, by the customer, based on what he needs. So, funny flashy things that developers want to implement are very often left to the bottom of the list because they... are not important and do not add any business value! And the features the customer wants because they represent BUSINESS VALUE , are on the top of the list and delivered quickly, because in the real world, if the customer does not have what he needs, he is not going to be one of my customer anymore. You at Atlassian have a GREAT tool to know which features are on top of the list, it is the number of votes. Actually, it gives us the feeling that we are deciding something by voting, but if I look at the number of years top voted issues are staying there, I must admit that customers do not have a great power for Atlassian... Unfortunately... Please give us the tools we need to do our work EVERY DAY . Each hour we spend trying to figure out workarounds is time we do not spend in our business. You have a great product, but these important features that you ignore for years are generating a lot of frustration for your customers. Thanks.

            Gandalf added a comment -

            @sascha Meyer: I totaly agree with your point of view. This feature is expected since a very, very, VERY long time, it's limiting us in opening our environment to key customers (for follow-up/ process transparency...) only because we don't want to share the effective effort of a story/task...
            @Jira: cut the crap, be pragmatic and find a way to hide the time tracking field!

            Gandalf added a comment - @sascha Meyer: I totaly agree with your point of view. This feature is expected since a very, very, VERY long time, it's limiting us in opening our environment to key customers (for follow-up/ process transparency...) only because we don't want to share the effective effort of a story/task... @Jira: cut the crap, be pragmatic and find a way to hide the time tracking field!

            Well, it looks like ViewPort will be a very powerful and highly customizable approach - but is this not taking a sledgehammer to crack a nut?
            From my point of view we just want to hide the Time Tracking fields for different user groups (internally) without having to deploy and andminister a completely alternative view.

            Keep it smart and simple

            Sascha Meyer added a comment - Well, it looks like ViewPort will be a very powerful and highly customizable approach - but is this not taking a sledgehammer to crack a nut? From my point of view we just want to hide the Time Tracking fields for different user groups (internally) without having to deploy and andminister a completely alternative view. Keep it smart and simple

            Grrr! Again the regular and extremely painful missing-this-feature-in-JIRA-if-you-share-JIRA-with-external-parties suffering day.

            Why? Because of this.

            Atlassian, if you plan to provide a (I must admit: a very powerful) issue search feature within ViewPort (like in JIRA), please do make sure that you prevent the digging-in-existing-users-groups-labelvalues-and-custom-fields-feature - not only via autocomplete, but also probing via exact matches.

            Sigh ...I'm really looking forward to ViewPort.

            Deleted Account (Inactive) added a comment - Grrr! Again the regular and extremely painful missing-this-feature-in-JIRA-if-you-share-JIRA-with-external-parties suffering day. Why? Because of this . Atlassian, if you plan to provide a (I must admit: a very powerful) issue search feature within ViewPort (like in JIRA), please do make sure that you prevent the digging-in-existing-users-groups-labelvalues-and-custom-fields-feature - not only via autocomplete, but also probing via exact matches. Sigh ...I'm really looking forward to ViewPort.

            mdoar - ViewPort is under development. See Shihab's comment above about the concept site. We expect to have something in alpha for customers in a few months. Feel free to contact Shihab directly via email to get on that list.

            Scott Farquhar added a comment - mdoar - ViewPort is under development. See Shihab's comment above about the concept site. We expect to have something in alpha for customers in a few months. Feel free to contact Shihab directly via email to get on that list.

              Unassigned Unassigned
              shamid@atlassian.com shihab
              Votes:
              194 Vote for this issue
              Watchers:
              195 Start watching this issue

                Created:
                Updated:
                Resolved: