v3 Manager actions with parse errors - admin Resource delete issue, editor can't open Resource

[nick0]

(edit: I misread the version as 3.1.17 instead of 3.1.7)

Hello,

I recently updated my starter site from 1.4.15 to 3.1.7 using the Migration plugin and have a couple of puzzling (presumably permissions related) parse issues.

I'm looking for some high level / technical help from @Dmi3yy and/or the devs please.

The same parse issues detailed below happen with new users and new roles - and with or without a custom manager folder name.

The site is using php 7.4.

Confirming that these things do not happen in the 1.4.15 site that this site was migrated from - everything works as expected in the Evo 1 Manager.

Also posted here in the forum if interested.

1 Administrator role

When I delete a Resource (aka a page in the LHS site tree), the Parse Error "Call to a member function toArray() on null" is thrown with a popup that says "You do not have the correct permissions for this resource".

The Resource still gets the red strike through (eg so it is actually deleted) but something is obviously not quite right given the error is thrown.

This is with the main / only Administrator account.

Same parse error occurs with a totally new user with the Administrator role trying to delete a Resource.

I created a totally new Admin user but experience the exact same issue when trying to delete a Resource.

In checking out Users > Roles, the Administrator role is greyed out and says "This role cannot be edited or deleted." I presume that to mean I should have maximum editing capabilities for all users with the Administrator Role. Why I can't delete a brand new Resource like normal is beyond my skill set.

Here is a copy of the parse error...

Parser / Call to a member function toArray() on nu - System Events
Event Id: 	0 	Source: 	Parser / Call to a member function toArray() on nu

« Evolution CMS Parse Error »
Call to a member function toArray() on null
Error information 	
File 	/home/my-site/public_html/my-custom-manager/actions/mutate_content.dynamic.php

Backtrace
Illuminate\Support\Facades\Facade::__callStatic('handleRoute', array $var2)
my-custom-manager/index.php on line 162
EvolutionCMS\ManagerTheme->handleRoute()
core/vendor/illuminate/support/Facades/Facade.php on line 261
Illuminate\Routing\Router->dispatch(Illuminate\Http\Request $var1)
core/src/ManagerTheme.php on line 407
Illuminate\Routing\Router->dispatchToRoute(Illuminate\Http\Request $var1)
core/vendor/illuminate/routing/Router.php on line 625
Illuminate\Routing\Router->runRoute(Illuminate\Http\Request $var1, Illuminate\Routing\Route $var2)
core/vendor/illuminate/routing/Router.php on line 636
Illuminate\Routing\Router->runRouteWithinStack(Illuminate\Routing\Route $var1, Illuminate\Http\Request $var2)
core/vendor/illuminate/routing/Router.php on line 672
Illuminate\Pipeline\Pipeline->then(Closure $var1)
core/vendor/illuminate/routing/Router.php on line 697
Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Illuminate\Http\Request $var1)
core/vendor/illuminate/pipeline/Pipeline.php on line 103
EvolutionCMS\Middleware\VerifyCsrfToken->handle(Illuminate\Http\Request $var1, Closure $var2)
core/vendor/illuminate/pipeline/Pipeline.php on line 167
Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Illuminate\Http\Request $var1)
core/src/Middleware/VerifyCsrfToken.php on line 13
EvolutionCMS\Middleware\Manager->handle(Illuminate\Http\Request $var1, Closure $var2)
core/vendor/illuminate/pipeline/Pipeline.php on line 167
Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Illuminate\Http\Request $var1)
core/src/Middleware/Manager.php on line 25
Illuminate\Session\Middleware\StartSession->handle(Illuminate\Http\Request $var1, Closure $var2)
core/vendor/illuminate/pipeline/Pipeline.php on line 167
Illuminate\Session\Middleware\StartSession->handleStatefulRequest(Illuminate\Http\Request $var1, Illuminate\Session\Store $var2, Closure $var3)
core/vendor/illuminate/session/Middleware/StartSession.php on line 64
Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Illuminate\Http\Request $var1)
core/vendor/illuminate/session/Middleware/StartSession.php on line 121
Illuminate\Routing\Middleware\SubstituteBindings->handle(Illuminate\Http\Request $var1, Closure $var2)
core/vendor/illuminate/pipeline/Pipeline.php on line 167
Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Illuminate\Http\Request $var1)
core/vendor/illuminate/routing/Middleware/SubstituteBindings.php on line 50
Illuminate\View\Middleware\ShareErrorsFromSession->handle(Illuminate\Http\Request $var1, Closure $var2)
core/vendor/illuminate/pipeline/Pipeline.php on line 167
Illuminate\Pipeline\Pipeline->Illuminate\Pipeline\{closure}(Illuminate\Http\Request $var1)
core/vendor/illuminate/view/Middleware/ShareErrorsFromSession.php on line 49
Illuminate\Routing\Router->Illuminate\Routing\{closure}(Illuminate\Http\Request $var1)
core/vendor/illuminate/pipeline/Pipeline.php on line 128
Illuminate\Routing\Route->run()
core/vendor/illuminate/routing/Router.php on line 695
Illuminate\Routing\Route->runController()
core/vendor/illuminate/routing/Route.php on line 205
Illuminate\Routing\ControllerDispatcher->dispatch(Illuminate\Routing\Route $var1, EvolutionCMS\Controllers\Actions $var2, 'handleAction')
core/vendor/illuminate/routing/Route.php on line 262
EvolutionCMS\Controllers\Actions->handleAction()
core/vendor/illuminate/routing/ControllerDispatcher.php on line 48
EvolutionCMS\ManagerTheme->handle(27)
core/src/Controllers/Actions.php on line 27
Illuminate\View\View->render()
core/src/ManagerTheme.php on line 420
Illuminate\View\View->renderContents()
core/vendor/illuminate/view/View.php on line 91
Illuminate\View\View->getContents()
core/vendor/illuminate/view/View.php on line 122
Illuminate\View\Engines\PhpEngine->get(string $var1, array $var2)
core/vendor/illuminate/view/View.php on line 139
Illuminate\View\Engines\PhpEngine->evaluatePath(string $var1, array $var2)
core/vendor/illuminate/view/Engines/PhpEngine.php on line 38
Illuminate\Filesystem\Filesystem->getRequire(string $var1, array $var2)
core/vendor/illuminate/view/Engines/PhpEngine.php on line 58
Illuminate\Filesystem\Filesystem::Illuminate\Filesystem\{closure}()
core/vendor/illuminate/filesystem/Filesystem.php on line 108
require(string $var1)
core/vendor/illuminate/filesystem/Filesystem.php on line 107
include_once()
my-custom-manager/views/page/27.php on line 5

2 Editing / Publishing roles

When simply attempting to open a Resource, the Parse Error "Parser / SQLSTATE[42S22]: Column not found: 1054 U" is thrown.

The user cannot open any of the LHS tree Resources at all, I see the following on the top of the RHS frame.

This is a copy of the parse error from the RHS frame:

Source: Parser / SQLSTATE[42S22]: Column not found: 1054 Unknown column 'modx_document_groups.document_group' in 'where clause' (SQL: select `modx_site_tmplvars`.*, `modx_site_tmplvar_contentvalues`.`value`, `modx_site_tmplvar_templates`.`rank` as `tvrank`, `modx_site_tmplvar_templates`.`rank`, `modx_site_tmplvars`.`id`, `modx_site_tmplvars`.`rank` from `modx_site_tmplvars` inner join `modx_site_tmplvar_templates` on `modx_site_tmplvar_templates`.`tmplvarid` = `modx_site_tmplvars`.`id` left join `modx_site_tmplvar_contentvalues` on `modx_site_tmplvar_contentvalues`.`tmplvarid` = `modx_site_tmplvars`.`id` and `modx_site_tmplvar_contentvalues`.`contentid` = 178 left join `modx_site_tmplvar_access` on `modx_site_tmplvar_access`.`tmplvarid` = `modx_site_tmplvars`.`id` where `modx_site_tmplvar_templates`.`templateid` = 5 and (`modx_site_tmplvar_access`.`documentgroup` is null or `modx_document_groups`.`document_group` in (1, 4)) order by `modx_site_tmplvar_templates`.`rank` asc, `modx_site_tmplvars`.`rank` asc, `modx_site_tmplvars`.`id` asc) - Editing resource - The details of the error could be seen in the Evolution CMS system events log.

No problems for these users accessing / editing chunks etc. Just Resources.

Confirming that I fully deleted the Editing and Publishing roles, cleared the cache and recreated new roles (albeit with the same names) with the same privelages.

Same thing happens for a User with the new roles. If I change the Role of a User to Administrator I can edit and save a Resource as expected - however per issue 1 above, I cannot delete a Resource without throwing that parse error with the pop up error.

@BBloke had a look at this for me. He thinks the reason it might be failing "is because the SQL statement doesn't know about the document_groups table and cannot apply a WHERE statement against it."
He played with the statement and got it working if he "left join that table into the statement. This is a core function and not something that can be messed with."
Not sure if that sheds any light on the issue for the devs?

Something very weird is going on in these roles / permissions that is beyond my understanding.

Any ideas on how to resolve?

Perhaps there is something lingering from 1.4.X in the database that you could please point me towards to look for and remove?

Please help devs.

I can give Evo 3.1.17 manger access to a demo site that experiences these same issues if you'd like to experience them and diagnose - just let me know how to get the details to you privately (eg an email address?).

Many thanks in advance.

[nick0]

Just having a look at the database in phpMyAdmin.

Could it be related to data in the role_permissions table?

Evo 3 Fresh install looks like this - does not have the 2 parse issues detailed in the original post...

Evo 1 to Evo 3 Migrated website 1 looks like this - does have the 2 parse issues detailed in the original post...

Evo 1 to Evo 3 Migrated website 2 looks like this - does have the 2 parse issues detailed in the original post...

[fourroses666]

1. Did you check the roles > the role like editor > permissions?

• Access rights management > Access rights & Web access control checked

I noticed my normal Editor users couldn't access the Manager! After checking these 2 checkboxes it was accessible again.

2. After Migrate reinstall the same version?
   I noticed I couldn't access the Image gallery and had some error in the Tree and after reinstall that was fixed. So I always migrate and the reinstall. (at this moment 3.1.7)

[nick0]

1. Did you check the roles > the role like editor > permissions?

Yes, I totally recreated them and as per what is working aok in 1.4.15.

Regardless, Admin role has full access so delete should not throw an error.

This is the editor role's permissions, looks ok to me for simply opening a Resource:

* Access rights management > Access rights & Web access control **checked**

I noticed my normal Editor users couldn't access the Manager! After checking these 2 checkboxes it was accessible again.

Yes, these 2 options in configuration were already selected like so.

1. After Migrate reinstall the same version?
   I noticed I couldn't access the Image gallery and had some error in the Tree and after reinstall that was fixed. So I always migrate and the reinstall. (at this moment 3.1.7)

Agreed, necessary and reinstalled multiple times.
That is necessary given the 1.4.15 to 3.1.17 update produces many issues. Resintalling did solve a fair few.

I think there might be something lingering in the database as suggested that needs special dev input.

But out of interest,,, do the role_permissions table in your sites look anything like the screencaps in the second post above?

[fourroses666]

Hmm, you have it on Admin role. I really have no idea to solve that. Looks like some settings from EVO 1 got stuck and needs to be reset or something. With Admin role you should have all access. You could try to add a new role and check all checkboxes and see what happens. Or try to re-enter your password, I don't know.

Maybe some TVs have no rights. When I add a new TV I see I can give permission access to them even Administrators.
I don't use this permission stuff on my sites.

[nick0]

No worries, thanks for the suggestions Marc - unfortunately I think I really need help from the devs who are eerily quiet at the moment - @Dmi3yy please help so I can resolve this and keep moving.

This is a new admin user with a new password using the default Administrator role - so I presume it's not password related and I can't edit the admin role.

Agreed, I am presuming this is related to the new roles and permissions in Evo 3 and something is lingering in the database from Evo 1 that is causing a hiccup. On Googling the Editor related parse error, a few responders in Stack Overflow mentioned Lavarel so who knows, perhaps it is a Lavarel error - I have no idea as a non coder.

Good thinking Marc. I didn't even know TVs had to have rights...

...regardless, checking and saving for all 4 roles in my test site - that literally now has only one TV for testing - makes zero difference, both errors persist.

Just checked a page with a template in the test site which has no tv's attached - both parse errors exist as reported. Therefore I am presuming this is not related to giving permissions to TV's.

Access permissions are like so... so surely should work for Admin to delete a Resource and Editor to open a Resource with All Resource Groups (Public) checked.

Please help devs.

Thanks.

[BBloke]

I've been looking at some things of my own and found it's giving me headaches.

I've happily found the difference between "Access Permissions" and "Web Access Permissions" from a manager log in POV.
The first allows manager access, whereas the second doesn't! (just the bear basics).

So I have a new user set to a specific user role who can sign in to the manager. The user is assigned in to the SiteAdmin Group.

I can see all the documents in the document tree. All public documents are lit whilst private documents are greyed. Documents contained within the User Group my user is assigned to are also greyed out.

I would expect documents that I'm in the group of to be editable?

When I click a public document I get the same WHERE clause error. I think I found the file which handles the SQL statement. Line 898 of manager/actions/mutate_content.dynamic.php so I changed it from:

$tvs = SiteTmplvar::query()->select('site_tmplvars.*', 'site_tmplvar_contentvalues.value', 'site_tmplvar_templates.rank as tvrank', 'site_tmplvar_templates.rank', 'site_tmplvars.id', 'site_tmplvars.rank')
                                    ->join('site_tmplvar_templates', 'site_tmplvar_templates.tmplvarid', '=', 'site_tmplvars.id')
                                    ->leftJoin('site_tmplvar_contentvalues', function ($join) use ($id) {
                                        $join->on('site_tmplvar_contentvalues.tmplvarid', '=', 'site_tmplvars.id');
                                        $join->on('site_tmplvar_contentvalues.contentid', '=', \DB::raw($id));
                                    })->leftJoin('site_tmplvar_access', 'site_tmplvar_access.tmplvarid', '=', 'site_tmplvars.id');

To this: (I don't know if it would be left join or inner join?

$tvs = SiteTmplvar::query()->select('site_tmplvars.*', 'site_tmplvar_contentvalues.value', 'site_tmplvar_templates.rank as tvrank', 'site_tmplvar_templates.rank', 'site_tmplvars.id', 'site_tmplvars.rank')
                                    ->join('site_tmplvar_templates', 'site_tmplvar_templates.tmplvarid', '=', 'site_tmplvars.id')
                                    ->leftJoin('site_tmplvar_contentvalues', function ($join) use ($id) {
                                        $join->on('site_tmplvar_contentvalues.tmplvarid', '=', 'site_tmplvars.id');
                                        $join->on('site_tmplvar_contentvalues.contentid', '=', \DB::raw($id));
                                    })->leftJoin('site_tmplvar_access', 'site_tmplvar_access.tmplvarid', '=', 'site_tmplvars.id')
									->leftJoin('document_groups', 'document_groups.document', '=', 'site_tmplvar_contentvalues.contentid');

Not sure but would save_content.processor.php line 197 need this change too? It looks similar! I found it by running a find in files with 'orWhereIn' inside the manager folder.

I can now click a public document and edit it. Resource locking is working too.
I can also click on a document within the user group I'm assigned to and edit that document.
In fact, I can click on any document (greyed or not) and edit any document! Should that be the case?

Back in my test site with out the modification. I have two documents, public and private. My user is not in the private group. I can see the public document only and I can edit that document.

After adding my User into the Private group I can no longer edit a public document and the private documents are greyed.

I get the following error:

« Evolution CMS Parse Error »
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'h8py_document_groups.document_group' in 'where clause' (SQL: select `template`, `menuindex` from `h8py_site_content` where `h8py_site_content`.`parent` = 2 and `h8py_site_content`.`published` = 1 and `h8py_site_content`.`deleted` = 0 and (`isfolder` = 0 and `id` = 1) and (`privatemgr` = 0 or `h8py_document_groups`.`document_group` in (1)) and `h8py_site_content`.`deletedon` = 0 order by `menuindex` asc limit 1)

I cannot find where the code is for the above to take a look. I couldn't find it when searching for 'orWhereIn' inside PHP files in the manager folder. A wider search revealed

** No Template variables are assigned to any document. Assigning TV's doesn't change the error in this instance.
As far as my documents are showing, the home page is showing as public for Web and Manager and the private document is showing Web Public and Manager Private. On my migrated site all documents which are in a resource group are private for web and manager but new resources show Web Public and Manager Private, Web access isn't allowed to private pages.

I guess the Web/Manager access is mute as there is only User Access?

There is something flawed in the current single user, role, resource and user group settings that I cannot get my head around completely.

I think the above issue is in core/src/Core.php in getDocumentChildren. There are a couple of where statements that require document from document_groups but there is no join.

I changed it to:

if ($this->isFrontend()) {
            if (!$docgrp) {
                $documentChildren = $documentChildren->where('privatemgr', 0);
            } else {
                $documentChildren = $documentChildren->where(function ($query) use ($docgrp) {
                    $query->where('privatemgr', 0)
                        ->orWhereIn('document_groups.document_group', $docgrp);
                })->join('document_groups', 'document_groups.document', '=', 'site_content.id');
            }
        } else {
            if ($_SESSION['mgrRole'] != 1) {
                if (!$docgrp) {
                    $documentChildren = $documentChildren->where('privatemgr', 0);
                } else {
                    $documentChildren = $documentChildren->where(function ($query) use ($docgrp) {
                        $query->where('privatemgr', 0)
                            ->orWhereIn('document_groups.document_group', $docgrp);
                    })->join('document_groups', 'document_groups.document', '=', 'site_content.id');
                }
            }
        }

There is one more change needed to ensure it works and that is in /core/functions/actions/mutate_content.dynamic.php line 18 mine now reads:

$where = ['isfolder' => 0, 'site_content.id' => $site_start];//"sc.isfolder=0 AND sc.id!='{$site_start}'";

This is pretty major surgery and it's taken me an age to find and fix but I wouldn't say it's perfect. I have given no consideration to the implications that it could quite easily break something else.

I hope it helps the devs.

[nick0]

Brilliant, thanks @BBloke - amazing detective and coding work.
Hello @Dmi3yy and fellow devs...

[bossloper]

You have done a lot of digging there @BBloke ... nice one!

This is still a complete road block for me.
For the record we had a bit of a discussion about it back here too: https://forum.evo.im/d/92-login-for-web-users-with-error-no-table-web-user-attributes/16

@Dmi3yy Do we need separate 'web permissions' and 'manager permissions' adding back in instead of this single 'access permissions'. As they were for 1.4.x ?
'Web Public' and 'Manager Private' logic is broken in 3.x.

[Seiger]

It fix in the last release.