/assign

Hi @FelixMalfait, I would love to contribute but all good first issue are taken
/assign

/assign

Hey all, feel free to raise a PR since this is a short fix we'll merge the first correct one :). Thank you!

@FelixMalfait What's even more weird to me is that I can still interact with rows and update them.
Shouldn't the API raise dedicated exceptions when doing CRUD on deactivated object model ? Is that expected ?

I get your point but I'm not sure yet, because when we have apps they will make the assomptions that those standard objects exist so we might want to keep a behavior where it doesn't break and objects are just hidden

Ok I see 🤔
So deactivation is more of hidden/invisible feature.
What is the expected behavior here ?
Should we redirect to the page NOT_FOUND or create a dedicated page with an overlay over the record table ?

@prastoin to be honest I'm not sure exactly what it will be long-term (just hidden VS deeper deactivation — both are possible paths), that's why I'd suggest to maintain the status quo for now.

For that particular issue, I think the problem is in the logic that decides what is the first page after login.
We could also tackle adding a NOT_FOUND for deactivated objects as a separate issue, but I'm not convinced we should do it yet (again because the vision isn't mature enough so we'd better spend our time on things we're convinced of)

Ok makes sense !

For that particular issue, I think the problem is in the logic that decides what is the first page after login.

Unless I'm mistaken I couldn't reproduce this behavior on production. ( Added a new member to the workspaces and wasn't redirected to the company page by default )
Maybe it was due to your inApp navigation history of an other workspace ( sounds weird and would be a different bug )

Were you impersonating a user when this occured ?