Is it viable to use Orchid as a user dashboard instead of SOLELY for admins?

[TomDo1234]

My company sells software

My company wants a dashboard where regular users can update their details such as:

The devices they have registered to our software
Their software license numbers
And other things as well such as what level of software they own

I dont want a dashboard that is solely for admins, I want users that can only update their own details in addition to the "admin" users that can do everything such as delete users and stuff.

Is this viable with Orchid? And if so do I have to make my own register/create new user page?
If I have to make my own create new user page, what is the best way to do this with Orchid? How do I use the CSS styles from the login page into my register page?

[dkarvounaris]

Well, this is what I'm trying to achieve also now, as I'm testing Orchid. I managed so far to have different menus depending on the user, even several menus for the same user, able to switch back and forth. Specifically:

I'm building a SaaS, so the administrators must have access to a special admin area, where they can manage some things separately from anything else the SaaS offers to other users. As also, have access to the regular pages. This was actually very easy to achieve. I used the new Laravel Pennant package to create "features", which would represent the abilities or features available to specific types of users. This additionally helps abstracting away permissions and roles, which decouples them in a nice way and provides other benefits.

Already, the feature can be assigned to specific users, which are gonna have available only specific menus and screens to them, even though, roles have not been fully implemented yet. This comes next, as I'm looking to replace Orchids integrated authentication with another package (specifically "Bouncer", as it allows objects to be owned and restricts access on entity ID). This should be though not a big issue I believe, just by simply ignoring Orchids authentication feature and do it the usual way - or use the alternative package inside of it, if possible. But it's still something I have to look at.

The current selection happens in the registerMenu(), like this:

    public function registerMenu(): array
    {
        Feature::forget(HubAdmin::class); // never use cached value for security

        return match (true) {
            $this->onAdminHub() => $this->buildAdminMenu(),
            $this->onSiteHub() => $this->buildSiteMenu(),
            $this->onHub() => $this->buildUserMenu(),
            default => []
        };
    }

I have separated the menus to be constructed in separate methods. The on*() methods check for Feature::active() as also, if the current use is one of the routes of the menus, to select which to display. They are like this:

    protected function onAdminHub(): bool
    {
        return Feature::active(HubAdmin::class) && Str::contains(Route::current()?->getName(), 'hub.admin.');
    }

The build*() methods contain, what usually would go in the registerMenu() method, creating the menus. Though, I abstracted one level more away, into specific "menu" classes containing only sections of the menu, and created a MenuBuilder class which "composes" the array that would be usually here. This allows me, to split a menu up into sections, which can be re-used in different menus avoiding duplication, and allows me at an even later time adding "hooking" functionality for packages in the menus. This is how it's done (notice how entries can be individually managed with the Feature::active() for specific users):

    protected function buildSiteMenu(): array
    {
        return (new MenuBuilder())->build(
            NavigationMenu::class,
            DocsMenu::class,
            ...Feature::active(HubAdmin::class)
            ? [
                GoToAdminHubMenu::class,
            ]
            : []
        );
    }

The only thing left is, to implement roles too, even though the Feature already sufficiently block accessing another URL entered manually, as long all the paths contain a feature check. Permissions or roles provide a better layer of security though, at a higher level, Features provide a finer control by many different means (imagine using them to determine not just by user access, but also by which plan they subscribed to, by which team they belong to etc.)

So far Orchid has shown to be more flexible than any other package I tried in the past, where I would always hit a barrier regarding customization beyond the basic features.