-
Bug
-
Resolution: Unresolved
-
Highest
-
113
-
Severity 3 - Minor
-
Summary
The "Last Active" date may not consistently align with the actual last instance a user was active in a specific application, such as Jira or Confluence.
This inconsistency in the "Last Active" date can be more accurately identified by customers who possess Enterprise licensed applications. They have access to application events in the Audit log, allowing them to observe if a user has viewed a Jira issue, made edits, or interacted with a different section of the application.
The inconsistencies in the 'Last Active' dates are not confined to mere hours. They can, in fact, be inaccurate for an extended period, even beyond weeks.
Environment
Cloud, New centric User Management experience.
Create an environment comprised of:
- Jira Work Management
- Jira Service Management
- Jira Software
Grant some of your users access to either JWM, Software, or JSM
Steps to Reproduce
Can be more easily reproduced using the following constraints:
| User A | JWM access only |
- User A logs into JWM and creates a ticket.
- This action gets logged and "Last Active" updates.
- User A logs after a couple days back in Jira to view a JSW Jira ticket.
- User A has the permissions to view the ticket.
- User A open the ticket and view it for more than 2 seconds
- This activity gets recorded in the Audit Log of Atlassian Access for Enterprise licenses
Expected Results
Last Active date should be updated to show the last activity of the user in Jira, which was when the user browsed the JSW project Jira ticket.
Actual Results
Last Active date is not updated with the last time the user viewed the JSW Jira ticket.
Workaround
There is no workaround besides having the users create tickets or perform other actions in different Jira project types.
Additional notes
This bug also affects the retrieval of these values through the API, which directly impacts the ability of certain customers to automate their user lifecycles.
- follows
-
-
- Long Term Backlog
-
-
ACCESS-1291 Include 'Last Active Date' as a field in REST API endpoint /rest/api/2/user
- In Progress
-
- Gathering Interest
- is cloned from
-
-
- Closed
-
- split to
-
-
- Long Term Backlog
-
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
-
-
- relates to
-
[ACCESS-1783] Last Active inform inaccurate time in Users Page
Hi everyone,
We are actively working on improving the way we show 'Last active' dates in Admin Hub (admin.atlassian.com).
Our investigations found there is no inaccuracy with the data source of the ‘Last active’ dates on the Users page or in Audit logs.
However, as ‘Last active’ on the Users page vs ‘Last active’ in Audit logs are driven by different data sources, they have different definitions based on their events.
Definition of ‘Last active' for the Users page from: User's last active dates
- Returns user’s last active date for each product listed in Atlassian Administration.
- Active is defined as viewing a product's page for a minimum of 2 seconds.
- The data for the last activity may be delayed by up to 24 hours.
- If the user has not accessed a product, the product_access response field will be empty.
Activity events captured by audit log: Track organization activities from the audit log
So while both the ‘Last active’ date on the Users page and in Audit logs are accurate based on their individual definitions and data sources, I acknowledge the inconsistency between these pages and the confusion it may cause.
Our engineering team is working on a long-term solution to reconcile the data sources between these pages. In the interim, we have updated our public-facing documentation to clarify the differences in definitions.
Thanks a lot for your feedback, I really appreciate your patience while we make these improvements.
Cheers,
Michelle
Product Manager, Atlassian Guard Standard
All comments
Hi everyone,
We are actively working on improving the way we show 'Last active' dates in Admin Hub (admin.atlassian.com).
Our investigations found there is no inaccuracy with the data source of the ‘Last active’ dates on the Users page or in Audit logs.
However, as ‘Last active’ on the Users page vs ‘Last active’ in Audit logs are driven by different data sources, they have different definitions based on their events.
Definition of ‘Last active' for the Users page from: User's last active dates
- Returns user’s last active date for each product listed in Atlassian Administration.
- Active is defined as viewing a product's page for a minimum of 2 seconds.
- The data for the last activity may be delayed by up to 24 hours.
- If the user has not accessed a product, the product_access response field will be empty.
Activity events captured by audit log: Track organization activities from the audit log
So while both the ‘Last active’ date on the Users page and in Audit logs are accurate based on their individual definitions and data sources, I acknowledge the inconsistency between these pages and the confusion it may cause.
Our engineering team is working on a long-term solution to reconcile the data sources between these pages. In the interim, we have updated our public-facing documentation to clarify the differences in definitions.
Thanks a lot for your feedback, I really appreciate your patience while we make these improvements.
Cheers,
Michelle
Product Manager, Atlassian Guard Standard
With no workaround available, we would greatly appreciate this bug being prioritized for development.
As customers, we should be able to have accurate data to use when assessing whether paid subscription(s) are still needed.
Hi Team, I am running into this issue also, and created a service request and added some logging data of specific users that got reset in a recent, small timeframe. Please check JST-994452 for details. If you want a look at the data itself, i can reopen and grant that access.
Hi Team, can you please help to prioritize this defect as we are planning to use this field for managing the user license management based on the last active date using users admin API
HI Team,
When can we expect this issue to be resolved? It has been nearly a year, and it remains unassigned. This feature is essential for our license management.
Thanks,
Mirkeya