Change defaultHomePagePath from /objects/companies to last visited page

[FelixMalfait]

Right now we assume the companies page exist, which is an issue because the company object can be disabled (useful for B2C).

It would be safer to fallback to /people which is less likely to be disabled.

But most importantly, we can set the default homepage to be the last visited view.

See: #6125 which is a pre-requisite / very close ticket, both could be eventually tackled together.

[Nabhag8848]

@FelixMalfait working on it and #6125 , also found out that even though when /objects/companies is disable its accesible when navigating manually by changing url.

[Nabhag8848]

Also what kinda behaviour we need for, say for eg: /objects/tasks was the last visited view and user went to settings, disabled tasks user closed the app. what should be defaultPath in that case when the user visited again -> cause this can happen similarly to /people if we fallback to /people.

this will also lead us to clear the lastView if currentLastView matches with the one which is being disabled.

[FelixMalfait]

@Nabhag8848 great thanks a lot!

also found out that even though when /objects/companies is disable its accesible when navigating manually by changing url
Good catch but not a big deal to be honest, I'm even not sure if we should block it for now. Depends on how much side effects this has.

For edge cases like the one you describe, I think we just want to fail gracefully without an error and not overcomplexify the code. It's such a rare event to disable an object that we don't want to optimize for a specific user experience in that case.

When I said "fallback to people" I think that was wrong. In useDefaultHomePagePath we should probably avoid hardcoding anything related to a specific object. We can instead, for example, take the first non-disable object that comes alphabetically. In most cases the user will go to the view stored in local storage after their signup and only very occasionally on new devices, end up on that page.

[charlesBochet]

@FelixMalfait we were also discussing introducing a position on object metadata. Should we default to the first non disabled object?

I'm not sure we should store this defaultView in DB, we don't store things in local storage for now and I don't think we should start with this use case and we still need a default anyway so I would go with the first non disabled object on sign-in

[FelixMalfait]

@charlesBochet yes the first non-disabled object, and yes we will introduce position but it's okay to start alphabetically for now, here's the ticket for it: #4889

We don't want to store in DB indeed, we want to store in localStorage as in #6125 which is linked
(and more specifically #5949 which is linked in #6125 and gives a technical input)

[Nabhag8848]

@FelixMalfait some questions:

1. I see we can deactivate all objects, what is the current behaviour in production ? when user first sign-up there is default objects being created (NoAccess: as I cannot without plan in prod ) ? .

• also what is the behaviour we need in this case, ideally maybe it will be like onboarding in future but currently we should assume there will be an atleast one object, right ?
• Also for now, if we proceed with assuming there will be atleast one, it doesn't break for good as we can access deactivated objects link.

2. Also can you give more context about what isRemote is for ?

twenty/packages/twenty-front/src/modules/object-metadata/components/ObjectMetadataNavItems.tsx

Lines 42 to 46 in 08c7947

	export const ObjectMetadataNavItems = ({ isRemote }: { isRemote: boolean }) => {
	const currentUser = useRecoilValue(currentUserState);
	const { toggleNavigationSection, isNavigationSectionOpenState } =
	useNavigationSection('Objects' + (isRemote ? 'Remote' : 'Workspace'));

[FelixMalfait]

@Nabhag8848 thanks for tackling this!

1. Prod is exactly the same as local, you can also create an account for free here: demo.twenty.com ; we do create all standard objects upon signup yes!
   Yes we can assume there will always be one object, if someone deactivate everything it's like they are trying to break the app on purpose 😅
2. It's a feature behind feature flag which we decided not to release for now. It allows you to bring in external objects that are not in the local database. For example you can connect your Postgres DB, a Snowflake DB or a Stripe account, and then those objects will automatically become available in the CRM. Data is not synced but accessed lived upon request

[Nabhag8848]

Thanks 🔥

[Nabhag8848]

EDIT: QUESTIONS RESOLVED

@FelixMalfait more questions:

[RESOLVED] 1. Lets say someone open object person record directly with url, in this case should last visited view should be updated to the one which is provided ?

object/person/<recordID>/view=<viewId>

[RESOLVED] 2. Can we delete the Data Models as of now ?, if not, just mentioning here we need to handle that case as well, if the lastVisited object is same as the deleted datamodel we need to clear it.

[RESOLVED] 3. There is a also one related bug in backend, once signin is completed, during that first time, objectMetadataItems have objects marked as active in isActive field even though it is deactivated. though after once the sign in is completed and as we navigate we are getting expected activeObjectMetadataItems, looks like first time we are getting metadata from a cache ? if it is, its just that when we activate and deactivate the data model, cache isn't getting refreshed to newest one. will open a issue for this cause currently I might not able to handle this.

Some more things which we have already achieved including our core issue.

• we also had to handle this for create and delete views, in case when we create views by default it navigates to that created view, in case when we delete we need to fallback to index view or view with first position. -> both cases needed be handle and should sync with localStorage.

• also we had to take care that scope is per workspace, which is achieved, so it also now works for different workspace. and things are persist across the workspace.