It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Screen fields search

How we could limit fields on screens search ?

I want only see this fields wchich are on project how could I limit them ?

2 answers

0 votes

You can't.  Because you don't always know what the project is, and even if you did, the user might change it, and that would mean adding/removing the fields dynamically.

In short, it's a monumental pain to try to do this dynamically, and there's little value in doing it.

But when I have got for example 2000 project how I will find the field wchich I looking for in the screen?

Look at the project, and an issue within it.

Sorry. I don't understand this annswer. But I can't see in the search only this fields which I have got in project ? In 2000 project I could have got maybe 100000 fields :(

Ok, that's either very scary, or you're not using "fields" to mean "JIRA fields". Could you explain? Do you really have 100,000 fields listed when you go to Admin -> custom fields ?

Sometimes it will be global field for most project. And sometimes could It beproject which have got unical fields. This field which only this field will have. How could I set tchem only for one project ? Please Nic Brought help.

Please, answer the question I've asked. What do you mean by "field" here? Do you really have 100,000 fields?

I'm worry that i will have a lot of fields. In Sharepoint all list was have a lot of unical fields. Only for this list - project. So I vorry that if I will have got 2000 project for example I will dont find a field in Screen

Then don't create 100,000 fields. It's not going to be of any value. I think you need to step back from what you are doing and analyse it properly. Why would you want 100,000 fields? What's the model?

I told to much. It could be 8000 fields. But how to do to see only this field which are on the project? On Screen Search, and on Issue Navigator. Only this fields which are on the project. Please Nic help.

8000 is still several thousand too many to be useful. To see what fields are used in a project, you will have to read through the screen schemes, field configuration and field contexts for each field to work out which ones are valid. Seriously, I think you've got a broken approach to your requirements here. Could you explain what you're trying to do that means you'd end up with 8,000 fields?

Now we have got a Sharepoint. With a lot of list. And a plan is to migrate all this list to Jira. That's why that a lot of fields.

And how to use screen Schemes, and context to see only this fields what we wan't to see?

Sharepoint into JIRA? That does not make a lot of sense. Jira is an issue tracker, Sharepoint is where documents go to die. They're for very different things. I'd suggest revising your data requirements (if not the software choice) - what are these 8,000 fields actually for? Screen schemes, context and field configurations work together to present the user with fields set up in the way they need them. See for a starter (the diagram is quite handy)

Jira with confluence advantages. But I listien from Jobin Kuruvilla that Confluence isn't for documents too.What is Your Nic opinion. It could store a lot of documents ? For about 3000 t0 5000 documents ? In Confluence.

I've worked with Confluences a couple of hundred times that size. But you need to think about what you're doing. Confluence can handle documents as attachments, but it is NOT a management system for them. If you want to store static document *objects*, use a document management system. If you want to store documents as living pages, then Confluence is an excellent choice.

So we could store documents like in folders on the pages ?And get tchem from there ?How to import documents from Confluence Nic ? A structure of documents.

No, that's the point. An attachment in both JIRA and Confluence simply sits on the issue or page you put it on. No trees or folders, minimal metadata, basic searches. They are not about document object management, one is for issue tracking and processes, the other for writing things (including documents) as *live* pages. The last time I was lumbered with Sharepoint, we converted it properly - wrote a script to import all the required word documents as Confluence pages. Once they became live pages, the users actually started to use them.

And how build a driling tree from documents ? Please Nic told.

If they're done as Confluence pages, there's a tree hierarchy. If they're attachments, not a lot you can do

Where can i find tree hierarchy. What should i click.

Try the page tree macro

Thanks I put this on the Page.

Hello Grzegorz, If I could suggest one other thing (otherwise you will exhaust @Nic Brough [Adaptavist] completely) please have a look at a very good course in JIRA administration by here: Only $25 and you will save yourself a lot of self-discovery and ploughing through the Atlassian documentation.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira Core

How to manage many similar workflows?

I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...

3,652 views 11 5
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you