#7594 closed enhancement (fixed)
[Patch] Populate username fields using session info
Reported by: | Ryan J Ollos | Owned by: | osimons |
---|---|---|---|
Priority: | normal | Component: | FullBlogPlugin |
Severity: | normal | Keywords: | |
Cc: | Trac Release: | 0.11 |
Description
When a user has a valid session (created by entering name and email in the preferences panel), the ticket's reporter field is populated with the user's name and email in the format: name <email>.
It would be nice if the same functionality existed for populating the blog post's Post Author field, and the blog comment's Your email or username: field. The latter is probably of more practical use because anonymous comments are probably commonly allowed, but I imagine a blog post typically requires an account.
That might bring up another feature to implement (assuming this can't be done already) ... an option to only allow comments when a user has a valid session key. This is done, for example, with the VotePlugin.
Attachments (1)
Change History (13)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
Summary: | Populate username fields using session info → [Patch] Populate username fields using session info |
---|
A colleague and me hacked up a patch that does this. Works fine for us.
Changed 13 years ago by
Attachment: | 0001-Display-author-name-instead-of-account-name.patch.zip added |
---|
comment:3 Changed 13 years ago by
comment:4 Changed 13 years ago by
Eh, there's a little issue still. The author name is not used when creating a new post and previewing a new post or comment.
comment:5 Changed 13 years ago by
Thanks for the patch. It is somewhat more elaborate than what I had expected... I had just imagined a small lookup at the template level, with minor changes going from this:
req.authname
to
req.session.get('name') or req.authname
It should be no more than a few instances of this in the fullblog_edit.html
template, and then whatever is entered there stays with the post anyway - regardless of where it is initially fetched.
comment:6 Changed 13 years ago by
(And same treatment to the relevant part in fullblog_view.html
where adding comments of course).
So the patch would just look like this to make it somewhat similar to the treatment of usernames in Ticket system:
-
0.11/tracfullblog/templates/fullblog_edit.html
a b 92 92 <label for="blog-author">Post Author:</label><br /> 93 93 <input id="blog-author" type="text" 94 94 name="author" size="40" 95 value="${defined('blog_edit') and blog_edit.author or req.authname}" /> 95 value="${(defined('blog_edit') and blog_edit.author) 96 or (req.session.get('name') or req.authname)}" /> 96 97 </div> 97 98 <div class="field"> 98 99 <label for="blog-categories">Categories (space separated):</label><br /> -
0.11/tracfullblog/templates/fullblog_view.html
a b 113 113 <br /> 114 114 <input id="author" type="text" 115 115 name="author" size="30" 116 value="${defined('blog_comment') and blog_comment.author or req.authname}" /> 116 value="${(defined('blog_comment') and blog_comment.author) 117 or (req.session.get('name') or req.authname)}" /> 117 118 </div> 118 119 </py:if> 119 120 <div class="buttons">
For commenting, I could even consider dropping the check for anonymous
so that the comment author field is always displayed. Then the same logic would be used and made visible to the author - and even allowing changing if so desired.
Then I may even consider this logic for name suggestion:
req.session.get('name') or req.session.get('email') or req.authname
comment:7 Changed 13 years ago by
Blame the size of the changes on our sorely missing Trac knowledge.
Would your suggestion also work for existing posts and comments? Ours does, BTW. FWIW, ours also lets people retro-actively change their "real" name ;-)
comment:8 Changed 13 years ago by
No, like all the other modules in Trac it will not link to some user dimension that in effect can change history. What is entered stays as-is for posts and comments - just like they do in wiki and ticket and other modules/plugins in Trac.
So, I won't be adding a user dimension - at least as long as no such dimension & API exists in Trac itself.
comment:9 Changed 13 years ago by
OK, I see but I've also come to realize that what we wanted is subtly different from the original #description. We want to use the FullBlogPlugin for a low-barrier blog site in a medium sized company (about 400 people). User account data (account name, display name and email address) come from an Active Directory server and cannot be modified by the user. Posts and comments require the user to be authenticated.
In this setup, entering any of the author info is unnecessary. We have even disabled the input field for that, IIRC. We want to submit the blog posts by account name (req.authname
) to avoid the possibility of attributing posts to the wrong person in the not that unlikely case we have people with the same display name.
In that situation, you end up with a patch like the one we attached because it only changes the MVC View part. Your suggested changes would modify the MVC Controller part and would leave one guessing at the interpretation of when ended up in the database). Depending on one's goal, either approach has its pros and cons, I guess.
comment:11 Changed 8 years ago by
There are some issues with r14773:
- For an authenticated user, before the change the authname was stored in the
author
column, now the user fullname is stored in theauthor
column of the database. This makes posts before/after the change be associated with different authors. Theversion_author
before and after the change is the authname. - For an authenticated user with a fullname set in preferences, the add comment form uses the authname, which is probably preferable, but inconsistent with the create/edit post form after r14773.
Trac consistently stores the authname in the database rather than the fullname. It will probably be better to follow that pattern.
In Trac we use Chrome.authorinfo
to render an author, and a fullname will be shown when [trac]
show_full_names
is true for Trac 1.2+. This could be used in the dl.metainfo
to render the author's fullname. It could use used anywhere an author name is rendered.
Chrome.authorinfo is available in Trac 0.12 and later.
+1
We're using account info from our Active Directory (AD) server and the account names (
sid
s in the session table) are pretty unintelligible: two letters and a bunch of digits. So there's no telling who AC1234567 really is unless you've memorized all 400 of them ;-)We do have the AD display names in the
name
field of the session attribute table so if those could be displayed that would go a long way to figuring out who AC1234567 actually is.