I can't add due date to tasks

[Hernán Gorino]

Hi! I Have a project (created like a Scrum Project) with a Dashboard. In the dashboard I can see all the tasks of my product backlog (with a preview data with some fields).

I need to see in any task that I has in the dashboard, the EXPIRATION DATE (this is a filed that containts the task).

[Joe Pitt]

Do you have the scheduling permission? 

[Hernán Gorino]

Which is this permission? How can I set this this permission for my user?

Do you have Skype or other tool to chat about this topic?

Thanks

[Joe Pitt]

No, I don't have skype or other tool. We're restricted using anything but the phone for outside communications.  My first question, are you a JIRA admin? The permissions are controlled by the permission scheme applied to the project. Permission schemes are managed by the JIRA admin. Being new I'm presuming your company is new to using JIRA. Below are some suggestions that will make using JIRA easier and eliminate some issues almost all JIRA users have problems with. 

First, by default JIRA has a horrible permission scheme that violates security best practices by allowing everyone that can logon to do just about everything.

JIRA works by GRANTING access. You can't restrict access. By default, it grants access to the group used to logon (see Global permissions to see the "can use" groups and admin groups).  This is where users are getting the access from.

1. The FIRST thing you need to do to get control is to remove any groups with logon privileges from the permission scheme unless you absolutely want everyone to have that permission.
2. Then I suggest you setup Project Roles for the various functions like, tester, QA, Browse Only, etc.
3. One permission scheme will cover almost all projects. The project admin controls project role membership

This may be a big effort, but it will pay off down the road by making it easy to control access.

Most of the 'old timers' use project roles. It meets the best practice for security and gives complete control to the project lead for access to their project. JIRA comes with many project roles, but you can add more if you have a special need.

Do not delete issues. When you delete it is GONE. Hardly a week goes by without someone wanting to restore an issue. Deleting issues will come back and bite you when it is the most inconvenient. I suggest closing with a resolution value of Deleted anything you want to delete. I implement a special transition only the project lead can execute and it requires filling in a reason field from a select list (such as entered in error, OBE, Duplicate, Other) and explanation text.

Missing issue numbers will eventually cause a question about what it was and why was it deleted even if it was done properly. Missing data always brings in the question of people hiding something that may have looked bad.

The only viable way to restore an issue is to create a new instance of JIRA and restore a backup that has the issues. Then export them to a csv file and import them to your production instance. You will lose the history.

Do not delete users

Users should be made inactive not deleted. JIRA uses a pointer to the user’s DB entry to display user information. If you delete a user when you open a JIRA issue the user worked on anywhere the user that would be displayed will cause a SQL error. Even if the user never logged on, if they were assigned a ticket the history of the ticket will get an error when you display it.