Admin Actions

[adrian]

15 hours ago, tpr said:

I think the admin UI could be re-arranged into a table layout:

• first column: action names
• second column: description/notes
• third column: applied roles + and Edit button, that opens a modal or perhaps only unhides the role asmSelector. Alternatively you can set the asmSelect to operate in "inline" mode, I've experimented with that and it worked.

I know it would take some time, but sooner or later this has to be done

 

You like to keep me busy don't you

How's this?

That along with a few tweaks/fixes has been committed.

Don't forget to fork and contribute

[tpr]

Looks really sharp!  I'll print a screenshot and put it under the Christmas tree

One thing though. Doesn't cook coffee

[tpr]

Here are is a SCSS snippet if you would like to use inline roles (I'm not liking those big green asm items). It also enables removing roles by clicking on its label (not only on its icon), "user" icon instead trash and there's a line-through effect on hover too. You can use an online tool to make CSS from it.

Spoiler

table.adminactionsconfig {
  .Inputfield[id^="wrap_"] {
    background: transparent !important;
  }
  .InputfieldContent, label {
    padding: 0.25em 0.25em 0 !important;
    border: none !important;
    background: transparent !important;
  }
  .asmList {
    margin-top: 0.25em !important;
  }
  .asmListItem {
    padding-left: 8px !important;
    margin-right: 8px;
    display: inline-block !important;
    width: auto !important;
    font-size: 14px;
    background: transparent !important;
    border-color: transparent !important;
    color: inherit !important;
    &:hover {
      .asmListItemLabel {
        text-decoration: line-through !important;
      }
    }
    .asmListItemRemove {
      left: 0 !important;
      right: 0 !important;
      bottom: 0;
      top: 1px;
      &:not(:hover) {
        i {
          &:before {
            content: '\f007';
          }
        }
      }
    }
    i {
      margin-left: 2px;
      &:not(:hover) {
        color: #EA2262;
      }
    }
  }
}

 

 

[adrian]

Thanks @tpr - I have implemented that, although I was a little hesitant. I certainly like the look, but I was worried about the consistency of the interface compared to what we're used to with ASM Selects. Curious why you haven't done this for the roles settings in AOS?

[tpr]

Thanks! Good question - actually I haven't thought about that before your question. Perhaps because I didn't know that asmSelects can be used without the sort feature (although there's no need for that in AOS at all).

[tpr]

The latest AOS contains this tweaked role selector appearance. Thanks for the tip!

The only difference is that I use the "user" icon even on hover, I think the line-through is enough signal for the removal.

[Ivan Gretsky]

Merry Christmas, @adrian!

Want to try to use your action module in a slightly different way. I need to be able to execute actions from outside of PW (from emails). I am planning to solve this task kind of like in this module: I will have a page for each callable-from-outside action with some random security string and some options.

But I want to try to make it a little more customizable. I plan to write new actions for Admin Actions module, call them from API like you said it is possible to and pass options stored in some field of the callable-from-outside action page.

Do you see any caveats? Can you suggest a field to store options? Is there a way to turn off auto-backup feature (at least for the from-API usage or by configuration)?

[adrian]

Hi @Ivan Gretsky

I think I would store the options in a textarea in json format so you can easily convert to an array to pass to the action via the API call.

Are you planning on having the security string in the link from the email and handling the authentication in the logic on your pages? 

Currently the automatic backup can't be turned off, but I agree that this should be possible. I'll do it as a configurable option and also add an option to turn it off via an API call.

Let me know if you come across any issues once you start setting this up and I'll see what I can do to make AdminActions work as needed for you.

[Ivan Gretsky]

I did already managed to write a simple action and launch it via the API. I am currently going with a json in a textarea (but also looking at this field).

1. Mandatory backup is problem 1.
2. I had to give admin-action permission to the guest user. Not sure how dangerous is that. Is there a way to get around it?
3. I am planning to have some security string stored in a dedicated field on the callable-from-outside action page which the token input value will have to match. Is there anything else you recommend?
4. Not sure what you mean under handling authentication. Currently the script is running from the guest user.

[adrian]

Hi @Ivan Gretsky - I've added some options for controlling the automatic backup (not committed yet) and I am thinking about the guest user access for making calls to actions via the API. I am considering a couple of different options and will put together something in the next couple of days. Hope that works for your timeframe?

 

[Ivan Gretsky]

Thank you for your best-in-class support.

[adrian]

Hi @Ivan Gretsky - ok, a new version has been committed that adds a new module config setting for determining whether database backups will be automatic, optional, or disabled.

1) Automatic - database backup will happen without user intervention.

2) Optional - adds a new checkbox at the bottom of every action's "options" form before the user clicks "Execute Action". 

3) Disabled - this means no database backup will occur.

If you do want to do a backup when calling an action via the API, simply add a new item to the options array: 

'dbBackup' => true

 

I am still working on figuring out the best approach for guest access. The biggest problem I see is that adding the "admin-actions" permission to the guest role means that any logged in user can now see the Setup > Admin Actions menu, even though they don't have permission to view or execute any of the actions.

I have been playing around with adding a new helper module to handle the API calls, rather than calling the main ProcessAdminActions module directly, but there are a couple of inheritance issues I am not thrilled about, so looking into other options. Will hopefully have a good solution soon.

Please let me know if the backup side of things handles your needs on that front.

 

[adrian]

Hi everyone,

I have committed a new version that takes care of @Ivan Gretsky's issues with guest access for calling actions via the API.

The new version also includes the ability to add actions to the Setup > Admin Actions submenu which could be really handy for quick access to key actions that you use regularly. At the moment you could add them all if you want, but perhaps in the future we'll have too many to make this usable, which is why I have made these configurable.

 

See the new "In Menu" column:

[Ivan Gretsky]

Thank you @adrian! It is amazing to watch something being created with such an amazing pace by people like you and ryan. And so much to learn from. I recommend everybody to go through these guys' code to learn how you can be really powerful using ProcessWire.

Another little idea. Not sure it is necessary, but seems logical to me to separate "core" actions and those specific to the site. Like core ans site modules. I can see this module to be a base to easily create little things that would other way need their own process modules. In that case, most of the time I would use only custom actions... A filter option or a tab. What do you think?

I know, that for everybody but admin I can achieve about the same with by-action role assignment. But as I almost always login a superuser myself...

[Martijn Geerts]

Just to chime in: Fantastic Module @adrian

[adrian]

6 hours ago, Martijn Geerts said:

Just to chime in: Fantastic Module @adrian

Thanks @Martijn Geerts - glad you're finding it useful - I appreciate the feedback!

 

20 hours ago, Ivan Gretsky said:

Another little idea. Not sure it is necessary, but seems logical to me to separate "core" actions and those specific to the site. Like core ans site modules. I can see this module to be a base to easily create little things that would other way need their own process modules. In that case, most of the time I would use only custom actions... A filter option or a tab. What do you think?

Hi @Ivan Gretsky - just to clarify - are you talking about simply separating the "core" actions in the module's "action" folder from those "site specific" ones in the /site/templates/AdminActions/ folder?

I think tabs sounds like a good approach - I'll take a look at doing that. Also something else to consider is the tables filter feature of @tpr's awesome AOS module - that will make finding actions nicer once there are lots more, although to be honest sometimes I just like good old CTRL/CMD + F

 

20 hours ago, Ivan Gretsky said:

I know, that for everybody but admin I can achieve about the same with by-action role assignment. But as I almost always login a superuser myself...

Just an FYI - if you don't want certain/any core actions available, you can remove the superuser role from those actions and they won't clog up your list of actions.

[LostKobrakai]

How about letting a dedicated AdminActions.module handle all the serious work (e.g. like WireActions), so actions are also triggerable via the api? I can imagine that some actions might be useful to be run as part of a migration (shameless plug :D) and not just via the backend.

[adrian]

22 hours ago, LostKobrakai said:

How about letting a dedicated AdminActions.module handle all the serious work (e.g. like WireActions), so actions are also triggerable via the api? I can imagine that some actions might be useful to be run as part of a migration (shameless plug :D) and not just via the backend.

 

They are already triggerable via the API: 

$options = array(
   'field' => 99, 
   'sourcePage' => 1131, 
   'destinationPage' => 1132
);
$modules->get("ProcessAdminActions")->CopyFieldContentToOtherPage($options);

I did think about separating into a core AdminActions.module and then have the ProcessAdminActions.module run on top of that, but went for the self-contained approach.

Let me know if this doesn't suit your needs though and I can revisit separating them out.

[adrian]

On 1/2/2017 at 11:01 AM, Ivan Gretsky said:

Another little idea. Not sure it is necessary, but seems logical to me to separate "core" actions and those specific to the site.

Hi @Ivan Gretsky - I have implemented this - now both the modules settings and the Setup > AdminActions are split into "Site" and "Core" tabs. I haven't committed just yet. I will PM you the new version. Would appreciate it if you could test and let me know if it suits your needs and if you find any problems.

Thanks!

[adrian]

@Ivan Gretsky - I ended up doing some more tweaking on this and decided to commit it so you can get the new version from the modules directory now. Here's a screenshot of the tabs in action:

 

I have also added a new: FTP Files to Page action based on this request: 

It works with files and images and looks like this:

[kongondo]

@adrian, I know function names are case-insensitive, but maybe you could change this line  from

 $destinationPage->$fieldName->add($item->getPathName());

to...

 $destinationPage->$fieldName->add($item->getPathname());// @note: lower 'n' in getPathname

to match what's in the docs...Just me being silly.

[adrian]

Thanks @kongondo - I was PHP was strict on function name case!

I think I inadvertently copied the case of $fieldName through to the getPathname() method.

Anyway, it's fixed in the latest version - thanks for noticing and pointing it out.

[adrian]

Just added a new "Email Batcher" action, which has the following features:

• Select recipients by user role, or using a pages selector for any pages on the site
• Parsing of field tags in the body so you can do something like: Dear {first_name}
• Option to send a test email
• HTML body, with automated text only version also sent
• Special {fromEmail} and {adminUrl} tags.
• Ability to hook EmailBatcher::parseBody to apply other custom replacements

Don't forget TracyDebugger's Mail panel when testing - it will capture the outgoing emails (so they won't actually be sent):
http://processwire.com/blog/posts/introducing-tracy-debugger/#mail-panel

 

 

 

[adrian]

Just added a new "Copy Repeater Items To Other Page" action.

It lets you append or overwrite items from a repeater on one page to one on another.

[adrian]

Another quick update. Both the new "Copy Repeater Items To Other Page" and "Copy Table Field Rows To Other Page" actions now include an optional selector so you can define what repeater items / table rows will be copied.