What Jira permissions are required in order to configure calendar sources?

to be able to create and configure the event sources in a calendar configuration, a user should be granted the calendar permission Calendar editing first. When it comes to Jira permission requirements, a user may require certain Jira permissions depending on what he or she is trying to achieve.

For instance, three users Oksana, Yuriy and Raymond are granted the Calendar visibility and Events editing calendar permissions but only Oksana and Raymond are granted the calendar permission Calendar editing. As a result, Oksana and Raymond will be able to create new event sources for the calendar but Yuriy will not have such ability as he is missing the required permission Calendar editing.

Open

Let’s say, Oksana wants to create an event source for the project GRAND. She will be able to do so only in case she is granted the required project permission View projects (new project permission that is a part of deprecated project permission Browse projects).

Open

Another example when a user could experience some limitations during an event source creation is, let’s say, Raymond wants to create and configure a Jira dates source based on a DEMO board filter. Raymond is granted the project (DEMO) permission View projects, and DEMO board filter is shared with the project DEMO. As a result, he is able to create a Jira dates event source based on DEMO board filter.

Another example, a user created a private Jira filter and shared it with user Oksana only. As a result, only Oksana and private filter owner will be able to create a Jira dates event source based on the private filter.

Also, there is one more example that could be found useful. Let’s say Raymond wants to add Assets fields to the event source configuration. He’ll be able to do so only in case the Assets integration is enabled by an admin in the app configuration first (cloud version) or Assets is integrated in Jira (server/DC version). Then, the Object schemas shall be shared with his user.

To sum-up:

In most cases, a user may require the project permission View projects in order to be able to create and configure an event source, in calendar configuration. In certain cases, a user may also require an access to a filter or Assets object schema.

How to differentiate my worklogs based on a project?

The simple way to do it is to create multiple worklog sources for different projects and define a different color for each worklog source. Please refer to the page to find out more about worklog source configuration.

Should you prefer to have just one worklog source and worklog entries to be in different colors depending on a certain condition, you can create and apply the conditional colors.

The conditional colors can be created and saved, in a source configuration.

In case you want the worklog events to differ in color based on a project, you would have to edit the worklog source configuration and add the conditional colors based on the filed “Project“.

Please take a look below:

We miss the old feature "Spent Vs Planned" report. How do we recreate it in the new app version?

To generate a report "Spent Vs Planned", first, please make sure that your calendar contains the required sources: Worklogs and Planning. Please refer to the Event Sources Tab of your calendar to verify this. Second, in Reports mode, configure the fields for reporting as Day and Event Source.

Then, add the fields Day and Event Source to the field sorting and tick the checkboxes “Group by“ next to them, as shown below:

Finally, generate a report. Your report might look similar to the one below:

We would like to generate a report for former users

For those who use cloud Jira this can be done the next way:

• as admin, create a special group for inactive users

• add inactive users to the group

• create a worklog source configured for the group of inactive users

• generate a report based on the source

For server Jira users, it is recommended to make users inactive rather than remove them from Jira in order to save their connection to the worklogs. In such a case, the worklog history is saved and the reports can be easily generated.

In case a user is removed from Jira, his or her worklog history is lost. In order to see the worklogs that belong to removed users you would have to create a worklog source with the configuration: Jira filter “All issues“ and user option “All“. As result, all worklogs will be shown for former users. Please see below:

In my report, I want to see the total work logged for the parent task and its sub-tasks

We’ve prepared a special field for that, aggregated Parent (“Σ Parent“). Please see below:

In my report, I want to see the total work logged for the epic task and its tasks

We’ve prepared a special field for that too, aggregated Epic (“Σ Epic“). Please see below:

In my report, I want to see the epic name in case there is an epic link for a task

Please use the field aggregated Epic Name (“Σ Epic Name“) as shown below:

The generated report is not being downloaded

One of the reasons why the generated report is not being downloaded is that multiple downloads are blocked. Please check your browser if this is the case.

Manage multiple downloads if needed.

The report is being generated in days and I prefer it to be generated in hours

You can change the time units for reports, by clicking next to Total, on the left panel:

I want to see the planning events created by others

In order to see the planning made by others, you may either

1. create a Planning calendar

2. in your calendar, that contains a planning source, grant the visibility and event editing permissions to other users

When using the first option, the planning calendar can be created as a public calendar so each user has access to it. The planning source shall be added to it. Thus, each user will be able to create a planning event based on the source.

In addition, should you prefer to work only with your calendar, without accessing the Planning calendar, you can add iCalendar source to your own calendar. Prior to it, you would have to create the export for the Planning calendar. Then, in your calendar configuration, add iCalendar source, using the generated URL for the Planning calendar export.

Once the iCalendar source is added to your calendar configuration, you will see the planning events made in Planning calendar, in your own calendar. If needed you’ll be able to create worklogs based on imported events.

When using the second option, other users who are granted the visibility and event editing permissions shall be able to access your calendar and create events there.

In such case, you may want to create Team planning source, in your calendar configuration. Then, grant the required permissions to other users, assuming your calendar is not public. As result, the users who are granted the visibility and event editing permissions shall be able to create and edit planning events.

I want to see Logged vs Planned for each day

In order to see logged time versus planned time in daily total hours, you would have to do next:

1. Next to Total, on the left panel, tick the checkbox “Detailed“, as shown below

2. Make sure the first two enabled sources, on the left panel, are the sources you would like to compare in your daily detailed time

The sources to be compared don’t have to be the very first two sources in the list, on the left panel. They have to be the first two enabled. Please see another example below.

Why the calendars look differently if the app is opened in a project context view comparing to the way it looks when the app is opened from Jira top menu?

The calendar availability and calendar content may differ, depending what Jira area you opened the app, project context view or Jira top menu. This is the expected behavior, and is explained by the way the calendar sources are configured. In more details below:

• In case a calendar source is configured with the Project option “All projects“ the calendar, along with the events that are based on the source with the option “All projects” will be shown in a project context view of any project.

• In case a calendar source is configured for a specific project. For instance, project DEMO, the calendar, along with the events that are based on the DEMO source will be shown in a project context view of DEMO project only.

• In case a calendar source is configured with the Project option “No projects“ the calendar, along with the events that are based on the source with the option “No projects” will not be shown in a project context view at all.

The conditional color that includes the function “endOfWeek()“ is not working properly

You might experience the next issue when the configured conditional color that includes the function “endOfWeek()“ is not working correctly.

For instance, as an app user, in User settings, I’ve configured my week to start on Monday:

Then, in source configuration, I’ve configured the conditional color: Due date <= endOfWeek() → red.

Although, the configured conditional color is not applied to the event that is based on issue that has a due date that falls on Sunday of the current week.

The root cause of the issue is laying in Jira’s behavior as, in Jira, week starts on Sunday.

What is the difference between Issue fields, Event fields, Report fields and Aggregated fields?

Issue fields- are the attributes of Jira issues. These are the standard and custom Jira fields. Examples: assignee, reporter, priority, due date, etc. The issue fields are used in source configuration, including conditional colors, and report field configuration.

Event fields- are the attributes of custom events such as Meetings, for instance. Examples: event user(s), event reporter, event summary, event description, etc. The event fields are used in source configuration, including conditional colors, and report field configuration.

Report fields- are the fields that can be added to report field configuration. They include issue fields and event fields. In addition, there are unique report fields that can be used specifically in reports such as event source, day, week, and month.

Aggregated fields- are the fields that have been created specifically for the application to aggregate the value for two different event types, Jira dates and custom. Examples: Σ Summary, Σ Description, Σ Reporter. Such fields can be used in reports but not in source configuration.

In addition, there are aggregated field for parent, epic and time tracking fields such as Σ Parent, Σ Epic, Σ Epic Name, Σ Original Estimate, Σ Remaining Estimate and Σ Time Spent.

Such fields can be used in reports and in source configuration.