Blog

Phone cameras record which way up a photo was taken in an EXIF orientation tag rather than physically rotating the pixels, so a picture that looks upright on the phone can land sideways once it is uploaded to a Confluence page. Rotating it by hand in an external editor and re-uploading works, but it re-compresses the JPEG and throws away the original metadata. CelesteCS Image Lossless Rotator fixes this directly on the Confluence page instead.

The one-click fix

Open the page for editing, click the sideways image to bring up its property panel, and choose Rotate according to image orientation. The plugin reads the EXIF Orientation tag written by the camera and rotates the image to match – no need to know in advance whether it was 90, 180 or 270 degrees off.

Why it stays lossless

Ordinary JPEG rotation has to decode the image to pixels and re-encode it, which degrades quality a little every time. CelesteCS Image Lossless Rotator instead rotates the compressed 8x8-to-16x16-pixel blocks that make up a JPEG file directly, so the image data itself is never re-compressed. See Lossless Rotation for the technical explanation of why this works for JPEG but not for every format equally.

Keeping the metadata a photographer actually cares about

Rotating an image normally leaves its EXIF, IPTC and XMP metadata behind, but CelesteCS Image Lossless Rotator copies that metadata across to the rotated file and updates the fields that depend on orientation, such as width and height. That means author credit, capture date and GPS location survive the rotation intact – see Copying image metadata for exactly which tags are preserved.

Because the whole operation runs as a REST call on the Confluence server itself, the original image file never has to round-trip to the browser and back, which also makes it practical to fix a whole page of misrotated photos in a couple of clicks rather than one download-edit-upload cycle per image.

toto togel

Jira lets teams link issues as clones, duplicates or blockers, but finding all of them from the issue navigator usually means clicking through issues one at a time. CelesteCS JQL Extensions adds dedicated functions for exactly these three relationships, plus a way to spot suspicious duplicate data before it turns into a linked duplicate in the first place.

Following a specific relationship

• issue in jqlxClonesOf("key = APP-100") – every issue cloned from APP-100.
• issue in jqlxDuplicatesOf("project = SUP and status = Open") – open duplicates of the matched issues, useful for a weekly support triage.
• issue in jqlxBlockersOf("project = APP and status = \"In Progress\"") – whatever is blocking today’s in-progress work, a natural stand-up query.

Catching duplicate data before someone links it manually

Sometimes the same request comes in twice under different summaries, with nothing linking them yet. jqlxIssuesWithDuplicateFieldValues flags issues that already share a field value someone would expect to be unique:

• issue in jqlxIssuesWithDuplicateFieldValues("project = SUP and status != Closed", "Customer Reference") – two open tickets referencing the same customer ticket number, a likely duplicate report.

The mirror function, jqlxIssuesWithUniqueFieldValues, is handy for a data-quality sweep in the other direction – for example confirming that every issue in a migration batch really does carry a distinct external ID before the import is trusted.

All of these accept the same jqlQuery-first pattern as the rest of the plugin, so they combine freely with ordinary JQL clauses and with the other jqlx-prefixed functions functions described in the Functions reference.

situs toto

kampungbet

A common reporting request is a single table that lists an Epic together with all of its Stories, rather than two separate lists that have to be cross-referenced by hand. JQL alone cannot express “this issue, plus everything linked to it” – but the jqlxFlattenedTwoLevelTree function from CelesteCS JQL Extensions does exactly that.

The query

• issue in jqlxFlattenedTwoLevelTree("project = APP and type = Epic and status != Done")

This returns every open Epic in the project and every issue directly linked to those Epics (their Stories, in a typical Jira setup), combined into one flat list with no duplicates – even though the JQL query itself only asked for Epics.

Narrowing it to a specific link type

If the instance has several link types and only the Epic-Story relationship should be flattened, pass it explicitly:

• issue in jqlxFlattenedTwoLevelTree("project = APP and type = Epic and status != Done", "is Epic of", "Outward")

Turning the flat list into a table

Feed that same JQL query into a CelesteCS Reporting Jira Data Provider macro, and a Reporting Table View underneath it. Inside the Reporting Table Item body, a formula such as IF(CurrentItem.fields.issuetype.name = "Epic", "", REPT(CHAR(160), 4)) & CurrentItem.key indents Stories under their Epic visually, giving a genuinely hierarchical-looking report built from a single flat data source – no separate query per Epic required.

For a deeper look at building multi-level trees with actual parent-item references rather than indentation, see Building a multi-level Jira issue tree with Reporting List View.

kampungbet

Plain JQL can filter issues by field values, but it has no way to ask questions about an issue’s attachments, comments or subtasks as a group – things like “nobody has replied in three weeks” or “every subtask is already done”. CelesteCS JQL Extensions adds a set of jqlx-prefixed functions functions that answer exactly this kind of question, right inside the Jira issue navigator.

Issues nobody has followed up on

• issue in jqlxIssuesWithCommentCountEqualTo("project = SUP and status = \"Waiting for support\"", 0) – support tickets sitting without a single reply.
• issue in jqlxIssuesWithAllCommentsCreatedBefore("project = SUP and status = Open", "-14d") – issues where even the newest comment is over two weeks old.

Subtasks that quietly block a story from closing

• issue in jqlxIssuesWithSubTaskCountGreaterThan("project = APP and type = Story", 0) – stories that actually have subtasks, as a starting point.
• issue in jqlxIssuesWithAllSubTasksCreatedByUser("project = APP and type = Story", "jdoe") – stories whose subtasks were all created by one person, often a sign they were never triaged as a team.

Attachments that are missing or stale

• issue in jqlxIssuesWithAttachmentCountEqualTo("project = SUP and \"Attachment required\" = Yes", 0) – tickets that should have a screenshot or log file but don’t.
• issue in jqlxIssuesWithAnyAttachmentsCreatedBefore("project = SUP and status = Open", "-30d", "log") – open issues carrying a log file older than 30 days, a good candidate list for “please re-attach current logs”.

Every one of these still returns standard Jira issues, so the result can be saved as a filter, dropped into a dashboard gadget, or reused as the jqlQuery parameter of a CelesteCS Reporting Jira Data Provider macro to turn the same logic into a Confluence report. The full function reference, with every parameter explained, is in the JQL Extensions Functions documentation.