Nic Brough -Adaptavist- Expert

You don't have any access to the database behind Cloud, so I'm a bit stuck on what you're doing. Even if you did have access to the database, you would be looking at the wrong tables. Could you explain what you are trying to do instead of how? What do your end users get from what you are trying to do?

We do not know what "unit curent" is. I suspect it is a term you use inside your organisation, but even if I assume that, I don't know how your organisation uses it. You will need to explain how this relates to Jira in more detail if you want a useful answer here. I will take a bit of a guess though - I think you mean that…

You did not propose any operators, you gave us a list of rules you might want to impose. The reason "labels != <label>" ignores unlabelled issues is explained in the previous answers and comments. If you are interested in unlabelled issues, then add them to the search with "or labels is empty"

They're in the content tables as given above. Could you explain what you are actually trying to achieve here? There is a better way than trying to read the database, and probably more than one better way. But without knowing what you're trying to do, we can't help you with it. Running off trying to explain how the database…

Could you explain how you are doing this on a Cloud system?

The migration assistant is for migrating to Cloud, and yes, only handles core Jira. I don't know what help you might need with "merge on server", have you looked at the Atlassian docs on merging systems yet?

But you gave us a list of rules, not searches. I asked for what operators you think you are missing. To search for issues that do not have a label, use "labels != <label>"

Comments are also content. This is one of the reasons you probably don't want to be reading the database - it's the most complex and worst way you can try to get data out of Confluence.

Whether you think you need that information or not is irrelevant really. It is not recorded and hence it is not available. I'm not sure what you think "a list of available custom fields" would be or how it might be useful. By definition, a custom field is a field that you choose to add as a customisation. A list of…

Yes, you should be worried. Atlassian take regular and frequent backups of all Cloud systems, but these are only suitable for restoring a whole set of systems in case of a complete failure. They are not suitable for restoring (parts of) a system if someone deletes or reconfigures something destructively. You should look at…

Those are not search operators, they are usage rules. Most of which you can already form searches for when you're looking for enforcement. Additionally, most of the usage you've listed there is not what labels are for. You should be using the workflow and system fields for most of what you've defined. I'd suggest revising…

You'll need to read up on Cloud merges, not migration. These are several orders of magnitude harder. You either need a complicated "download Cloud, merge on server, re-upload to Cloud" process, or you will need to accept potentially massive data loss. Start by having a think about what you want to merge in - what loss of…

Yes, that picture shows a list of the fields from the issue that you can add to the request. I don't see anything here that you cannot tick to include in the request screen.

There's a whole other conversation to be had about how "using labels to prioritise" is a really terrible idea, especially as Jira deliberately has many better ways to do it. But I am commenting to question how you think "recognising various operators" would work? What operators do you think you need and why?

Confluence has up to four urls for a page. * If your page name is plain text without punctuation, then you can find it under <base url>/display/<space/<page name>. If you rename a page, this url will change * A page has a unique id, which you will see in the url when you edit the page, or give it a name that cannot be a…

Add you as a technical or billing contact.

The date that a custom field is entered is not recorded, as it's not useful information (you only really care when data is entered into it) The "details" of custom fields can be seen (and edited) on Admin -> Issues -> Custom fields.

No, you need to be thinking about the links you enter, not just linking everything automatically.

I would look to Draw.io and Smartdraw.

The account that bought the 100 user licence will need to add your account as a technical or billing administrative account to the site.

Yes, you can have different fields by request type, and you can define which fields the customer has access to as a sub-set of what the agent can use.

As the documentation for cloud migration says: Upgrade your Jira Server to the latest version, export it and then import it into an empty Cloud site. This will overwrite your "relevant configurations" of course. See https://confluence.atlassian.com/cloud/jira-server-to-cloud-migration-resources-972330179.html

No. The hierarchy in Jira Software is Epic, Issue and sub-task. You will need apps if you want to allow more complexity. Be warned that if you do add more complexity below Epic, most people will get confused by it and you usually end up in a complete mess.

Yes, it is supported. But if you write code for it, that will not be supported by anyone other than you. Why do you ask?

Correct, The "sneaky tricks" file as I call it is not editable by end-users on Cloud. I'm not sure Cloud reads it any more, and that particular flag probably wouldn't be even coded for on Next-gen projects or the latest "new issue view".

For Jira to consider an issue resolved, it needs a resolution to be set. It will record when this is done in the "resolution date" field. It sounds like your workflow is not enabling the selection of a resolution for the user (or using a post-function to set it)

Have another look at the docs, they've been clear on it for most of the years passed since this question was asked.

It depends on how your Jira system is set up to handle users. Some of them will be set up to let you create your own account. There will be a "sign up" link on the log in screen which will ask you for some basic info and create an account. You will probably then need to contact the administrators to get added to the…

Not for most screens - if a field is on a create, edit or transition screen, it is there to enable it to be entered or changed. On the view screens though, yes, you can make a field read-only, such that inline edit won't work - remove the field from the "edit" screen and it will disallow all editing of the field, while…

See https://community.atlassian.com/t5/Bitbucket-questions/Bitbucket-service-stops-often-in-linux-server/qaq-p/1492158 - there is more information and the next steps you need to take there already.