Module Tracy Debugger

[kongondo]

2 minutes ago, adrian said:

This isn't about permissions in the sense you are talking about. It's just for these page permissions:

Of course, again! Sorry, am half asleep! Custom permissions are mainly used with custom modules ?

[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?

[gmclelland]

Ya, I initially thought it would show all the permissions.

As for the colors: maybe a light green background with a dark green check mark and light red/pink background with a dark red "X" ?

[kongondo]

1 minute ago, adrian said:

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

It does, thanks!

[bernhard]

27 minutes ago, adrian said:

Better imho! I think it could even be grey instead of orange. I'll play around with it one day, but atm I'm busy with other stuff and don't need to care about permissions a lot ? Maybe @tpr comes up with a good suggestion...

 

13 minutes ago, adrian said:

19 minutes ago, kongondo said:

So no custom permissions then?

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?

Oh. I also thought it would list all available permissions. 

 

31 minutes ago, adrian said:

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.

Didn't know about that one. You are absolutely right. Anyhow, it was just an idea. Personally I don't have a need at all for such a panel, but I'm quite sure it can be very handy to have one day...

[bernhard]

8 minutes ago, gmclelland said:

As for the colors: maybe a light green background with a dark green check mark and light red/pink background with a dark red "X" ?

I strongly vote against using the red color at all. IMHO having "no access" colored red is wrong, if you want the role not to have access! So it would be indicating a problem where everything is actually fine.

[adrian]

7 minutes ago, bernhard said:

17 minutes ago, gmclelland said:

 

I strongly vote against using the red color at all. IMHO having "no access" colored red is wrong, if you want the role not to have access! So it would be indicating a problem where everything is actually fine.

I think this is a good point. Maybe it really is just cross vs tick and no background colors at all?

 

11 minutes ago, bernhard said:

Oh. I also thought it would list all available permissions. 

This panel is just page permissions for the currently viewed / edited page. I don't want to get into a roles/permissions matrix. I think this is why it probably does belong as a section in the RequestInfo panel. It's not meant to be a big "all knowing" overview of permissions and roles.

[bernhard]

2 minutes ago, adrian said:

Maybe it really is just cross vs tick and no background colors at all?

I think it's good to have some color. What about the colors of the console - active = white, inactive = light blue:

3 minutes ago, adrian said:

This panel is just page permissions for the currently viewed / edited page. I don't want to get into a roles/permissions matrix. I think this is why it probably does belong as a section in the RequestInfo panel. It's not meant to be a big "all knowing" overview of permissions and roles.

Understand. Thx ? 

[adrian]

Ok, I have added this functionality to the RequestInfo panel like I suggested. This keeps things simple and always available. I got rid of all the background coloring - it's really not needed and I prefer the striped rows for clarity of info for each row. 

Current user is on the first row (and bolded to stand out) so if you're using the User Switcher panel you can quickly get all the details for that current user.

I have a few other things in the works, but will commit this shortly.

[tpr]

I liked the previous colored version where it was more obvious who can or cannot do what. I would perhaps try making the X icons 50% transparent or so to separate things better (or remove entirely?).

Another idea is that on clicking on the table would toggle the icons visibility, so eg it would load with no X icons but on click they would appear and the check icons would disappear. Or perhaps just use hover for inverting the icons' visibility so no need to use js?

How about removing the -able endings in the column headers to make it more compact? You can add the original text as a title attribute to keep them too. 

[adrian]

1 minute ago, tpr said:

I liked the previous colored version where it was more obvious who can or cannot do what. I would perhaps try making the X icons 50% transparent or so to separate things better (or remove entirely?).

Another idea is that on clicking on the table would toggle the icons visibility, so eg it would load with no X icons but on click they would appear and the check icons would disappear. Or perhaps just use hover for inverting the icons' visibility so no need to use js?

You know you've just signed up to add your magic to this don't you ? 

PM on the way if you are actually interested in giving it a go.

[tpr]

Ok but let me know which version you (including others) would prefer, if any.

[adrian]

12 minutes ago, tpr said:

Ok but let me know which version you (including others) would prefer, if any.

Honestly I don't know. I am actually pretty happy with the clean and simple I have now. I don't actually see using this for trying to get an overview of who can do what, but rather as a way to check that a certain user or role can do what I want them to be able to do. Given this, I actually think the striped rows is the most important visual distinction - find the role you're interested in and follow it across.

But you're right, let's see what others think before we do anything. I might actually just commit things shortly and those interested can test and can provide better feedback.

[bernhard]

I vote for striped rows, no red, no green, just set the X to invisible or light grey.

Checkmark means access, empty cell means no access. No warning colour but still easy to distinguish (better than without any colouring).

@adrian why don't you create a temporary branch for such updates? We could then play around and give feedback or prs. Why sending zip files around?

[adrian]

21 minutes ago, bernhard said:

Checkmark means access, empty cell means no access. No warning colour but still easy to distinguish (better than without any colouring).

Yeah, I actually think that is probably cleanest - thanks!

22 minutes ago, bernhard said:

why don't you create a temporary branch for such updates? We could then play around and give feedback or prs. Why sending zip files around?

Maybe I should - I have on occasion, but maybe I should more often!

[tpr]

3 hours ago, tpr said:

How about removing the -able endings in the column headers to make it more compact? You can add the original text as a title attribute to keep them too.

@adrian I added this line to my previous post by editing it so you may have missed it. I think the shorter column headers would be just as informative as the longer.

[adrian]

8 minutes ago, tpr said:

How about removing the -able endings in the column headers to make it more compact? You can add the original text as a title attribute to keep them too.

Sure - don't think I'll bother with the title attribute here though - it should be obvious enough. I also changed the order so the more important/relevant ones are on the left, although I am not really sure where "list" belongs ?

[szabesz]

22 hours ago, adrian said:

On 10/2/2018 at 9:15 PM, bernhard said:

Are you talking about a link to the docs or about shortcut links to the settings page of the template where the admin can adjust those permissions? The latter would be great! Maybe there could also be a section where it shows which template setting is responsible, eg:

path             | template     | active
-----------------|--------------|--------------------------------
/                | home         | yes
/foo             | basic-page   | yes
/foo/bar         | whatsoever   | no (inherited from basic-page)

The template strings could be linked to the access tab of the template settings.

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.

@LostKobrakai might not want to take his module any further, he also writes:

Quote

...I haven't used it in a while. But I haven't added the 3.0 flag for a purpose, because the module was build before the ability to assign additional permissions on a per template level was added. I'm not sure if the module does take those into account properly.

Also, your Tracy Debugger module is an all-in-one Swiss Army Knife module to support development in general, so this feature would also be welcome.

Edited October 3, 2018 by szabesz
typo

[tpr]

1 hour ago, adrian said:

although I am not really sure where "list" belongs ?

Thanks, I think it's fine now (means I'm outta ideas :))

[bernhard]

1 hour ago, adrian said:

2 hours ago, bernhard said:

Checkmark means access, empty cell means no access. No warning colour but still easy to distinguish (better than without any colouring).

Yeah, I actually think that is probably cleanest - thanks!

awesome! thx ? 

5 minutes ago, szabesz said:

@LostKobrakai might not want to take his module any further, ha also writes:

Quote

...I haven't used it in a while. But I haven't added the 3.0 flag for a purpose, because the module was build before the ability to assign additional permissions on a per template level was added. I'm not sure if the module does take those into account properly.

Also, your Tracy Debugger module is an all-in-one Swiss Army Knife module to support development in general, so this feature would also be welcome.

While I agree that it would be welcome I have to say that I haven't had a need for this module yet and will probably not have in the near future. I agree that it makes sense to integrate some modules into tracy, but I don't think it's a good idea to leave adrian alone with that effort. Even though he seems to be similar to ryan from a productivity point of view (do those two ever sleep? ?? ).

I've done a little contribution once (field code) and it was not that hard. But maybe @adrian you could write up a little tutorial to show us how we can contribute to tracy. How everything plays together, what helpers are there, what css classes you use in general (or how we can inspect all that). Something like a quickstart of tracy extension building. Maybe this could make tracy more of a teamwork than an (absolutely awesome) one-man-show?

Maybe tracy could even be built a little differently to support 3rd party modules. Just like you did recently with the admin actions module (https://processwire.com/talk/topic/14921-admin-actions/?do=findComment&comment=173496). I'm not requesting this, I'm just thinking out loud here.

 

2 hours ago, adrian said:

2 hours ago, bernhard said:

why don't you create a temporary branch for such updates? We could then play around and give feedback or prs. Why sending zip files around?

Maybe I should - I have on occasion, but maybe I should more often!

It would then also make sense to streamline the way of collaboration and have a standard workflow centralized on git.

[netcarver]

20 hours ago, bernhard said:

I strongly vote against using the red color at all. IMHO having "no access" colored red is wrong, if you want the role not to have access! So it would be indicating a problem where everything is actually fine

My vote would be not to colour the cells at all, or use a really light difference between the two because, as Bernhard already pointed out, there is no correct answer here - sometimes you want a role to have a permission - in which case the "tick" mark is correct - and sometimes you don't, in which case the "cross" is correct.

@adrian there is a "Note" colour from the diagnostics panel that might work as a possibility here.

Edited to add: just read the updates on empty cells for no-access. Even better!

[adrian]

10 hours ago, bernhard said:

But maybe @adrian you could write up a little tutorial to show us how we can contribute to tracy. How everything plays together, what helpers are there, what css classes you use in general (or how we can inspect all that). Something like a quickstart of tracy extension building. Maybe this could make tracy more of a teamwork than an (absolutely awesome) one-man-show?

I'd love some help ?

If people have ideas for other panels that would be brilliant. It's really very simple to get a panel working and what you do with it is up to you.

Maybe I'll add this to the docs site (https://adrianbj.github.io/TracyDebugger/#/) at some point, or maybe someone could do that for me, but here are the really quick basics.

• Create a new file under the panels subdirectory named to match the name of your new panel, eg: MyNewPanel.php
• In that file have a class MyNewPanel that extends BasePanel, eg:

class MyNewPanel extends BasePanel {

• Add getTab() method
  • optional isAdditionalBar() method to check if the current call to the panel is from an AJAX or Redirect debug bar. Some panels are not relevant for these bars, so you can check that and return if you wish.
  • timer() method to check how long it takes to generate this panel.
  • return a span with title tag (for mouseover of the panel icon in the debug bar) with the SVG for the icon and a label. It's up to you to assign the SVG to that $this->icon variable.

    public function getTab() {
        if(\TracyDebugger::isAdditionalBar()) {
            return;
        }

        \Tracy\Debugger::timer('myNew');

        return '
        <span title="My Panel">
            ' . $this->icon . (\TracyDebugger::getDataValue('showPanelLabels') ? ' My Panel' : '') . '
        </span>';

    }

• Add getPanel() method
  • if this panel does work with additional bars, then check for this and add the name of the bar in parentheses in the <h1> title
  • output should all be contained in a tracy-inner div
  • use generatePanelFooter to create the ms/kb values in the footer of the panel. The last parameter (optional) is for a hash link to the docs website
  • return - parent::loadResources() actually currently returns nothing but it's in the BasePanel class and may be used again at some point, so should be included in the return. The minify() method is not mandatory but I use it in some panels with a lot of embedded JS / HTML. Note that it's very rudimentary and currently is broken by inline comments in $out so be careful.

public function getPanel() {

    $isAdditionalBar = \TracyDebugger::isAdditionalBar();
    $out = '
    <h1>
        <a title="My New">
                ' . $this->icon . ' My New
        </a>' . ($isAdditionalBar ? ' ('.$isAdditionalBar.')' : '') . '
    </h1>

    $out = '<div class="tracy-inner">';
    $out .= 'whatever you want output in the panel';
    $out .= \TracyDebugger::generatePanelFooter('myNew', \Tracy\Debugger::timer('myNew'), strlen($out), 'myNew');
    $out .= '</div>';
    return parent::loadResources() . \TracyDebugger::minify($out);
}

 

You have access to these color constants from the main \TracyDebugger class:

    const COLOR_LIGHTGREY = '#999999';
    const COLOR_GREEN = '#009900';
    const COLOR_NORMAL = '#354B60';
    const COLOR_WARN = '#ff8309';
    const COLOR_ALERT = '#cd1818';

 

You can access module config settings with: 

\TracyDebugger::getDataValue('settingName');

Once the panel is built, you can add it to Tracy here:

https://github.com/adrianbj/TracyDebugger/blob/dd617b8ca8f450b8891ecacaef2b3949698fc126/TracyDebugger.module#L139-L169

That's a very rough first draft of what needs to happen. 

I think the best place to start is probably the MethodsInfoPanel.php file because it's so simple.

This process has reminded me of just how messy some things are ?

 

[bernhard]

11 minutes ago, adrian said:

SORRY - rest coming soon!!!

Cat bite? ???

[adrian]

23 minutes ago, bernhard said:

Cat bite? ???

Haha - no, errant keyboard shortcut saved the post ?

It's been "completed" now, although it really needs some work and should be moved to the docs site as I mentioned.

[adrian]

11 hours ago, szabesz said:

Also, your Tracy Debugger module is an all-in-one Swiss Army Knife module to support development in general, so this feature would also be welcome.

I would certainly welcome this functionality in Tracy, but I am not super excited on building this at the moment, but if you're feeling motivated, I am sure with the code from LK's module and the quick guide I just put together you should have a decent starting point. Of course it will need to be updated to support the new access functionality that Ryan added fairly recently.