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

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 Sebi
      I've created a small module which lets you define a timestamp after which a page should be accessible. In addition you can define a timestamp when the release should end and the page should not be accessable any more.
      Github: https://github.com/Sebiworld/PageAccessReleasetime
      Usage
      PageAccessReleasetime can be installed like every other module in ProcessWire. Check the following guide for detailed information: How-To Install or Uninstall Modules
      After that, you will find checkboxes for activating the releasetime-fields at the settings-tab of each page. You don't need to add the fields to your templates manually.
      Check e.g. the checkbox "Activate Releasetime from?" and fill in a date in the future. The page will not be accessable for your users until the given date is reached.
      If you have $config->pagefileSecure = true, the module will protect files of unreleased pages as well.
      How it works
      This module hooks into Page::viewable to prevent users to access unreleased pages:
      public function hookPageViewable($event) { $page = $event->object; $viewable = $event->return; if($viewable){ // If the page would be viewable, additionally check Releasetime and User-Permission $viewable = $this->canUserSee($page); } $event->return = $viewable; } To prevent access to the files of unreleased pages, we hook into Page::isPublic and ProcessPageView::sendFile.
      public function hookPageIsPublic($e) { $page = $e->object; if($e->return && $this->isReleaseTimeSet($page)) { $e->return = false; } } The site/assets/files/ directory of pages, which isPublic() returns false, will get a '-' as prefix. This indicates ProcessWire (with activated $config->pagefileSecure) to check the file's permissions via PHP before delivering it to the client.
      The check wether a not-public file should be accessable happens in ProcessPageView::sendFile. We throw an 404 Exception if the current user must not see the file.
      public function hookProcessPageViewSendFile($e) { $page = $e->arguments[0]; if(!$this->canUserSee($page)) { throw new Wire404Exception('File not found'); } } Additionally we hook into ProcessPageEdit::buildForm to add the PageAccessReleasetime fields to each page and move them to the settings tab.
      Limitations
      In the current version, releasetime-protected pages will appear in wire('pages')->find() queries. If you want to display a list of pages, where pages could be releasetime-protected, you should double-check with $page->viewable() wether the page can be accessed. $page->viewable() returns false, if the page is not released yet.
      If you have an idea how unreleased pages can be filtered out of ProcessWire selector queries, feel free to write an issue, comment or make a pull request!
    • By David Karich
      Thanks to the great Pro module "RepeaterMatrix" I have the possibility to create complex repeater items. With it I have created a quite powerful page builder. Many different content modules, with many more possible design options. The RepeaterMatrix module supports the cloning of items, but only within the same page. Now I often have the case that very design-intensive pages and items are created. If you want to use this module on a different page (e.g. in the same design), you have to rebuild each item manually every time.
      With this proof of concept I have created a module which adds the feature to copy a repeater item to the clipboard so that you can paste this item to another page with the same repeater field. The module has been developed very rudimentarily so far. It is currently not possible to copy nested items. There is also no check of Min/Max. You can also only copy items that have the same field on different pages. And surely you can solve all this more elegantly with AJAX. But personally I lack the deeper understanding of the repeaters. Also missing on the Javascript side are event triggers for the repeaters, which would make it easier. Like e.g. RepeaterItemInitReady or similar.
      it would be great if @ryan would implement this functionality in the core of RepeaterMatrix. I think he has better ways to implement this. Or what do you think, Ryan?
      Everybody is welcome to work on this module and improve it, if it should not be integrated into the matrix core. Therefore I put it for testing and as download on GitHub: https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDublicate
      You can best see the functionality in the screencast: 
       
    • By anderson
      Hi,
      Please take a look at this:
      https://templatemag.com/demo/Good/
      The upper nav bar, including dropdowns like "pages" and "portfolios", what do you call this whole thing? At first I guess it's called "dropdown nav bar", but seems not.
      AND of course, what's the simplest way/module to achieve this in PW?
      Thanks in advance.
    • By Sebi2020
      Hey, I'm new and I created a simple module for tagging pages because I didn't found a module for it (sadly this is not a core feature). This module is licensed under the GPL3 and cames with absolutly no warranty at all. You should test the module before using it in production environments. Currently it's an alpha release. if you like the module or have ideas for improvements feel free to post a comment. Currently this fieldtype is only compatible with the Inputfield I've created to because I haven't found  an Inputfield yet, that returns arrays from a single html input.
      Greetings Sebi2020
      FieldtypeTags.zip.asc
      InputfieldTagify.zip
      InputfieldTagify.zip.asc
      FieldtypeTags.zip
    • By psy
      Background
      I'm creating a module to integrate https://pushalert.co/ into ProcessWire. You actually don't even need a module. You could just use the "Other Websites" javascript provided by PushAlert for basic functionality, ie send a broadcast notification to all subscribers. This is essentially what all the other integrations, including WordPress, do. The WP integration installs a widget with a form enabling the admin to enter details such as title, message, etc from a blog post. It does not:
      collect any statistics within the CMS about the notification enable audience fine tuning to eg a particular subscriber or subscriber segment within WP. The admin needs to use the PA dashboard for that functionality PushAlert has a javascript and REST API. It's intended that this module will use both. https://pushalert.co/documentation 
      What my module does so far:
      associate a subscription with a user. FE user clicks a button on the website front end to subscribe and/or agrees to the browser popup to accept notifications from this site send broadcast push alerts from a page within admin It doesn't have a 'widget' but easy enough to create a fieldsetpage with the relevant fields and add that fs page to any appropriate templates, then with a hook, send the notification. Need to be careful that once published/sent, the notification is not automatically re-sent on subsequent page edits.
      Looking for help/collaboration on how best:
      to send a notification, eg from a blog post, then track the statistics. Dilemma is that the push notification must come from the admin page. Responses go to the sending page which, as it's an admin page, is restricted and will not accept the https response. This is where the other CMS integrations stop. The only json response from PushAlert is the status, eg 'success', and the notification id. There is no opportunity at this point to capture the sending page id. handle, 'once sent on page publish', do not automatically resend on future page edits Am thinking along the lines that FS Page will have a @kongondo runtime markup field https://modules.processwire.com/modules/fieldtype-runtime-markup/ to pull the stats from PushAlert. Every time an admin visits the page, the stats will update.
      Once an admin checks the 'Send notification on page publish' checkbox, a hook creates new front end page that records the 'sender page', sends the notification request to PA, which then uses that newly created frontend page, as the response endpoint. Another rook re-associates the front end page with the admin page (eg blog post), to update the stats.
      Potential use cases:
      Notify individual and/or users with a particular role of an event, eg "New work opportunity" for job seekers; new blog post published; entries now open, etc...
      Looking for help/ideas/collaboration on this module. Please let me know if you're interested and as I do, believe this would be a great addition to ProcessWire