Screen fields search

[Zawistowski Grzegorz]

How we could limit fields on screens search ?

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

[Bogdan Gorka]

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 Lynda.com here: http://www.lynda.com/JIRA-tutorials/Installing-Administering-Atlassian-JIRA/191943-2.html Only $25 and you will save yourself a lot of self-discovery and ploughing through the Atlassian documentation.

[Nic Brough -Adaptavist-]

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.

[Zawistowski Grzegorz]

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

[Nic Brough -Adaptavist-]

Look at the project, and an issue within it.

[Zawistowski Grzegorz]

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 :(

[Nic Brough -Adaptavist-]

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 ?

[Zawistowski Grzegorz]

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.

[Nic Brough -Adaptavist-]

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

[Zawistowski Grzegorz]

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

[Nic Brough -Adaptavist-]

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?

[Zawistowski Grzegorz]

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.

[Nic Brough -Adaptavist-]

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?

[Zawistowski Grzegorz]

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.

[Zawistowski Grzegorz]

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

[Nic Brough -Adaptavist-]

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 https://confluence.atlassian.com/jira/configuring-fields-and-screens-187859099.html for a starter (the diagram is quite handy)

[Zawistowski Grzegorz]

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.

[Nic Brough -Adaptavist-]

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.

[Zawistowski Grzegorz]

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.

[Nic Brough -Adaptavist-]

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.

[Zawistowski Grzegorz]

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

[Nic Brough -Adaptavist-]

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

[Zawistowski Grzegorz]

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

[Nic Brough -Adaptavist-]

Try the page tree macro

[Zawistowski Grzegorz]

Thanks I put this on the Page.