The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.As discussed with Berdir in IRC, I'd like to do the following:
A. On the "add points" page, create fields for the entity type and ID. This way, a site administrator could actually refer to a specific node (or even a Private Message) in a manual points award. The "Reason" field would automatically link to the appropriate node or other entity.
B. On the "add points" page, change the "operation" field to be an autocomplete field that suggests defined operations. So the administrator could choose a defined operation or else type his own unique manual one. Ideally, the autocomplete would search both the operation name and the description (but return just the operation that matches).
WIth this feature, the administrator could mimic a Userpoints Node and Comments award just by selecting the operation name defined by that module. This would allow advanced Rules workflows in which certain Rules actions would only fire on certain defined operations.
--Ben
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | userpoints_entity_operation_autocomplete_form4.patch | 16.62 KB | berdir |
| #9 | userpoints_entity_operation_autocomplete_form3.patch | 16.41 KB | berdir |
| #6 | userpoints_entity_operation_autocomplete_form2.patch | 13.81 KB | berdir |
| #1 | userpoints_entity_operation_autocomplete_form.patch | 8.89 KB | berdir |
Comments
Comment #1
berdirA first, working patch.
- Operation is now a autocomplete field, added a new 'admin description' property to the info hook which is used here if existing. Also added documentation for that hook. Note that the field searches operation string, description and admin description but only displays either the admin description or the operation (it always inserts the operation). Space is extremely limited there... Currently, only the 'expiry' operation provides a admin description.
- Added entity type (select) and id (textfield). Untested other than that it shows up in the form.
Thinking about vertical_tabifying that form to make it shorter. No idea how to group it though, except that entity + reference would make up up a "References" tab.
Comment #2
BenK commentedI'm working on testing this patch, but wanted to get back to you first about creating vertical tabs (which is a good idea). How about four tabs in the following order (tabs are shown in all caps):
GENERAL
Username
Points
Category
STATUS
Moderated
Expiration Date
REASON
Operation
Description
REFERENCES
Entity Type and ID
Reference
One alternate possibility would be to have only three vertical tabs and get rid of the "Status" tab. The fields in that tab would be included as part of the "General" tab.
Thoughts?
--Ben
Comment #3
berdirI guess we'll simply have to try this out to see how it looks for real ;) Like your idea though.
Only thing I'm wondering about if we should only move additional settings into a vertical tabs fieldset and leave the general stuff outside. Similiar to the node (type) forms.
Comment #4
BenK commentedYeah, I like the idea of putting the General category outside the vertical tabs. It would give us a nice short form visible by default (just user, points, and category) with more specific control if necessary.
--Ben
Comment #5
BenK commentedJust finished testing the current patch. The basic functionality is working well. Here's my to-do list:
A. If you use the new entity type and ID field from the "add points" form it's working great. But if you later edit the points transaction, then the type select list and entity id appears blank (even though it's not). Changing other fields and saving won't cause the entity type and id to be lost... it just doesn't appear to the person editing like there is any values in the entity type and ID fields.
B. If you try to reference an entity ID that does not exist (either on the "add points" form or the "edit transaction" page, you get the following error:
It's pretty easy to reference an incorrect entity id by mistake so there should be some type of handling for this.
C. The new autocomplete field on the operation works well, but I think it's too small. Because we're including descriptions in here now, it needs to be bigger so that we can read the entire description in the autocomplete.
D. Is there any way that tokens can be used in the description field on the "add points" form? Now that we can reference an entity (and the description will link to it), it would be handy, for instance, to be able to use a token for the node title.
--Ben
Comment #6
berdir- Added vertical tabs. Also moved Timestamp (not visible by default because of a setting) and moderator fields into Status. Revamped entity fields a bit to work inside vertical tabs. It's a bit tricky now because only the title of the entity_type field is now displayed but the description is on the entity_id field so that it is shown below both fields. Not sure how well this works for screenreaders...
A. Forgot the #default_value fields. Works now.
B. Catched the exception in userpoints_rules.module, this should work now.
C. Made it wider.
D. Maybe, but let's handle this in a follow issue. The problem is that we can't provide useful token suggestions because that depends on the selected entity_type. Unless we update it dynamically with AJAX, no idea if that would work ;)
Comment #7
berdirComment #8
BenK commentedJust finished testing the patch. The vertical tabs look really great. It totally transformed the whole look and feel of the add points form. :-)
Here's my report on the prior to-do list:
A. This is fixed.
B. I'm still getting this error. And I've confirmed the culprit is the Rules integration sub-module because if I disable the module the problem goes away.
C. Looks good. This is fixed.
D. Sure, let's postpone for now.
And here's some other stuff I noticed:
E. For the operation field, the description text currently reads: "The operation type for this transaction (default is admin). Any value is valid but using an existing operation has the benefit of translated reason." Change this to: "The operation type for this transaction (default is admin). Any value is valid but using a defined operation will cause an auto-generated description (specific to the chosen operation) to be included. This description can be translated into multiple languages."
F. In the "Reference" vertical tab, switch the order of fields so that "Entity" is above "Reference".
G. Should we change the label of the "Entity" field to be "Linked entity"? Just an idea.
H. Also, since the "Reference" field now has the same name as the "Reference" vertical tab, how about we change the label on the "Reference" field to be one of the following:
"Reference tag" (probably my top choice)
"Internal reference tag"
"Internal Reference"
"Reference for internal tracking"
"Internal reference code"
"Internal reference data"
"Internal reference string"
"Admin reference"
--Ben
Comment #9
berdirB. I think I got it this time. Wrapped the wrong block in an exception It's still not perfect, though, need to discuss a few things with fago when I catch him in IRC...
Comment #10
berdirSubmitted too early.
E-H: Changed, as discussed.
Comment #11
berdirComment #12
BenK commentedHey, this patch is really looking good. The error described in B. now seems fixed. All of the changes to the add/edit form look great. And the workflow is very logical with the vertical tabs. So unless you need to make some additional changes to B. suggested by fago, this is RTBC.
Nice job!
--Ben
Comment #13
berdirCommited, thanks for testing!
Will try to talk with fago about this, the current solution is already better than it was before, so it's not blocked on that.