How do you create your screens for issues? Do you like to have them as one screen for each purpose of creation, edit, and view, or do you like to have a separate screen for creation and edit/view?
I really interested to see what everyone is doing. I have read the documentation on how to but it really up to the admins and users to configure these how they want. There is I know a best practice but I am interested in every ones thoughts on this.
Thanks for the feed back. I am self taught and ran into some issue with screens as I been using one screen to define it all. I am working toward my admin certs and want to start to use a better practice so we can make fields appear after words like during the view and or edit. I will be doing lots of copying here soon to get these screens adjusted.
When I first started I remember someone saying at least a creation and edit. Than he didn't use view or something like that. I would think view would show all detail that needs to be seen on the ticket as it is in a close state for all notes?
Generally Edit and View screens can have the same fields (as Nic recommends), except @Dirk Ronsmans mentions a good case for storing read-only/dynamic custom fields on the View screen.
Nic's right - whether you use a single or multiple screens depends on your situation. I prefer individual screens to make edits later (if you choose to do so) easier. But it IS a preference, and not a best practice... 😉
U can always start with the same screen for edit/view and if needed duplicate it and change it then :)
That's how I usually work! (only make an extra one if needed :))
Oh, multiple screens, in most cases.
But. Always do the requirement analysis. There is no "best practice" though, you should always work to do the "good practice that works best for your people in the environment you all work in".
My guidelines:
(Exception - don't put some automated/scripted/calculated fields on view. I often add scripted fields that do things like "show number of attachments", "show number of sub-tasks", and so-on. People don't need them in issue view, only search and reporting)
Thanks for the feed back. It is appreciated. I will start to view towards some big changes then.
I agree with all the previous answers but would like to leave u with one exception.
Yes, normally u would work with 2 screens
But, for some projects I tend to split up the edit and view screen.
Why? Well a very simple reason and a shortcoming in JIRA. If you want to create a read-only field you don't have any way of doing this out of the box except for a small trick where you show it on the "view" screen but don't add it on the "Edit" screen. This stops it being editable from the view screen directly or the Edit screen and in essence has a read-only field.
Only draw-back here is that is is still editable through a bulk action.
Add-ons exist to fix this (such as behaviours) but if you don't have those, this is a little trick. (and afaik, Cloud does not have behaviours either)
Good call on the read-only fields Dirk!
Thanks for the response and head up. I do understand the concepts and when I first started on this I started from the ground up no prior knowledge and made lots of mistakes and some those mistakes I continued to replicate. I then found out it was not so much a mistake as probably not great practice as I lose control with I don't have the separation of screens stated in this discussion.
I really do appreciate all the feedback. It will make me a better admin and also help me with my certs and understandings.
Another use case is when you have "old fields" that you don't need to use anymore, but you need to keep as visible for old issues.
The new issues don't use those "old fields", so you don't add them to the create and edit screens.
The view screen still has the "old fields", just to be seen if you look for an old issue.