adrian

Tracy Debugger

Recommended Posts

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 🙂

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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!

  • Like 1

Share this post


Link to post
Share on other sites
27 minutes ago, adrian said:

image.png.472dea523fdfa82e7c9263932cc13e0e.png

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...

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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:

mWqULxX.png

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 🙂 

  • Like 1

Share this post


Link to post
Share on other sites

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.

image.thumb.png.78ef5ca7cde0fc018c53bfd155181633.png

  • Like 2

Share this post


Link to post
Share on other sites

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. 

  • Like 2

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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!

image.png.b63a3cf93f0d6289ba01699041eb4979.png

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!

  • Thanks 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 ?

image.png.22522999f1daeb4c5b77af7925a0a81d.png

  • Like 3

Share this post


Link to post
Share on other sites
Posted (edited)
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 by szabesz
typo
  • Like 1

Share this post


Link to post
Share on other sites
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 :))

  • Like 1

Share this post


Link to post
Share on other sites
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!

image.png.b63a3cf93f0d6289ba01699041eb4979.png

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.

  • Like 1

Share this post


Link to post
Share on other sites
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!

  • Like 1

Share this post


Link to post
Share on other sites
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 🙂

 

  • Like 3

Share this post


Link to post
Share on other sites
11 minutes ago, adrian said:

SORRY - rest coming soon!!!

Cat bite? 😱😜😁

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

  • Like 2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Robin S
      Another little admin helper module...
      Template Field Widths
      Adds a "Field widths" field to Edit Template that allows you to quickly set the widths of inputfields in the template.

      Why?
      When setting up a new template or trying out different field layouts I find it a bit slow and tedious to have to open each field individually in a modal just to set the width. This module speeds up the process.
      Installation
      Install the Template Field Widths module.
      Config options
      You can set the default presentation of the "Field widths" field to collapsed or open. You can choose Name or Label as the primary identifier shown for the field. The unchosen alternative will become the title attribute shown on hover. You can choose to show the original field width next to the template context field width.  
      https://github.com/Toutouwai/TemplateFieldWidths
      https://modules.processwire.com/modules/template-field-widths/
    • By horst
      Croppable Image 3
      for PW 3.0.20+
      Module Version 1.1.16
      Sponsored by http://dreikon.de/, many thanks Timo & Niko!
      You can get it in the modules directory!
      Please refer to the readme on github for instructions.
       
      -------------------------------------------------------------------------
       
      Updating from prior versions:
       
      Updating from Croppable Image 3 with versions prior to 1.1.7, please do this as a one time step:
      In the PW Admin, go to side -> modules -> new, use "install via ClassName" and use CroppableImage3 for the Module Class Name. This will update your existing CroppableImage3 module sub directory, even if it is called a new install. After that, the module will be recogniced by the PW updater module, what makes it a lot easier on further updates.
      -------------------------------------------------------------------------
       
      For updating from the legacy Thumbnail / CropImage to CroppableImage3 read on here.
       
      -------------------------------------------------------------------------
       
    • By MoritzLost
      UPDATE: I have published a stable version of this module!
      Discussion thread:
      Github: https://github.com/MoritzLost/TextformatterPageTitleLinks
      ---
      Hello there,
      I'm working on a tiny textformatter module that searches the text for titles of other pages on your site and creates hyperlinks to them. I'm not sure if something like this exists already, but I haven't found anything in the module directory, so I wrote my own solution 🙂
      It's not properly tested yet and is still missing some functionality I would like to implement, so at the moment it should be considered in BETA. Features include limiting the pages that will get searched by template, and adding a custom CSS class to the generated hyperlinks. As I'm writing this I noticed that it will probably include unpublished and hidden pages at the moment, so yeah ... it's still in development alright 😅
      You can download the module from Github:
      https://github.com/MoritzLost/TextformatterPageTitleLinks
      There's some more information in the readme as well.
      Anyway, let me know what you think! I'm happy about any feedback, possible improvements or ideas on how to improve the module. Cheers.
    • By blad
      Hi guys!
      I just uploaded a module to explore files based on elFinder. By default it will show the "Files" folder.
      Screenshots:

      Video:
       
      To do:
       More options To fix:
       The function of rotating or scaling an image fails  Image editors V 1.01 (view issue)
      Fixed the bug working with the Multi-Language support ( translation of folders ). Fixed the name of elfinder.en  Github:
      https://github.com/LuisSantiago/ProcessElFinder/
      I hope you like it.
    • By BitPoet
      I'm really in love with FormBuilder, but the one thing missing to match all my end users' expectations were repeatable field groups. Think repeaters, in ProcessWire terms. Our primary application of PW is our corporate intranet, so "lines" of fields are quite common in the forms I build. We have all kinds of request forms where the information for a varying number of colleagues needs to be entered (from meal order to flight booking request) and where it is simply impractical to send a form for each, and I don't want to clutter my forms with multiple instances of fields that may only get used ten percent of the time.
      That's why I started to build FormBuilderMultiplier (link to GitHub).
      What it does:
      Adds an option to make a regular Fieldgroup repeatable Lets you limit the number of instances of a Fieldgroup on the form Adds an "Add row" button the form that adds another instance of the Fieldgroup's fields Adds a counter suffix at the end of every affected field's label Stores the entered values just like regular fields Makes the entered values available in preview and email notifications Supports most text based fields, textareas and selects (really, I haven't had enough time to test all the available choices yet) What it doesn't do (yet):
      Support saving to ProcessWire pages (i.e. real Repeaters) I haven't tested all the validation stuff, Date/Time inputs etc. yet, but since I'm utterly swamped with other stuff at work, I didn't want to wait until I have it polished. Any feedback is welcome. There might also be some issues with different output frameworks that I haven't encountered yet. The forms I work with mostly use UIKit.
      Status:
      Still alpha, so test well before using it in the field.
      Known issues:
      When rows are added, the form's iframe needs to be resized, which isn't completely clean yet.
      How it works:
      The Fieldgroup settings are added through regular hooks, as is the logic that adds the necessary field copies for processing the form and displaying previews.
      "Multiplied" field instances are suffixed with _NUM, where NUM is an incremental integer starting from 1. So if you have add two fields named "surname" and "givenname" to a fieldgroup and check the "multiply" checkbox, the form will initially have "surname_1" and "givenname_1" field (I'm still considering changing that to make the risk to shoot oneself into the foot by having a regular "surname_1" field somewhere else in the form less likely).
      When a "row" is added, the first row is cloned through JS and the counter in the fields' IDs, names and "for" attributes as well as the counter in the label are incremented before appending the copies to the Fieldset container in the form.
      To keep backend and frontend in sync, a hidden field named [name of the fieldset]__multiplier_rows is added to the form. Both the backend and the frontend script use this to store and retrieve the number of "rows".
      ToDo:
      Naturally, add the option to store the data in real repeaters when saving to pages. Do a lot of testing (and likely fixing). Make a few things (like the "Add row" button label etc.) configurable in field(set) context. Add a smooth API to retrieve the multiplied values as WireArrays. The mandatory moving screenshot: