adrian

Those permissions only allow access to see the Setup > Admin Actions menu. In the other thread I mentioned that you need to give roles access to each specific action. I am still not clear if you have done that or not. I am referring to the interface below in the module's settings. Can you confirm you have given access to your custom action?

Hi @fruid - you need to assign roles to the action within the module settings interface.

Hi @ryan - all sounds very cool! I just upgraded by local sandbox install and now I am seeing: Error: Call to a member function isDefault() on bool in /wire/core/PagesLoaderCache.php:311 It seems to be coming from the $page->get('process=236') call, but you should see it if you have Tracy running with any of these panels open: Let me know if you have any troubles reproducing.

Thanks - I wasn't thinking about that Login option - yes, I think it is handy - much nicer that the core login dance :) Yeah, I suppose we could go with 41 or the first available superuser, but if I implement this, I think it would be better to use the user switcher and have the option to choose. Regarding having access to everything on the bar already - that's not quite true - I do also prevent access to Adminer in this situation. Whether I really have good justification for that or not is another question, but I do want to have a more thorough think through this moving forward to make sure I am not overlooking anything of concern.

Hi @bernhard - I don't know about a "Login as superuser" because you may have more than one superuser so how would you know which one to log in as. One possibility would be to allow the user switcher panel to always show for local dev and you could select the user from there, but I need to think about this a bit more because it would allow logging in as a superuser without having initially started a user switching setting as a superuser. I know it's local dev only and all, but it still makes me nervous. I have modified the user switching to work like the language switching - not double-click btw, just a single click is all that is needed. I'll commit this later. Not really sure what you mean here - which login button are you talking about?

Sorry, seems like I need to make the ajax call to saveUserActivity() myself. That seems to be working and updating status as expected. Now it's really just a matter of triggering that UserActivity popup alert instead of the PW warning. And of course have it triggered when an ajax triggered saveUserActivity() call is made from the frontend.

Hi @ryan, That is kinda what I tried already. From my testing, the first part of that code doesn't actually trigger the ajax updates. Of course the initial loading of the front end profile is logged by UserActivity by default anyway, so I don't need that for initial testing of the alert in the admin, but without it, it's not actually useful in the real world. Any ideas why the ajax wouldn't be working? The second part works as a notifier, but to be useful I think it really needs to trigger the same dialog that UserActivity normally displays. Unfortunately the core PW warning banner doesn't really work for this because if there is more than one alert, the rest are collapsed and editors aren't going to expand it to see the "User may be editing their profile right now" message. How can we trigger the user activity alert instead? Thanks!

@ryan - just realized that I possibly wasn't very clear above. I understand that frontend users are tracked and they appear in the Access > User Activity list. What I am looking to do it tie their activity on a specified front-end URL (basically a custom profile editing form) to their user page in the admin, so that if admin editors go the user's page in the admin, they'll see the "current being edited by" warning. Hope that makes more sense. Thanks!

@ryan - is there any chance of adding support for using this module on custom frontend forms? Maybe it's already supported somehow, but my initial limited experiments didn't seem to get me very far. The idea is that you don't want staff editing a user profile in the admin at the same time the user is editing it themselves via their frontend interface. Thanks!

Sorry, by closing the panel I actually meant disabling it (via the selector panel). How do you exclude the icon from the debug bar? Am I forgetting about a feature of my own module :) ?

Hi @Robin S Honestly, I am not really sure there is a need for a time limit at all. Given that only a superuser can start a session, I am not really sure we need a limit different from whatever the PW session timeout is in config.php Let me take a look - I think I can probably remove the time limit and just ensure that the session is killed when the panel is closed or if you click the End Session button.

Oh, sorry - long day :) There is the $session->tracyUserSwitcherId which is set whenever a user switcher session is active. Does that help?

Hi @Robin S - that doesn't seem right to me. Can you reproduce on other sites? If so, does it also return true in the Console panel like in this example where I am getting false?

Just an FYI that a couple of years ago I used Soma's multisite with ARB without any issues - in case that is at all useful. Do let me know if there is anything I can do to allow that AdminRestrictBranch::getBranchRootParentId to not break things.

Is there a problem with my version of the module, or just kixe's? What features does that have that made you choose it - can I integrate them into mine?

Thanks @Pete - I've been running that module on PHP 8 - surprised I hadn't come across the error before. Should be fixed now!

Next up is @Jonathan Lahijani !! Really appreciate the support everyone.

Now I feel like I am just hijacking this thread, but another big shout-out, this time to @elabx

And another big thanks to @Pixrael for being number two!

Just wanted to send a big thanks @flydev ?? for being my first Github sponsor!

Thanks @Jan Romero - I am running the latest version from the modules directory, but I see that your fix was implemented since it was last updated - looks like it needs a version number bump here to force an update.

Hi @thetuningspoon - I just noticed this: https://github.com/processwire/processwire-issues/issues/1599 Looks like this module needs to adjust how it inserts itself when a field is Locked. Please let me know if you have any problems reproducing.

Nothing serious - I use it on several sites without any real problems. I guess I just don't really like the inheritance / defaults setup. It's also a shame that Wanze isn't really around here much anymore.

That's not always a bad thing - if it ain't broke, don't fix it :) There is the module by bitpoet that works in reverse (I think - I have used that one, but not this one).

Awesome - thank you! I had forgotten that class_exists tries to load unless you set that optional autoload argument to false. I've made that change so the new version has it. Thanks again.