Jump to content
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
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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Mike Rockett
      Jumplinks for ProcessWire
      Release: 1.5.56
      Composer: rockett/jumplinks
      Jumplinks is an enhanced version of the original ProcessRedirects by Antti Peisa.
      The Process module manages your permanent and temporary redirects (we'll call these "jumplinks" from now on, unless in reference to redirects from another module), useful for when you're migrating over to ProcessWire from another system/platform. Each jumplink supports wildcards, shortening the time needed to create them.
      Unlike similar modules for other platforms, wildcards in Jumplinks are much easier to work with, as Regular Expressions are not fully exposed. Instead, parameters wrapped in curly braces are used - these are described in the documentation.
      Under Development: 2.0, to be powered by FastRoute
      As of version 1.5.0, Jumplinks requires at least ProcessWire 2.6.1 to run.
      View on GitLab
      Download via the Modules Directory
      Read the docs
      Features
      The most prominent features include:
      Basic jumplinks (from one fixed route to another) Parameter-based wildcards with "Smart" equivalents Mapping Collections (for converting ID-based routes to their named-equivalents without the need to create multiple jumplinks) Destination Selectors (for finding and redirecting to pages containing legacy location information) Timed Activation (activate and/or deactivate jumplinks at specific times) 404-Monitor (for creating jumplinks based on 404 hits) Additionally, the following features may come in handy:
      Stale jumplink management Legacy domain support for slow migrations An importer (from CSV or ProcessRedirects) Feedback & Feature Requests
      I’d love to know what you think of this module. Please provide some feedback on the module as a whole, or even regarding smaller things that make it whole. Also, please feel free to submit feature requests and their use-cases.
      Note: Features requested so far have been added to the to-do list, and will be added to 2.0, and not the current dev/master branches.
      Open Source

      Jumplinks is an open-source project, and is free to use. In fact, Jumplinks will always be open-source, and will always remain free to use. Forever. If you would like to support the development of Jumplinks, please consider making a small donation via PayPal.
      Enjoy! :)
    • By BitPoet
      As threatened in Ryan's announcement for 3.0.139, I built a little module for sliding toggles as a replacement for checkboxes. Styling of the input is CSS3 only (with all the usual caveats about older browsers), no JS necessary, and may still be a bit "rough around the edges", so to speak, since I didn't have much time for testing on different devices or brushing things up enough so I'd feel comfortable pushing it to the module directory. But here's the link to the GitHub repo for now:
      InputfieldSlideToggle
      Fieldtype and Inputfield that implements smartphone-style toggles as replacement for checkbox inputs. The visualization is CSS-only, no additional JS necessary.
      Status
      Still very alpha, use with caution!
      Features / Field Settings
      Size
      You can render the toggles in four different sizes: small, medium, large and extra large.
      Off Color
      Currently, "unchecked" toggles can be displayed either in grey (default) or red.
      On Color
      "Checked" toggles can be rendered in one of these colors: blue (default), black, green, grey, orange or red.
      Screenshots

      Some examples with checkbox label


      View all Size and Color Combinations
      Small toggles Medium toggles Big toggles Extra big toggles  









    • By Orkun
      Hi Guys
      I needed to add extended functionalities for the InputfieldDatetime Module (module is from processwire version 2.7.3) because of a Request of Customer.
      So I duplicated the module and placed it under /site/modules/.
      I have added 3 new Settings to the InputfieldDatetime Module.
      1. Day Restriction - Restrict different days based on weekdays selection (e.g. saturday, sunday) - WORKING

       
      2. Time Slots - Define Time slots based on custom Integer Value (max is 60 for 1 hour) - WORKING

       
      3. Time Range Rules per Weekday - Define a minTime and MaxTime per Weekday (e.g. Opening Hours of a Restaurant) - NOT WORKING PROPERLY

       
      The Problem
      Time Slots and Day Restriction working fine so far. But the Time Range Rules per Weekday doesn't work right.
      What should happen is, that when you click on a date, it should update the minTime and maxTime of the Time Select.
      But the change on the select only happens if you select a date 2 times or when you select a date 1 time and then close the datepicker and reopen it again.
      The time select doesn't get change when you select a date 1 time and don't close the picker.
      Here is the whole extended InputfieldDatetime Module.
      The Files that I have changed:
      InputfieldDatetime.module InputfieldDatetime.js jquery-ui-timepicker-addon.js (https://trentrichardson.com/examples/timepicker/) - updated it to the newest version, because minTime and maxTime Option was only available in the new version  
      Thats the Part of the JS that is not working correctly:
      if(datetimerules && datetimerules.length){ options.onSelect = function(date, inst) { var day = $(this).datetimepicker("getDate").getDay(); day = day.toString(); var mintime = $(this).attr('data-weekday'+day+'-mintime'); var maxtime = $(this).attr('data-weekday'+day+'-maxtime'); console.log("weekday: "+day); console.log("minTime: "+mintime); console.log("maxTime: "+maxtime); var optionsAll = $(this).datetimepicker( "option", "all" ); optionsAll.minTime = mintime; optionsAll.maxTime = maxtime; $(this).datetimepicker('destroy'); $(this).datetimepicker(optionsAll); $(this).datetimepicker('refresh'); //$.datepicker._selectDate($(this).attr("id"),date); //$.datepicker._base_getDateDatepicker(); // var inst = $.datepicker._getInst($(this)); // $.datepicker._updateDatepicker(inst); /*$(this).datetimepicker('destroy'); InputfieldDatetimeDatepicker($(this), mintime, maxtime); $(this).datetimepicker('refresh'); */ // $(this).datetimepicker('option', {minTime: mintime, maxTime: maxtime}); } } Can you have a look and find out what the Problem is?
      InputfieldDatetime.zip
       
      Kind Regards
      Orkun
    • By teppo
      This module tracks changes, additions, removals etc. of public (as in "not under admin") pages of your site. Like it's name says, it doesn't attempt to be a version control system or anything like that - just a log of what's happened.
      At the moment it's still a work in progress and will most likely be a victim of many ruthless this-won't-work-let's-try-that-instead cycles, but I believe I've nailed basic functionality well enough to post it here.. so, once again, I'll be happy to hear any comments you folks can provide
      https://modules.processwire.com/modules/process-changelog/
      https://github.com/teppokoivula/ProcessChangelog
      How does it work?
      Exactly like it's (sort of) predecessor, Process Changelog actually consists of two modules: Process Changelog and Process Changelog Hooks. Hooks module exists only to serve main module by hooking into various functions within Pages class, collecting data of performed operations, refining it and keeping up a log of events in it's own custom database table (process_changelog.) Visible part is managed by Process Changelog, which provides users a (relatively) pretty view of the contents of said log table.
      How do you use it?
      When installed this module adds new page called Changelog under Admin > Setup which provides you with a table view of collected data and basic filtering tools See attached screenshots to get a general idea about what that page should look like after a while.
      For detailed installation instructions etc. see README.md.
       


    • By Gadgetto
      Status update links (inside this thread) for SnipWire development will be always posted here:
      2019-08-08
      2019-06-15
      2019-06-02
      2019-05-25
      If you are interested, you can test the current state of development:
      https://github.com/gadgetto/SnipWire
      Please note that the software is not yet intended for use in a production system (alpha version).
      If you like, you can also submit feature requests and suggestions for improvement. I also accept pull requests.
      ---- INITIAL POST FROM 2019-05-25 ----
      I wanted to let you know that I am currently working on a new ProcessWire module that fully integrates the Snipcart Shopping Cart System into ProcessWire. (this is a customer project, so I had to postpone the development of my other module GroupMailer).
      The new module SnipWire offers full integration of the Snipcart Shopping Cart System into ProcessWire.
      Here are some highlights:
      simple setup with (optional) pre-installed templates, product fields, sample products (quasi a complete shop system to get started immediately) store dashboard with all data from the snipcart system (no change to the snipcart dashboard itself required) Integrated REST API for controlling and querying snipcart data webhooks to trigger events from Snipcart (new order, new customer, etc.) multi currency support self-defined/configurable tax rates etc. Development is already well advanced and I plan to release the module in the next 2-3 months.
      I'm not sure yet if this will be a "Pro" module or if it will be made available for free.
      I would be grateful for suggestions and hints!
      (please have a look at the screenshots to get an idea what I'm talking about)
       




×
×
  • Create New...