Posted by Docc on November 10, 2008 at 6:30pm
| Project: | Storm |
| Version: | 6.x-2.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Any support for the token module coming up? so we could storm with with modules like rules?
Comments
#1
Which area would you want to use the tokens in?
#2
#3
I wonder if my issue has something to do with this, or if I'm just doing something wrong, but I'm trying to use actions to send me information when a ticket is added or an organization is updated, but my emails just have the token name in them, they don't have the actual information. So if it is node title, I get [title-raw] in my email instead of the actual title.
#4
OK.
You should generally be able to see the node title in the email as Storm uses the node module to store these. The exceptions are some types that don't have titles. Tickets and organizations have titles though so you should be able to see a title here.
I'd be keen to see a patch to expose the other Storm fields to the token module - otherwise I'll get around to it in due course.
#5
Ok, sorry, I actually found my problem and it wasn't with Storm, so I don't think my issue has anything to do with the original issue. Mine just had something to do with old rules with a new rules version, so it didn't understand the tokens I was using. I've now got all of my emails working how I want without anything extra from Storm, but, I don't know about the original poster.
Cheers,
Stephanie
#6
Just started using Drupal and installed the Storm modules. Great stuff!
Is there a way to pull the fields from Storm into an email action thru tokens yet, or am I missing something?
For example, I would like to include the Category field from a ticket.
thanks,
-amv
#7
Follow this issue. It isn't possible at the moment, but updates will be reported back here.
#8
Potential use case:
Now that the handy "Add to invoice..." links are on each timetracking, tokens could be used to modify what information is brought to the invoice item line. Example: "[storm_org] : [storm_proj] : [storm_ticket_dur] for [storm_ticket_title]" could be set in a config option, then be translated to: "ABCXYZ, Inc. : abcxyzinc.com : 4.0 hours for version 2 theme development"
I will note other suggestions for invoice UX improvements in a different issue, though
Second idea: use tokens to pre-populate invoice numbers using org prefixes, pre-populate ticket and timetracking titles with tokened starters, etc.
#9
Agree that token support would be nice. I'm sure you'll get around to it when you can. Wish I could help but I've just barely wet my feet with module developting.
Another use case:
I added a filefield on each project to upload files and it'd be nice to be able to specify where the file gets saved, such as [organization]/[project]/ to keep my file structure organized.
#10
I am currently using Notification Framework for sending out emails when a comment is posted or project / task is create / assigned.
It would be good to include some of the storm fields in the email template such as "status" and "assigned" etc.. The messaging framework uses Tokens for that.
#11
- susbcribing -
#12
sub
#13
sub
#14
Useful references:
http://drupal.org/project/support_token
http://drupalcode.org/viewvc/drupal/contributions/modules/support_token/...
#15
Attached is a patch (against 6.x.1.x.dev) for storm project token support. Using the sample rule (pasted below) a site will e-mail anyone assigned to a project when that project's node is edited. The patch reveals tokens for the following
Project status
Project Manager's title (ie the title field saved in the project node from the manager's person node)
Project Manager's uid
Project Manager's full name (ie the full name field saved in the project node from the manager's person node)
Project Manager's e-mail (ie the The e-mail from the project Manager's user record)
Project assignee(s) e-mails (a comma separate list of the e-mail from the project assignee(s) Drupal user record(s))
Project assignee(s) titles (ie the title field(s) saved in the project assignee(s) Drupal user record(s))
I debated on which e-mail to use between the Drupal user account e-mail and the person node e-mail and decided on the Drupal user account as chances are that will be the most accurate (Given that users can update it themselves without special permission).
If there are not any major issue with this I will be submitting more patches of a similar nature for Tickets and Tasks in the near future.
array ('rules' =>
array (
'rules_1' =>
array (
'#type' => 'rule',
'#set' => 'event_node_update',
'#label' => 'Send Assignees e-mail when project saved',
'#active' => 1,
'#weight' => '0',
'#categories' =>
array (
),
'#status' => 'custom',
'#conditions' =>
array (
0 =>
array (
'#type' => 'condition',
'#settings' =>
array (
'type' =>
array (
'stormproject' => 'stormproject',
),
'#argument map' =>
array (
'node' => 'node',
),
),
'#name' => 'rules_condition_content_is_type',
'#info' =>
array (
'label' => 'Updated content is Project',
'arguments' =>
array (
'node' =>
array (
'type' => 'node',
'label' => 'Content',
),
),
'module' => 'Node',
),
'#weight' => 0,
),
),
'#actions' =>
array (
0 =>
array (
'#info' =>
array (
'label' => 'Send a mail to an arbitrary mail address',
'module' => 'System',
'eval input' =>
array (
0 => 'subject',
1 => 'message',
2 => 'from',
3 => 'to',
),
),
'#name' => 'rules_action_mail',
'#settings' =>
array (
'to' => '[node:stormproject-assigned-to-email]',
'from' => '',
'subject' => 'testing',
'message' => 'you project has been edited, here\'s a link [node:node-path]',
'#eval input' =>
array (
'token_rules_input_evaluator' =>
array (
'message' =>
array (
0 => 'node',
),
'to' =>
array (
0 => 'node',
),
),
),
),
'#type' => 'action',
'#weight' => 0,
),
),
'#version' => 6003,
),
),
)
#16
Thanks for taking this forward.
A couple of comments and questions:
- Does this do anything for access controls? I'm guessing that we're saying that we only expose the token, it is up to the site admin to ensure that (s)he doesn't affect an access bypass by exposing sensitive info? Is this the principle that other modules work on?
- We could tidy the code in a couple of places - no gap between multi-line comment and top of function. Space after
//- It'd fit better with the way that we expose fields to views by having "Storm Project: Project Manager Email Address" as the token title.
Also, re taking the email address from the user account rather than the Storm person. I appreciate your logic, but this is going to give a WTF from new users that we give people an option to have an email address in the Storm Person but don't use it. Any suggestions for getting around this?
#17
I agree on the three comments i'll re-submit the patch. On the access question, yes I'm assuming it's up to the admins. That's something we could get around, but it will be very complicated as you likely know :)
on this question:
"Also, re taking the email address from the user account rather than the Storm person. I appreciate your logic, but this is going to give a WTF from new users that we give people an option to have an email address in the Storm Person but don't use it. Any suggestions for getting around this?"
I agree but don't have a great solution other then exposing both witch will be more confusing. Honestly, I think it's overkill to have both e-mail addresses and I would lean towards killing the one in stormperson as it seems slightly redundant. Though maybe an alternative is to write the logic to use the e-mails like this.
1.) If storm person e-mail is null take the Drupal e-mail
2.) If neither null defer to Drupal as users are more likely to maintain those
3.) if no Drupal account take storm e-mail
#18
Sounds like we agree.
How about this for the logic:
- If there is a Drupal account linked to the Storm person, use the email from the Drupal account
- If there is not a Drupal account linked, but there is an email in the Storm person record
- If both fail (no linked account, no email in Storm person record), token fails - I don't know if there is a specific way to do this apart from returning NULL.
I think that's pretty much what you were saying, but I got a bit confused with the bullets!
#19
Okay this should takes care of everything but the access issue.
I punted the decision of which e-mail to use to the stormperson module, as it seemed a better place for that function, using the logic laid out in #17 and #18
#20
Just a few things
- We should have a doxygen comment explaining the new function in stormperson
- One line comments could have capital letters and a space after the //
- If statements should have a space between the if and the open bracket
- What happens if the Storm person module is not enabled? I think it may cause an error when trying to call the new function if that's the case. Perhaps that token should be set to return null if the Storm person
#21
That makes sense, besides if stormperson isn't enabled you shouldn't have managers or assignees anyway. Fixed the minor formatting issues, patch attached.
Question: should we descend into organizations to get the users related to organizations if a team record points to an organization? I'm thinking yes, which makes me want to add a function to stormorganization to get a list of people related to the org.
#22
slight change in the doxygen comment
#23
Minor code style and comment edits.
#24
Committed to 2.x.
Putting back to active as @jalama mentioned patches for the other Storm modules.
#25
should I add them here or in their own issues? Maybe change the name of this issue to "Token support- Storm Project"
#26
Complete patch for all the fields in project. I added the following in this patch. For the Date end and Date begin fields I ran them through format_date() for which I took the site default timezone using the variable get function.
1.) Project Category
2.) Project Priority
3.) Duration Unit
4.) Duration
5.) Date Begin
6.) Date End
7.) Billable
8.) Billed
9.) Price
10.) Price Mode
11.) Organization Nid
12.) Organization Title
#27
small typo in one of the stormproject_token_values variables
#28
Okay I just caught onto the commit/ switch to the 2.x branch in #24. Sorry I'm a little slow been away for a couple weeks. Regardless this is my final patch today, this time against the 2.x branch. It includes Ticket and Task so my question in #25 can be ignored.
#29
#30
Only issue I can find is the trailing whitespace - on numerous rows. Would it be possible to check through and remove those?
#31
sans white space one final patch :)
#32
Committed to 2.x.
Feature so will not be back ported to 1.x.
Marking this issue as fixed now, we can open new issues for any other tokens required.
#33
Automatically closed -- issue fixed for 2 weeks with no activity.