Under what circumstances are the triggers best used.
How does one go about seeing the Trigger in action?
[quote]Under what circumstances are the triggers best used.
[right][post=“8785”]<{POST_SNAPBACK}>[/post][/right][/quote]
Triggers are used for lots of different circumstances: Essentially they allow for automated processing based on events within Matrix. For example, if a user uploads an image in a particular location, you can use a trigger to automatically create image varieties (i.e. identical images in different resolutions). Or, you could use triggers to automatically set Up for Review status on an asset when it goes live, to enforce content review policies for your organisation.
The best way to see a trigger in action is to configure one. 
I recommend the Up for Review trigger, because its pretty easy to setup and see in operation. Essentially, you configure the Trigger to work on a particular asset type created in a particular location. The trigger event is a Status Change to Live. The trigger action is “Add Future Status” of Up for Review with a period set (say, 6 months).
Then, when you set an asset in the specified location of the specified type live, it’ll automatically get an Future Status Change of Up for Review in the period specified.
Hmm… lots of specifics there!
Yeah, the "up for review" one is useful…and a direct use for it is enforcing password changes on users every x months. When an asset goes live (event) and is of type 'user' (condition), set the future status to "up for review" in x months (action).
Expanding on Nathan's example – setting a User asset Up for Review forces the user to change their password on next login. Note that this does NOT work for LDAP-based user accounts.
created an "Up for Review" Trigger. But can't see it in action.
What am I missing?
logged in and logged back again. it's a sytem admin account not LDAP.
still did not remind me to change password.
[quote]logged in and logged back again. it’s a sytem admin account not LDAP.
still did not remind me to change password.
[right][post=“8790”]<{POST_SNAPBACK}>[/post][/right][/quote]
The asset has to be in the Up for Review state to force a password change: The trigger is just going to get the Cron Manager to set this state on the asset at some future date and time. You need to ensure that your Cron Manager is running for a Future Status change to occur.
i just setup the asset to "Up for review" 6 months. what area of cron mgr will indicate it is setup for future date and time.
does this reminding of password expiry happens from the admin (this is where i am looking at) ?
If you want an easy trigger that doesnt require the cron manager, set this up:
event = asset created
condition = tree location (pick a point in the tree)
action = status change (to live)
When you create asset in the part of the tree you selected in the condition, they will be made live automatically (assuming no workflow is applied).
Ensure you mark the trigger as ACTIVE and that you also enable the trigger manager (details screen of the trigger manager asset).
the way you specified works. I was just trying to figure out the login that's it.
is there a way i can figure out what's going wrong. how does it prompt?
how do i get an indication on the "password expiry"
- Is the above too hard to achieve.
- Is it possible to develop a user defined trigger for instance,
when a status changes, or on a particular event, certain users
should be stopped to delete/ insert/ update records from the
database.
- No. When a user account is in the Up for Review state, you'll automatically get a Change Password screen. This occurs automatically and requires no configuration. However, the user asset must be in Up for Review state. If its only set to change to Up for Review in 6 months, then you may have to wait a while.
- There is no trigger action currently that disables access to the Administration Interface like you describe.
[quote]There is no trigger action currently that disables access to the Administration Interface like you describe.
[right][post=“8807”]<{POST_SNAPBACK}>[/post][/right][/quote]A trigger which sets the users’ status to “under construction” would deny them access to logging in (both front-end and admin interfaces), forcing them to be a public user…which may be what you want. It’s not disabling access to the database, but it’s certainly preventing them from adding / removing content or reconfiguring anything.
I’m not sure what event you would use to trigger this though. There’s not really an event which warrants someone having their rights revoked :P.
The thread is about an introduction to triggers. Please do not go into discussions of a particular trigger implementation.
MR3: Please set up a trigger recommended by Greg a few posts above (setting asset to Live). This will show you what triggers do. Do not concern yourself with the user example as it is not that simple and cannot be tested immediately.