[Due for payment 2026-07-21] [$125] [Device Management] Sort devices list by most recent timestamp first

[melvin-bot]

Problem

The devices list on the Device Management screen is not sorted. It should display the most recently used/added device first (descending by timestamp).

Expected Result

Devices are sorted with the most recent timestamp at the top of the list.

Actual Result

Devices appear in an unsorted order, making it hard for users to identify their most recently active sessions.

Context

Raised during the Migrate Onyx loginList to logins rollout. Related tracking issue: Device Management.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022073121152255669776
• Upwork Job ID: 2073121152255669776
• Last Price Increase: 2026-07-03

Issue Owner

Current Issue Owner: @cretadn22

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The device list on the Device Management screen renders in an unsorted order. It should show the most recently used/added device first (descending by timestamp).

What is the root cause of that problem?

getDeviceLogins returns the logins straight from Object.values(...) with no sort — so the order reflects the object's key order, not each device's timestamp:

Code references

• The selector that feeds the list — filters but never sorts: src/libs/UserUtils.ts:100-102

  function getDeviceLogins(logins: OnyxEntry<Logins>) {
      return Object.values(logins ?? {})?.filter(isDeviceLogin);
  }

• The page renders that array directly in FlashList (data={logins}), preserving the unsorted order: src/pages/settings/Security/DeviceManagementPage.tsx:77-84
• The timestamp we want to sort by is already computed for display via getLastLogin, which returns the later of lastLogin/created: src/libs/UserUtils.ts:57-60

What changes do you think we should make in order to solve the problem?

Sort the filtered logins descending by getLastLogin inside the getDeviceLogins selector, so every consumer (and the list) gets a consistent most-recent-first order. getLastLogin returns ISO date strings, which sort lexicographically, so localeCompare gives the correct order:

function getDeviceLogins(logins: OnyxEntry<Logins>) {
    return Object.values(logins ?? {})
        ?.filter(isDeviceLogin)
        .sort((a, b) => getLastLogin(b).localeCompare(getLastLogin(a)));
}

Doing it in the selector (rather than in the page's renderItem) keeps the sort out of the render path and reuses the exact timestamp already shown in each row.

What alternative solutions did you explore?

Sorting in the component (e.g., a memoized useMemo over logins before passing to FlashList) would also work, but centralizing it in the selector is simpler and avoids re-sorting on every render.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95307) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[ahmdshrif]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The devices list on Settings > Security > Device Management renders in an arbitrary order. It should be sorted descending by each device's most recent activity, so the most recently used/added device is at the top.

What is the root cause of that problem?

The structural cause: no ordering is defined anywhere in the data path — the list renders the raw enumeration order of the Onyx logins record, which is keyed storage order, not time order. Chain:

1. The page subscribes to the raw logins record with a filter-only selector: useOnyx(ONYXKEYS.LOGINS, {selector: getDeviceLogins}) —

   App/src/pages/settings/Security/DeviceManagementPage.tsx

   Line 35 in b2e9881

   const [logins] = useOnyx(ONYXKEYS.LOGINS, {selector: getDeviceLogins});

2. getDeviceLogins is just Object.values(logins ?? {}).filter(isDeviceLogin) — filter, no sort —

   App/src/libs/UserUtils.ts

   Lines 100 to 102 in b2e9881

   	function getDeviceLogins(logins: OnyxEntry<Logins>) {
   	return Object.values(logins ?? {})?.filter(isDeviceLogin);
   	}

3. logins is a Record<string, Login> keyed by partnerID_partnerUserID —

   App/src/types/onyx/Logins.ts

   Line 59 in b2e9881

   type Logins = Record<string, Login>;

   — so Object.values yields object-key insertion order, which has no relationship to lastLogin/created. Even if the server sent devices sorted, Onyx MERGE updates individual keys in place (e.g. revokeDevice's optimistic merge —

   App/src/libs/actions/User.ts

   Lines 103 to 118 in b2e9881

   	function revokeDevice(login: NewLogin, autoGeneratedLogin: string | undefined) {
   	if (!autoGeneratedLogin) {
   	return;
   	}
   	const loginKey = getLoginKey(login);
   	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.LOGINS>> = [
   	{
   	onyxMethod: Onyx.METHOD.MERGE,
   	key: ONYXKEYS.LOGINS,
   	value: {
   	[loginKey]: {
   	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
   	},
   	},
   	},

   ), so key order goes stale after any subsequent login anyway. Ordering must be computed client-side.
4. The FlashList renders that array as-is: data={logins} —

   App/src/pages/settings/Security/DeviceManagementPage.tsx

   Lines 77 to 84 in b2e9881

   	<FlashList
   	data={logins}
   	renderItem={renderItem}
   	keyExtractor={getLoginKey}
   	maintainVisibleContentPosition={{disabled: true}}
   	contentContainerStyle={[styles.ph5]}
   	ListHeaderComponent={listHeader}
   	/>

Git archaeology: the feature was introduced by PR #87948 ("Add device management feature") with no sort from day one — this is a missing case in the new logins-key rollout (tracking issue #81346), not a regression of intentional behavior.

Affected paths (all of them): getDeviceLogins has exactly one consumer, the selector at DeviceManagementPage.tsx#L35. The page is a single shared file (no index.native.tsx split, same component in narrow/wide layouts). The sibling hasDeviceManagementError (UserUtils.ts#L104-L106) is order-independent. So one fix point covers every surface, and the symptom — "devices appear in an unsorted order" — is fully explained by key-order enumeration.

What changes do you think we should make in order to solve the problem?

Sort at the single convergence point, inside getDeviceLogins, descending by getLastLogin — deliberately the same value each row already displays (datetimeToRelative(getLastLogin(item)) —

App/src/pages/settings/Security/DeviceManagementPage.tsx

Line 55 in b2e9881

<Text style={[styles.textLabelSupporting]}>{datetimeToRelative(getLastLogin(item))}</Text>

):

function getDeviceLogins(logins: OnyxEntry<Logins>) {
    return Object.values(logins ?? {})
        .filter(isDeviceLogin)
        .sort((a, b) => getLastLogin(b).localeCompare(getLastLogin(a)) || getLoginKey(a).localeCompare(getLoginKey(b)));
}

getLastLogin (

App/src/libs/UserUtils.ts

Lines 57 to 60 in b2e9881

	function getLastLogin(login: NewLogin) {
	// If we have not re-authenticated, then lastLogin will still be the default 2008-01-01 value. So the created time stamp will be more accurate in that case.
	return login.lastLogin > login.created ? login.lastLogin : login.created;
	}

) already encodes the correct semantic — it falls back to created when lastLogin still holds the backend default. Timestamps are YYYY-MM-DD HH:mm:ss strings, safely compared lexicographically (line 59 already string-compares them today). The getLoginKey tie-break keeps order deterministic for equal timestamps. The sort runs only when the LOGINS Onyx key changes (selector re-evaluation, not per render) over a handful of items — effectively zero runtime cost. I'd add a getDeviceLogins ordering case to tests/unit/UserUtilsTest.ts.

Regression safety in one sentence: only array order changes — the selector's sole consumer is this page, keyExtractor/revoke/offline-pending flows are order-independent, and .sort() mutates only the fresh array .filter() just returned.

Why the obvious one-line fix does NOT work: sorting by raw login.lastLogin fails on a documented data quirk — devices that have not re-authenticated keep the backend default lastLogin of 2008-01-01 (the comment at UserUtils.ts#L58 exists precisely for this), so a device added today would sink to the bottom, breaking the exact "most recently added first" requirement in the issue. Likewise sorting by additionalData.timestamp (device-info collection time) can disagree with the relative time each row renders from getLastLogin, producing a list that still looks unsorted next to its own labels. The sort key must be exactly the displayed value.

What alternative solutions did you explore? (Optional)

1. Sort in the component (useMemo in DeviceManagementPage): works, but re-sorts on renders unrelated to data changes and leaves getDeviceLogins returning misordered data for any future consumer; the selector is the cheaper, central location.
2. Sort by raw lastLogin: incomplete — mis-sorts never-re-authenticated devices to the bottom (2008-01-01 default), as above.
3. Have the backend return sorted devices: not viable client-side — logins is a keyed record and Onyx MERGE updates keys in place, so any server-side order is lost after the next login; the App must sort where it reads.

[shivang-goliyan]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-03 19:10:39 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

On the Device Management screen (Settings > Security), the list of devices shows up in an arbitrary order instead of most-recent-first. A user scanning for their latest active session has no reliable way to spot it, since the newest device can appear anywhere in the list.

What is the root cause of that problem?

The Onyx selector that feeds the list never sorts. In src/libs/UserUtils.ts, getDeviceLogins (lines 100-102) does:

return Object.values(logins ?? {})?.filter(isDeviceLogin);

Object.values returns entries in the record's key order, which is partnerID_partnerUserID and driven by the backend/insertion order, not by time. DeviceManagementPage.tsx (line 35) reads this selector and passes the result straight to FlashList as data={logins} (line 78) with no useMemo or sort in between, so whatever order the selector hands back is what renders. There's no timestamp ordering anywhere in the chain, which is why the list looks random. This has been the behavior since the feature first shipped in 1442281d3d8 (the helper was later renamed from getRevokableLogins to getDeviceLogins in c7ae4fa4371), so it's an original flaw, not a regression.

What changes do you think we should make in order to solve the problem?

Sort inside getDeviceLogins rather than in the render. It has exactly one caller (the page's useOnyx selector), so the fix is centralized and can't affect anything else, and Object.values already returns a fresh array so an in-place .sort() mutates nothing shared:

return Object.values(logins ?? {})
    .filter(isDeviceLogin)
    .sort((a, b) => getLastLogin(b).localeCompare(getLastLogin(a)));

The key detail is sorting by getLastLogin (UserUtils.ts:57), the same value the row displays via datetimeToRelative(getLastLogin(item)). getLastLogin returns max(lastLogin, created) because an un-reauthenticated device keeps the default 2008-01-01 lastLogin, so the created fallback is the accurate time. Sorting on raw lastLogin instead would wrongly sink any device that hasn't re-authenticated to the bottom even when it was just added. The timestamps are ISO/SQL strings ('2025-01-01', '2023-09-12 16:27:35.124'), so localeCompare gives correct chronological order, descending for newest-first.

I'd also add a getDeviceLogins unit test in tests/unit/UserUtilsTest.ts (it currently has none for this helper): feed a Logins record with scrambled keys and distinct lastLogin/created values, assert most-recent-first, and cover the lastLogin === 2008-default case so the created tiebreak is locked in.

What alternative solutions did you explore? (Optional)

Sorting in the component (a useMemo around logins before passing it to FlashList) works but spreads the concern into the render and only fixes this one screen; the selector is the single source and the natural place to guarantee order. I also considered leaving it to the backend to return sorted data, but Object.values ordering is never guaranteed regardless of what the server sends, the client already has the timestamps, and this is a client-side display concern, so the client should own the sort.

[lorretheboy]

All the pieces are found: getDeviceLogins filters Object.values() without sorting, and getLastLogin already computes the relevant timestamp. Here is the proposal.

Proposal

What is the root cause of that problem?

The Device Management page reads its list through the getDeviceLogins selector, which just does Object.values() on the logins Onyx object and filters for device logins — it never sorts:

App/src/libs/UserUtils.ts

Lines 100 to 102 in b2e9881

	function getDeviceLogins(logins: OnyxEntry<Logins>) {
	return Object.values(logins ?? {})?.filter(isDeviceLogin);
	}

Object.values() returns entries in the Onyx object's key insertion order, which has no relationship to when a device was last used. So the FlashList in DeviceManagementPage renders devices in that arbitrary order:

App/src/pages/settings/Security/DeviceManagementPage.tsx

Line 35 in b2e9881

const [logins] = useOnyx(ONYXKEYS.LOGINS, {selector: getDeviceLogins});

There is already a getLastLogin helper that resolves the correct timestamp per device (falling back to created when lastLogin is still the default value), but it's only used for display, not ordering:

App/src/libs/UserUtils.ts

Lines 57 to 60 in b2e9881

	function getLastLogin(login: NewLogin) {
	// If we have not re-authenticated, then lastLogin will still be the default 2008-01-01 value. So the created time stamp will be more accurate in that case.
	return login.lastLogin > login.created ? login.lastLogin : login.created;
	}

What changes do you think we should make in order to solve the problem?

Sort inside getDeviceLogins (the single convergence point — it's the selector the page consumes), descending by the same timestamp the page displays:

function getDeviceLogins(logins: OnyxEntry<Logins>) {
    return Object.values(logins ?? {})
        .filter(isDeviceLogin)
        .sort((a, b) => getLastLogin(b).localeCompare(getLastLogin(a)));
}

The timestamps are ISO datetime strings, so string comparison orders them chronologically. Fixing it in the selector means DeviceManagementPage needs no changes and any future consumer of getDeviceLogins gets the sorted list too.

What alternative solutions did you explore? (Optional)

Sorting in DeviceManagementPage with a memoized value before passing data to FlashList — works, but leaves the shared selector returning unordered data, so every consumer would have to re-sort.

[KJ21-ENG]

Proposal

What is the root cause of that problem?

The Device Management page renders the array returned by getDeviceLogins directly in FlashList.

App/src/pages/settings/Security/DeviceManagementPage.tsx

Lines 35 to 80 in b2e9881

	const [logins] = useOnyx(ONYXKEYS.LOGINS, {selector: getDeviceLogins});
	const [autoGeneratedLogin] = useOnyx(ONYXKEYS.CREDENTIALS, {selector: autoGeneratedLoginSelector});
	const listHeader = (
	<View style={[styles.pv3]}>
	<RenderHTML html={translate('deviceManagementPage.description')} />
	</View>
	);
	const renderItem = ({item}: ListRenderItemInfo<Login>) => {
	const {deviceName, deviceVersion, os, osVersion} = item.additionalData ?? {};
	const displayName = getDeviceDisplayName(item, deviceName, deviceVersion, os, osVersion, translate('deviceManagementPage.unknownDevice'));
	return (
	<OfflineWithFeedback
	pendingAction={item.pendingAction}
	errors={item.errorFields?.revoke}
	onClose={() => clearRevokeError(getLoginKey(item))}
	contentContainerStyle={[styles.flexRow, styles.alignItemsCenter, styles.pv3, styles.gap3]}
	>
	<View style={[styles.flex1, styles.flexColumn, styles.gap1]}>
	<Text style={[styles.textLabelSupporting]}>{datetimeToRelative(getLastLogin(item))}</Text>
	<Text>{displayName}</Text>
	</View>
	<Button
	danger
	small
	text={translate('deviceManagementPage.revoke')}
	onPress={() => revokeDevice(item, autoGeneratedLogin)}
	/>
	</OfflineWithFeedback>
	);
	};
	return (
	<ScreenWrapper
	includeSafeAreaPaddingBottom
	testID="DeviceManagementPage"
	>
	<HeaderWithBackButton
	title={translate('deviceManagementPage.title')}
	onBackButtonPress={Navigation.goBack}
	/>
	<FlashList
	data={logins}
	renderItem={renderItem}
	keyExtractor={getLoginKey}

getDeviceLogins currently filters Object.values(logins ?? {}) to device login partner IDs, but it does not sort the result. That means the list inherits the Onyx object entry order instead of ordering by the device activity timestamp.

App/src/libs/UserUtils.ts

Lines 94 to 101 in b2e9881

	const DEVICE_PARTNER_IDS = new Set<number>([CONST.PARTNER_ID.IPHONE, CONST.PARTNER_ID.ANDROID, CONST.PARTNER_ID.NEWDOT, CONST.PARTNER_ID.OAUTH]);
	function isDeviceLogin(login: NewLogin) {
	return DEVICE_PARTNER_IDS.has(login.partnerID) && (!login.additionalData?.infiniteLoginRoot || login.additionalData.infiniteLoginRoot === login.partnerUserID);
	}
	function getDeviceLogins(logins: OnyxEntry<Logins>) {
	return Object.values(logins ?? {})?.filter(isDeviceLogin);

The timestamp shown in each row already comes from getLastLogin(item), and getLastLogin chooses the later of lastLogin and created.

App/src/pages/settings/Security/DeviceManagementPage.tsx

Lines 44 to 56 in b2e9881

	const renderItem = ({item}: ListRenderItemInfo<Login>) => {
	const {deviceName, deviceVersion, os, osVersion} = item.additionalData ?? {};
	const displayName = getDeviceDisplayName(item, deviceName, deviceVersion, os, osVersion, translate('deviceManagementPage.unknownDevice'));
	return (
	<OfflineWithFeedback
	pendingAction={item.pendingAction}
	errors={item.errorFields?.revoke}
	onClose={() => clearRevokeError(getLoginKey(item))}
	contentContainerStyle={[styles.flexRow, styles.alignItemsCenter, styles.pv3, styles.gap3]}
	>
	<View style={[styles.flex1, styles.flexColumn, styles.gap1]}>
	<Text style={[styles.textLabelSupporting]}>{datetimeToRelative(getLastLogin(item))}</Text>
	<Text>{displayName}</Text>

App/src/libs/UserUtils.ts

Lines 57 to 60 in b2e9881

	function getLastLogin(login: NewLogin) {
	// If we have not re-authenticated, then lastLogin will still be the default 2008-01-01 value. So the created time stamp will be more accurate in that case.
	return login.lastLogin > login.created ? login.lastLogin : login.created;
	}

What changes do you think we should make in order to solve the problem?

Update getDeviceLogins so it sorts the filtered device logins by getLastLogin(login) in descending order before returning them. This keeps the selector aligned with the timestamp displayed in the UI, including the existing fallback where an old default lastLogin should use created instead.

App/src/types/onyx/Logins.ts

Lines 6 to 20 in b2e9881

	/** The timestamp of when this login was created */
	created: string;
	/** The owner of this login */
	accountID: number;
	/** The ID for the partner for this login (either Expensify itself or another 3rd party service) */
	partnerID: number;
	/** This login's unique user ID for this partner */
	partnerUserID: string;
	/** Most recent timestamp of when this login was used */
	lastLogin: string;

For equal timestamps, add a deterministic tie-breaker such as comparing getLoginKey(login) so rows remain stable across renders.

App/src/libs/UserUtils.ts

Lines 53 to 60 in b2e9881

	function getLoginKey(login: NewLogin) {
	return `${login.partnerID}_${login.partnerUserID}`;
	}
	function getLastLogin(login: NewLogin) {
	// If we have not re-authenticated, then lastLogin will still be the default 2008-01-01 value. So the created time stamp will be more accurate in that case.
	return login.lastLogin > login.created ? login.lastLogin : login.created;
	}

Test coverage:

• Add unit coverage in tests/unit/UserUtilsTest.ts for getDeviceLogins returning only device logins sorted by the later of lastLogin and created descending.
• Include a case where lastLogin is older than created to verify the fallback behavior from getLastLogin.
• Include a same-timestamp case to verify the deterministic tie-breaker.

What alternative solutions did you explore? (Optional)

Sorting in DeviceManagementPage would also fix the visible list, but keeping the ordering in getDeviceLogins is better because the selector owns the derived device-login list and any future consumer receives the expected ordering without duplicating UI-side sorting.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @cretadn22 (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022073121152255669776