I've heard its possible to change the status of an asset via the URL, is this true and how can it be done?
Basically I'm working on an authoring interface and I want a "Remove" or "Delete" button which immediately changes an assets status to Archived. Making this interface idiot proof is quite a challenge!
This functionality can be achieved using a trigger
. event - Simple Edit Accessed (3.12 or above)
. condition - URL matches (3.12 or above)
. action - Set Status
You may then create a button on simple edit, with the following query string "?archived=1". On the trigger condition, set URL to match pattern "archived=1" and action to set asset status to Archived.
You can also add in status check, asset type check to make the trigger more robust.
Keep in mind, as Greg has pointed out previously, misuse of triggers (especially the Asset Accessed event) can affect the performance of your system.
I hadn't considered a triggered approach, but I'd prefer not to use this method if there are already url keywords to do the job. In this case the trigger would have to run off Asset Accessed which is not ideal especially as it would be for assets sitewide.
Then again we have functionality we have to provide so system performance may have to be the trade off.
thanks.
Triggers are not that bad. There's a misconception that adding a single trigger will dramatically reduce the performance of the system. They were introduced so that advanced functionality can be configured without custom development and they're not totally inefficient. Yes, a lot of loose triggers without proper conditions will affect your system but there's no need to be afraid to use the triggers at all.
The functionality you're talking about is best achieved using triggers. Particularly, if you choose 'Simple Edit Accessed' event, not 'Asset Accessed', it will not be fired on every front-end access, but will be trickier to configure.
Unfortunately where I need to use is is not actually within simple edit so the simple edit accessed trigger wouldn't work, so I want to make sure the trigger is not going to be an overhead.
But I would still prefer a non trigger solution as we need multiple editing interfaces for various business clients within the department with different options for creating/editing/maintaining different asset types. So as much as possible all configurable elements are contained under a node for each area. That way I can clone the node tree for a new client and configure elements that they want done differently (odds are we'll have one small group who want to see archived assets that are in the middle of the site so balancing triggers would become tricky).
cheers
steve
I think a JavaScript solution may be the only option.
You could create a button, which onClick changes the status to Archived then submits Details Screen of the form.
Alternatively, you could move assets to a "Deleted" or "Archived" folder from the frontend using a Link Manager Page, but I doubt you could come up with a one-click solution.
[quote]But I would still prefer a non trigger solution as we need multiple editing interfaces for various business clients within the department with different options for creating/editing/maintaining different asset types.
[right][post=“15392”]<{POST_SNAPBACK}>[/post][/right][/quote]
Keep in mind that Layouts are system-wide, so that once you configure a layout for an asset type for simple edit, it will be applied across the entire system. You can’t customise layouts for particular sections of your system.
Triggers are still your best option here. The trigger would look for the URL as specified and then perform the status change as requested. There is no other mechanism that can do a status change.
You will only experience a performance hit from the triggers if you have many triggers all listening to the 'Asset Accessed' event. If there's only a handful of triggers for this event, all with tight conditions, you will hardly notice the difference.
Triggers + Paint Layouts = Magic
[quote]Triggers + Paint Layouts = Magic
[right][post=“15407”]<{POST_SNAPBACK}>[/post][/right][/quote]
Yes, they really are. 
Paint layouts I haven't had time to experiment with yet (time is a bit of a luxury
With the simple edit screens being global I've gotten around that by modularising the components into individual divs and then using user group permissions. Nobody will be using the /_edit urls, they will either be on the publishing team (in which case they all work in /_admin) and for the general end users who need an interface they will get this modular one we are making.
cheers
The rule of thumb I use in creating a trigger is - how much am I going to cause Matrix to have to read through in order to process my request? - and how can I narrow this down to something very specific?
I'm no longer afraid of using triggers, having created a few disasters and learnt from the mistake (triggering future status on a large site prior to 3.12 = bad XD) but narrowing things down at the start to a root node always helps.
Triggering to clear the cache on Asset Status changed to Live has made us best friends of our editors, who previously had to wait several hours or use _nocache.
I'd like to explore the 'delete' button approach - although we don't usually give our users permission to do such things ;). Like you we've got a custom interface so that editors don't have to use _edit to access their pages.
We're also using 3.10 so we don't have the Simple Edit Accessed or URL matches condition. As an alternative, I've used a trigger is to set everything that has Asset Status changed to Archived in one particular area of the site to be linked to Trash as a new parent in 5 min time. We know we don't want to keep these assets if deleted, and there are over 1000 in the folder, so combing through to find them in the admin interface is cumbersome.
I also use one to send an email to our metadata team when a new page is created in a particular area, giving them its url, asset ID and asset name in the email.
Could basic use of Paint Layouts + Triggers be covered in the proposed Triggers manual? Something I'm yet to explore but sounds like fun.
We've got the asset accessed & URL trigger working fine for standard pages but we've hit a snag with PDF files.
One trigger takes an asset from Live to Under Construction (we use it as a Remove option for approvers to take down a live asset) and the other is a trigger for taking an asset from Under Construction to Archived (our Delete option for authors…we'll be looking at expanding this to link to trash or deleting out of date archived assets via the database).
The editing interface has an "Editing Tools" area with a small set of simple buttons for Authors and Approvers. When someone clicks on either the Delete or Remove buttons a javascript alert opens asking to confirm the action, when they click Yes in the alert opens a tiny window using the asset with our URL value the triggers look for (which triggers the trigger), the javascript then closes the small window and then refreshes the portion of the interface we have provided. The interface uses asset listers and does not display archived or under construction (depending on author/approver group), the result is the item just Removed or Deleted vanishes from the listing for the user. Basically you click on delete, get prompted if you are certain, then its gone…thats the way the end user should experience it.
With Standard Pages both triggers work perfectly but when the asset is a PDF File instead the Live to Under Construction trigger fails to run (the Under Construction to Archived works). Its the same triggers that the standard pages work with and same code for the buttons etc. But we can't figure out why only one of the triggers is failing with the PDFs.
Could this be a bug wtih trigger handling of Pages vs Files?
[quote]Could this be a bug wtih trigger handling of Pages vs Files?
[right][post=“15576”]<{POST_SNAPBACK}>[/post][/right][/quote]
Its not a bug – its how File-based assets are handled by Matrix when they’re Live with Public Read permission. At this point, the asset gets a /__data URL which means it can be served directly by Apache – in fact, Matrix never sees requests to those files any more.
You would have to build a specific interface for File-based assets that uses URLs in the format of http://www.domain.com/_triggerKeyword?limbo_assetid=XXX where XXX is the asset ID of the File-based asset itself.
ah, of course. that keeps tripping me up.
thanks