[3.6.0-alpha.4] Storing content in the accounts area fails with message "No route found for path account..."

[texnixe]

Describe the bug
When accessing an account via the account view (as opposed to via users/userid and try to save content, a dialog pops up with the error message "The form could not be saved. Exception: undefined No route found for path: "account" and request method: "PATCH" .

To Reproduce
Steps to reproduce the behavior:

1. In a Starterkit, go to Panel => Your account
2. Make some content changes
3. Try to save changes
4. See error

Expected behavior
The content should be stored without error.

Screenshots

Kirby Version
3.6.0-alpha.4

Console output

Desktop (please complete the following information):
MacOs with Firefox

Additional context
User can be updated without issues from panel/users/:userid

[afbora]

I reviewed the codes again. As I understand it, areas view don't have post and patch routes, only get. Routes other than get are loaded from API (/config/api/routes). Why don't (or can't) we define all view related routes from within fiber areas?

[lukasbestle]

The dialog submit methods use POST. The views don't. For example the site area uses the API at the moment to save data.

[afbora]

Exactly. Why don't we use/move it in views like in dialog? Or using method like that?

<?php

return function ($kirby) {
    return [
        ...
        'views'  => [
            [
                'pattern' => 'account',
                'action'  => function () use ($kirby) {
                    return [
                        'component' => 'k-account-view',
                        'props'     => $kirby->user()->panel()->props(),
                    ];
                },
            ],
            [
                'pattern' => 'account',
                'method'  => 'PATCH'
                'action'  => function () use ($kirby) {
                    return  return $kirby->user()->update($kirby->requestBody(), $kirby->language(), true);
                },
            ],
        ]
        ....
    ];
};

[lukasbestle]

Good question. Maybe we didn't want to duplicate the existing API routes? @distantnative?

[distantnative]

I think Bastian's main rational was exactly that, to not duplicate the API code for these (since we'd still need to make this action available via the REST API).

I would think this issue might be related to the issue about accessing user files via the account view - maybe the solution would work here as well?

[lukasbestle]

Yeah, then I think we should fix the issue by using the correct API methods.

[bastianallgeier]

✅