This topic is locked
[SOLVED]

dynamic permissions build broken in 10.6 latest build?

10/29/2021 3:44:23 PM
PHPRunner General questions
M
MikeT author

When I create a new project e.g. from the template Cars the dynamic permissions page always shows empty in the build (browser window of /admin_rights_list.php is empty).
Nothing custom just starting from a template like cars or even also with an empty project, following exactly the instructions from the manual about dyn. permissions and starting with an empty db (database is created by the template).

I then fired up 10.5 and created a new cars project with a new database, and there the page admin_rights_list.php works in the build.

woodey2002 10/29/2021

Keep playing around you will get it.

First try adding a admin user from the database tab in the security security button in runner, then make sure to add the same user under the dynamic permissions tab in runner.

If this fails try adding new security/user tables to the project.

Cheers,
J

admin 10/29/2021

It is a bit confusing. Cars template doesn't even use dynamic permissions so you are definitely doing something else there.

M
MikeT author 10/29/2021

Thanks for the hints, I thought I tried all of this, both starting with an enmpty project and then (after that didn't work) with a template.
In both cases it worked in 10.5 but not in 10.6.

But it's entirely possible that I didn't get something.

M
MikeT author 11/1/2021

Should it (in theory) be possible to switch to dynamic permissions at a later development stage, or should one decide at the beginning which system to use?

In other words: if you start with login via database users table, but not dynamic permissions, and later you're switching to dynamic permissions, will everything (in theory) adapt to dynamic permissions in subsequent builds?

Thanks!

M
MikeT author 11/2/2021

I think I got it working now.

But the documentation about the dynamic permissions should probably be updated some day. I'm not complaining, the automatically created tables and screens are very nice.

E.g. & unless I'm missing something the user edit page's save already hashes the passwords, no need to do it via events.
But the trick to unset $values['password'] if empty seems not to work there (like described in the manual, if you want an admin change user details but sometimes not also set a new password), at least not as it does on a normal users-table page like I used in the past (without this generated admin area).

admin 11/2/2021

There is a chance you are missing something. There are multiple scenarios possible and you need to make sure you understand what applies to your specific situation.

The normal scenario is that users register themselves. The password is created and encrypted automatically. The functionality like password change or reset also works automatically.

Sometimes, admin needs to be able to edit user's info. To prevent their password from being overwritten you either need to remove the password field from the user edit page or use the technique explained in the documentation.

M
MikeT author 11/3/2021

Yeah, I probably did something wrong.

I used the exact same technique outlined in the manual for the edit user page in the admin area generated by dynamic permissions.
In my use case I need the admin to set / enter new paswords on a users edit page, or leave the current pw as is.

Therefore I'm blanking the pw field on the edit page as outlined in the manual, and check before update if it's empty, If empty I unset the password field, if not it gets hashed (as explained in the manual).
This worked for me before on user edit pages, not using the admin area (w/o dynamic permissions).
But in the admin area / dynamic permission scenario the code/scenario outlined above didn't work if the pw field was empty.

that's why I was asking if anything is different on these pages.

But I'm closing the issue, I need to retry in a more quiet moment, sorry for the noise.