adrian

@kongondo - just wanted to check to make sure the new "current user" row at the top of the table helps with your initial concern?

Nice ? Typically in the Console, you are better off using d() which dumps to the results panel below. This isn't about permissions in the sense you are talking about. It's just for these page permissions: https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/wire/core/Page.php#L88-L107 Maybe it needs to be reimagined, but that was my initial goal for this. What does everyone think?

Hi everyone, Thanks for all the good thoughts and ideas! There is of course the User Switcher panel which I use the all the time to check issues a client is having - that's the best way to see the site the way they are seeing it. I have just added a new row at the top of the table that shows the permissions for the current user (in this case "ajones"), so this is either you, or if you are using the UserSwitcher panel then it will obviously be for that user. Does that help with what you are looking for? It is using the same colors as the other panels. The colors are all now defined as constants. in the main TracyDebugger class. I know it's a bit loud here, but the idea is for form over function in identifying which roles don't have a certain permission. That said, I'd also be ok with this if you guys prefer: The key thing I think is that I know how many permissions there are and they easily fit on the width of the screen. I don't know how many roles there will be. Does anyone else have any thoughts on this? Not sure if I can because the script that handles the dump doesn't actually know how many dumps are coming, but maybe it can be done with JS after the fact - I'll take a look. I'll need to think about this some more - I feel like we are starting to get into the territory of this module: http://modules.processwire.com/modules/process-access-overview/ which is not really the goal here, or at least it wasn't. I'll let you guys chime back in on what you think would actually be most useful. Thanks again for all the feedback - greatly appreciated!

Anyone have any thoughts for this new panel before I publish it? Pretty self-explanatory - it shows the status of the various permissions for the current page for all user roles. This should make it much easier to quickly check things if a client complains they don't have access to do a certain action on a specific page. I'll probably commit tomorrow, but just wondering if you guys have any other ideas for this first. Actually, I am now wondering if perhaps this should just be a new section in the RequestInfo panel, rather than a dedicated panel. Any thoughts on this? Thanks!

No problem at all - it was an easy fix at my end for AdminActions - just a bit of initial confusion ?

Awesome - thanks for your help getting this sorted out!

Interesting - turns out that AOS actually adds AdminThemeDefault to html which is why it was working for me here. @tpr - is this something that can or should be changed? Anyway, thanks for helping to debug this - I have updated the CSS with part of what you provided above, but it had a problem with UiKit, so it's a combined version that seems to work with both themes and with AOS on and off. Please let me know if it looks ok at your end. I think if you save the module settings page it should fix the icons. Can you please confirm.

Surely this is the simplest approach, or maybe I am misunderstanding? foreach($page->fields as $f) { echo $page->$f; }

Also curious why you aren't seeing the icons I recently added to all of the actions - does saving the settings page take care of that?

Hi @matjazp - I just tested the default theme on Safari, FF, and Chrome and it looks fine here. The css I added to fix the position of the links (and also the space between the text above the tabs) is: html.AdminThemeDefault li#AdminActionsList ul.WireTabs { margin-top: 3em; } https://github.com/adrianbj/ProcessAdminActions/blob/d95cafe225c958db38e015ebe5df329ed9e826db/ProcessAdminActions.css#L5-L7 Would you mind taking a look to see if that is being applied please. Maybe it needs an !important added to it. I'll sort out that undefined index notice

@matjazp - I decided to take a look now and I have pushed a fix which seems to have things working well in the default theme as well as Uikit. Please let me know if it looks ok at your end now also.

Right, I see the problem now looking at it with the default theme. I can take a look tomorrow to see if I can get it working there as well.

Hi @matjazp - thanks for the report but I can't reproduce here. I just tested on Chrome, Safari, and Firefox. Any chance it's due to a cached version of the old css file?

Just an FYI on this front - $urls is linked to from the API Variables section of the Tracy PW Info panel. It is always up to date because it makes use of: $this->wire('all') to get all available variables.

Apparently I have a compulsion for new keyboard shortcuts ? Just added these: SHFT + Enter Expand to fit all code and add new line (saves position) SHFT + Backspace Contract to fit all code and remove line (saves position) I have also modified the drag resizing to automatically snap to row heights.

I think so, although typically I see: $this->wire()->scripts rather than $this->wire->scripts although I don't honestly know if it makes a difference. OT, but note that in the Console, I need to use $module instead of $this for the name of the module, but otherwise you can test all these options there.

For module development you should actually use: $this->wire('config')->scripts->add($this->wire('config')->urls->$this Take a look at Ryan's Github repo (https://github.com/ryancramerdesign/) for his most recent modules and you'll see that is the approach he takes. @LostKobrakai has an excellent post on when it's ok use: $config vs $this->config vs $this->wire('config') but I can't find it right now.

Sounds really nasty Ryan - keep on top of it and heal up quickly!

Just a quick not to mention that Admin Actions now supports two additional properties: $executeButtonLabel $icon I am sure both are self-explanatory, especially when you see them in action. I think both are useful additions for your custom actions.

I completely agree. The functions API may not even be turned on for the user's PW install. That said, you could still use: $this->wire('config')->urs->$this as the safest short URL.

It's not linked to but: http://processwire.com/api/ref/urls/ I learned about this from a blog post: https://processwire.com/blog/posts/processwire-3.0.40-core-updates/#urls-and-paths Pity the docs are hidden. Also a shame there's no $paths equivalent.

I make use of three different free services (in a fallback type scenario) in the Cookie Management Banner module: https://github.com/adrianbj/CookieManagementBanner/blob/945d406d227c821a27be972f3a63ce4c4d44c613/CookieManagementBanner.module#L62-L85 ip.nf geoip.nekudo.com ip.sb You can read a little about my conversation with the ip.nf folks here:

Hi @PCuser - sorry you're having problems. I just tested with an image with exactly that filename and it worked just fine. I wonder if there is something else at play here. Any chance you could do a little debugging? Firstly try on a clean PW install and if that works, see if it's some other module that is conflicting. Or perhaps it's specific image field settings at play. Does it work with a newly created image field with default settings? You get the idea ?

Or if you are only supporting recent'ish versions of PW: urls()->$this . 'script/test.js';

You don't even need className config()->urls->$this . 'scripts/test.js';