We explain the difference on the following documentation page: Free vs Paid subscription

It should be enough to just install Issue Checklist Pro and start the trial.

Atlassian is responsible for handling subscriptions and payments (vendors only set per-user price).

Payment should be handled automatically when the trial ends, i.e. 30-60 days after Issue Checklist Pro was installed and the trial started.
If the payment is not handled and the license not issued, then please contact Atlassian Support at https://support.atlassian.com/contact/#/

Atlassian is responsible for counting a number of users. It usually equals the number of users registered in your Jira (excluding Service Desk customers). 

In order to check the exact price, please:

• Go to Jira settings > Apps > Find new apps page
• Search for "Issue Checklist Pro"
• Click the "Issue Checklist Pro" on the search result list
• Find the price as presented on the screenshot below:
  
  

There are no limits at all. 

You can add as many items and templates and as often as you want 

The main checklist view, as presented on the screenshot below, disappears (the view is rendered by Issue Checklist app, so once the app is removed, the view is no longer there):

When the Issue Checklist is uninstalled, the data is still available in custom fields (if "Save checklist data to Jira custom fields" option was enabled when the app was in use). It means that if you add the Text or YAML custom field to the View Issue screen in Jira, you can still see the checklist like this:

The data also stays in Issue Checklist external database for 90 days (as explained in Privacy Policy). After 90 days the data is permanently deleted. If you re-install the app before 90 days since uninstallation, you can still access the data and use Issue Checklist as usual. 

No.

Issue Checklist and all other add-ons for Jira Cloud (as opposed to Jira Server plugins) are loaded in separate iframes inside the Jira page. This approach ensures security (iframe code cannot access the main page) but also lets the browser load the content of the add-on asynchronously without blocking the main page.

Technically, iframe content loads asynchronously but it can block the "onLoad" event of the main page. There are existing solutions to avoid blocking the "onLoad" event of the main page though.

This way, Jira Issue View and other pages are fully responsive even if Cloud add-on is not ready yet (e.g still loading or trying to render UI).

Following resources explain technical details of loading the iframe content in a browser: 

• http://www.lognormal.com/blog/2012/12/12/the-script-loader-pattern/
• http://www.aaronpeters.nl/blog/iframe-loading-techniques-performance

Overall, Cloud add-ons (including Issue Checklist) do not block loading Jira pages. 

When Cloud add-on is slow for some reason, users can observe one of the two symptoms:

• add-on panel/iframe shows typical "loading spinner" (when getting data from the server is slow because of poor connection or server performance issues)
• add-on panel/iframe is empty (if rendering UI is slow).

None of the above blocks Jira page rendering. Jira page is loaded independently and should be responsive as soon as it is ready, despite app server performance.

It is worth to note, that a lot of poorly performing JavaScript code loaded into a browser page might decrease the page performance and responsiveness. It relates to both Jira, Jira apps and any other web page. For this reason, Atlassian is switching Jira Cloud  client-side codebase to React which is one of the most popular and best performing Java Script frameworks. Issue Checklist is written in React too and re-uses several components of the Atlassian UI components to provide the best client-side performance and user experience possible. 

Overall, Issue Checklist and other Cloud apps cannot slow down Jira itself, but poorly written apps can slow down the browser and decrease web page responsiveness. 

Privacy Policy: https://herocoders.com/privacy-policy/

Security Statement: https://herocoders.com/security/

Terms of Use: https://herocoders.com/eula/

Yes, we do support Jira URL change. No actions are necessary on the Issue Checklist side. All data is available automatically after the rename. 

"Administer the host application" is related to custom fields integration. Issue Checklist uses it to:

• Write data to custom fields even if the fields are not on the "Edit Issue" screen.
  This way Issue Checklist can integrate with custom fields seamlessly and provide reach set of functionality without users required to manually add the custom fields to the screen (which is both burdensome and redundant).

• Update custom fields without sending notification email about issue update (so you don't get a notification every time someone ticks the checklist item).

When "Save checklist data to Jira custom fields" option is disabled, then "Administer the host application" permission is not used. 

Please note that both "Administer Confluence spaces" as well as "Delete data from the host application" are added by Marketplace automatically if "Administer the host application" is requested. Issue Checklist does not request those permissions, do not access Confluence and do not delete any Jira or Confluence data. 

The permissions requested by Issue Checklist plugins are visible in the "Scopes" section under the following URLs:

• Issue Checklist Pro ["READ", "WRITE", "PROJECT_ADMIN", "ADMIN"]
• Issue Checklist Free ["READ", "WRITE", "PROJECT_ADMIN", "ADMIN", "ACT_AS_USER"] - we do not use "ACT_AS_USER" permission

The checklist data is stored both in Jira (custom fields and entity properties) and on our servers.

Safety

We care about the safety of your data:

• We encrypt the data in transit but also at rest when stored on our servers 
• We do backup data every day
• The main database has 1 primary node and 2 backup nodes to minimize the risk of an outage
• We use trusted DB provider, i.e. MongoDB.com 
• Only authorized personnel can access the data
• All our systems are protected with two-factor authentication.

Read more in our Security Statement

Why we store data on our servers

The reason why we store checklist data on our servers is both security and flexibility:

• storing checklist items in Jira custom field means that:
  • data is limited to 32kb per issue
  • removing the custom field removes all checklist items from all projects (that is extremely risky)
• storing checklist items in Jira issue entity properties means that:
  • data is limited to 32kb per issue
  • no custom permission can be implemented (every user who can see Jira issue could also see checklist items; every user who can edit Jira issue could also edit/delete checklist items)

We avoid the above limitations by storing data on our servers. This way you can store as many checklist items as you need and use custom permissions to control who can view, add, edit, toggle or delete the checklist items.

Jira storage (custom fields)

Checklist data is also stored in Jira custom fields as long "Save checklist data to Jira custom fields" option is enabled in Global Settings. It means that:

• Every checklist action you take updates also Jira issue by saving new value to custom fields. It adds an entry to the Jira issue history and notification area.
• Checklist data is stored in Jira so your Jira backup contains checklist data too. This way you can keep your backup safe according to your company policy.
• You can read and modify the checklist through API by reading and modifying the text stored in custom fields. 
• Checklist fits into custom fields only up to 32kb 

If you don't accept any of the above, please disable "Save checklist data to Jira custom fields" option in Global Settings. In that case, checklist items will be stored only on our servers. 

Jira storage (entity properties)

Checklist meta-data is stored also in Jira entity properties. These include information if all items are completed, how many items are in the checklist, etc. 

We also store raw checklist items text in entity properties to enable JQL search of the checklist items text (as long as custom View Checklist permission is not enabled). 

Personal data

Issue Checklist does not read, transfer, or store any Personal Information outside Jira (that includes user names and email addresses) by default. Only cryptic user account ID is stored when you use the mention feature or when checklist history is tracked. The account ID is next changed to the real user name in your browser, so:

1. HeroCoders does not access/see real user names. 

2. Jira decides if you can see the real user name (according to the permissions granted to you in Jira project permissions settings)

However, if the “Send email on mention” option is enabled in Issue Checklist settings, we read (but do not store) your email every time someone mentions you in the checklist item.

Sensitive data

Issue Checklist and HeroCoders do not have access to any sensitive information like credit cards, passwords, etc.

Atlassian is responsible for payments, charges, authorization, resolving permissions, etc.

Other data

Issue Checklist does not store any other kind of data on our servers but only what you enter into the Issue Checklist input fields. Specifically, we do not store or transfer any sensitive or PII information. We also do not read or transfer any data from your issues or Jira like summary, description, etc. 

Data entered into the Issue Checklist UI as items or templates can be easily and instantly removed by using the UI "delete" links and buttons.

Non-app data

HeroCoders authorized staff has access to the email and name of the Issue Checklist Pro license owner (through Atlassian Marketplace). Every paid app gets it. It is usually a person who owns the Jira instance.

Find out more in our Privacy Policy (including physical data location).