Tokenauth's configurable UI is awkard, occupies too much mental real-estate for what it does, is intended to facilitate very awkward end-user steps to make it work, and complicates Internationalization.
Remove all present UI. Use tricks like #990468: Setting to always add token to links to consistently present the user's own tokenauth tokens as part of the URL whenever they see it so simple copy-and-paste will get them the access they need from bookmarks, RSS readers, and so on.
Other modules (or simple content creation) might add a site-specific help text.
Move the access token reset to the user edit page. Remove all other user-facing UI.
For whatever reason, I personally dislike the dedicated tab for Token Authentication. It's such a specific functionality to get a whole "tab", and it means so little without the additional context of easily seeing what it's supposed to do.
What if we put it directly on the user profile page?
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | tokenauth-notab-extra-fields.patch | 3.6 KB | john franklin |
| tokenauth_on_profile.png | 60.97 KB | Grayside |
Comments
Comment #1
andrewbenkard commentedHm, I am sympathetic to your POV on this, but offer my 2c in contrast.
My use case involves providing a "side door" into a private intranet for users who have not yet registered. I use a token from a generic user whose XYZ role has certain content permissions. The [minor] trouble for me is that other users in the XYZ role have access to their token via the User page, when they don't need it and typically don't understand what it's for.
So in a perfect world, I would have the ability to suppress display of the token from the user page. Except admins would be able to see it.
Comment #2
Grayside commentedInteresting. That doesn't seem to directly cover which of the UI's is better, but does point to a separation of permission between "access tokenauth" and, say, "view tokenauth token".
Comment #3
andrewbenkard commentedThat would be great! (End of thread hijack. )
As for your tab vs. inline issue, I have a slight preference for the tab. Token auth seems a tricky thing for most users to understand, conceptually and how to put it in practice. If the token is right there under profile info in the View tab, the typical user might think it's important and they have to do something with it. Or they will ask the admin what it is. If the token is seen in a separate tab, then the user has at least made a decision by clicking to see what this new thing is -- and thus mentally keep the function separate from their profile data.
Comment #4
Taxoman commentedYes, such a view permission would be very useful.
It is definitely not suitable for all sites to be "forced" to display such information on the user page, regardless of on the main tab or in its own tab.
I also think it should be possible to use for example Display Suite to decide if the Token Auth info should be in its own tab or not. By that, you would also have the permissions options built into the new http://drupal.org/project/DS, for viewing each such tab.
Comment #5
SeanBannister commentedYeah the ability to customize this would be great, for example we have a use case where we don't want to display this info to end users as we're implementing it in our own way and the user doesn't need to know about it.
Comment #6
Grayside commentedAfter a lot of thought, I'm thinking the direction is to drop the UI almost entirely, have a simple bit of UI just for resetting the token inside user settings page, and otherwise automate tokenauth URLs such that users never need specially crafted instructions. This will be something for a 2.x branch.
Updating the summary.
Comment #6.0
Grayside commentedIssue summary, direction pivot.
Comment #7
Grayside commentedDespite what I've said, here is the patch I was working on for the original post. Never say never, and never
git reset --hard HEADwithout a backup...Comment #7.0
Grayside commentedAdjust image size.
Comment #8
john franklin commentedPatch in #7 doesn't add the field right, nor does it remove the tab. Here is an updated patch.
Comment #9
guypaddock commentedWouldn't the best solution be to split the module? Move the UI components into an optional separate module, keeping the API portion in the main module?
Then site builders who want to expose the UI can, while developers who do not don't have to.