19 April 2015 to 25 April 2015
Let us know on our blog posts.
User deactivation is now here!
As part of our ongoing work to improve the site administration experience, this release will include a new Deactivate button. Site admins (users who have access to the User administration screens) can now deactivate a specific user. Deactivation means that:
- All the users' data remains in your site; the user's comments or changes are still around so you'll always know what the user did
- The user won't be able to log in anymore, and he/she won't count against your license
- You can reactivate the user later if want to
New Google Drive macros plus changes to existing macros
If you currently use the Google macros (for documents, presentations and spreadsheets), there are some changes you need to be aware of.
On April 20, Google will shut down APIs that our existing macros rely on to display Google drive files on Confluence pages. Our current Google macros will stop working at this time.
We won't be providing a replacement for the Google Documents List macro, but we have developed three brand new macros to make displaying Google Docs, Sheets and Slides on a page simple.
|Current macro||New macro|
Google Documents List
|No replacement for this macro|
Authentication is handled a little differently too - you no longer need to be using Google Apps authentication for your whole site. Now, the macro will prompt people to authenticate before they can view a Google drive file for the first time. We'll then store an authentication token and not make them authenticate again unless they're using a different computer or device, or the token times out.
Your existing Google macros will continue to work until Google shuts off the API. After that you'll need to manually add the new macros to your pages.
To use the new macros, administrators need to install the free Confluence Google Drive add-on. Read more about the Google Drive macros and how to install the add-on.
One less step to restrict who can edit a page
You no longer need to add someone as an editor and viewer in the restrictions dialog. We'll check if the person has edit permissions, and if they do, we'll let them see the page (it's a bit hard to edit a page you can't see, right?). Any child pages will also be visible, unless there are further view restrictions on the child pages.
This change applies to existing pages too, so any people who previously couldn't see a page because they only had edit permission will now be able to see the page.
Leah creates a page and restricts viewing to herself. Later she wants Josh to review the content, so she restricts editing to Josh and herself.
Here's what it looks like in the restrictions dialog, and to a space admin in the list of restricted pages:
Previously Josh couldn't see the page, because he only had permission to edit, not view. After Confluence is upgraded this week, Josh will be able to view and edit this page, as Leah originally intended.
The way permissions are inherited on pages has not changed:
- If you restrict viewing to a person or group, they'll be able to see that page and all its child pages (unless there are further restrictions on the child pages)
- If you restrict editing to a person or group, they'll be able to see and edit that page, plus see its child pages (just the same as if you applied separate edit and view restrictions).
- If you restrict viewing or editing to a person or group, a parent page (higher up in the page hierarchy) can have its own view restrictions that will prevent them seeing your page.
JIRA Portfolio 1.9.2-OD-01
Visualize your resource usage
We've redesigned the release view in the graphical schedule so that you can quickly see how much capacity you are utilizing, how much you have available and where you are overbooked. View the schedule globally or at the team or member level to see exactly where your resources are being used. See the big picture, including any potential bottlenecks, and adjust your schedule accordingly.
Sprint planning based in the real world
Have a special project or a long term goal that requires a special sprint length? Flexibly configure your teams' sprints to plan accurately and reflect how they work day-to-day in your plan by adding fixed sprints with defined start and end dates. Simply define the dates and assign a team and all of your other sprints will schedule around your fixed sprints. In addition, you can now easily discover and view which teams are working on what in the "sprints" column in the backlog view.
Plan according to your schedule
Configure your plan's schedule to your team's real world schedule. Have a 10 hour work day? A 4 day work week? No problem! You can now define a work week and hours that match how your team works. Have company or team specific time off? Set non-working days that are globally reflected across your plan.
Estimate quickly, where you work
- We've continued to add functionality to more tightly integrate JIRA Portfolio and JIRA. You can now edit estimates in your plan or in your project and then easily sync across both – allowing you to get increased visibility across your roadmap.
- Do you want to quickly plan, but have a bunch of unestimated stories and epics? Well now you can set a default estimate that is used for any unestimated stories and epics in the backlog.
JIRA Drag and Drop Attachment Plugin 3.3.1
We've updated the bundled JIRA Drag and Drop Plugin, which now allows you to drag and drop files directly on to an issue (as long as attachments are configured for your issues). We've also updated the way you can view attachments on an issue, you can now select to view them as thumbnails or as a list on the Attachments drop-down list.
This is a bug-fix release of JIRA. There are no feature updates.
Was this helpful?
Thanks for your feedback!