• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Dakar introduces quite a number of new variables, TWikiVariables#VarEMAILS is the latest example. In the interest of trimming fat and avoiding additional variables in the future I suggest to remove EMAILS and introduce a new USERINFO variable with this spec:

USERINFO{"format"} - retrieve and format info of logged in user

  • The tokens $emails, $username, $wikiname and $wikiusername are expanded to the info of the curretly logged in user
  • Syntax: %USERINFO{"$emails, $username, $wikiname, $wikiusername"}%
  • Expands to: ==
  • Related: USERNAME, WIKINAME, WIKIUSERNAME, TWikiUserAuthentication

This is a small enough change for Dakar with a low chance of introducing new bugs.

Ideas for enhancements after Cairo:

  • Add user="name" parameter to get the info of any user
  • Return any other info from user home page, such as $Location, $Telephone, etc

-- PTh

Moreover, I'd like to see an API for user info in Func.pm, i.e. to get the email addrs of a user, all users of a group and all groups of a user. But I wouldn't demand that from TWiki-4.0.0.

-- MD

This is a good idea, but it's not Urgent. It can always be introduced later, and the current variables set to the new USERINFO variable.

Regraded to Normal.


I set it to urgent because now is the last chance without going through the deprecation process (which adds to upgrade issues). Regrading back to Urgent.

-- PTh

I vote we dont use this because its too specific.

We have TopicVarsPlugin that can extract a setting from another topic. If we still had the user information in settings rathe than form fileds we could use that.

So this prompts me to ask, why don't we have instead of this, a perfectly general solution of which this is a specific instant. namely a mechnaism to extract form fields from another topic.

-- AJA

We do have such a function via a plugin - TWiki:Plugins/FormFieldListPlugin

I'll leave it as an exercise to the reader how to simulate %USERINFO{ ...}% using %FORMFIELDLIST{ ... }%

-- AJA

AJA, this won't cover the new email scheme?

-- SP

Right. It won't. Lets look at why not.

The e-mail ha been put 'outside' the normal TWiki informtion repository, in the .htpasswd file. That was design decision. There were other possibilities beside that one.

Now from a security paranoia POV this is a Good Thingtm since the .htpasswd can be put well away from the space administered by Apache. No, really, how many people put it under $cfg{DataDir} ?

But there is a point where security starts to interfere with with functiionality.

What I'm asking is whether it is good to have a unique function to deal with a special case or to use a more general tool.

Lets try another idea.
We've already added %META:PREFERENCE{}% as a mechaism where by we can have settings in a topic that can't be viewed. Why can't we make use of this?

Lets face it, we may need at some future time, to be able to hide other sensitive information. We can't keep stuffing it all in the .htpasswd file.

See TWiki:Codev.HiddenTopicSpecificSettings - this also touches on the "H" attribute to hide the field which leads to TWiki:Codev.TWikiFormWithHiddenType

Now you may turn around and say "yes, but its not hidden when you edit". True, and in that case this is an advantage. It means that the user has a simple and familair interface for altering his/her e-mail address. So we can eliminate another special case set of code and interfaces and make the user navigation simpler and less confusing.

What? Did I hear someone raise the idea that anyone can alter any user's home topic? I thought we were talking about SECURITY here, and security means the INTEGRITY of the data, not just hiding it. If anyone can alter anyone else's home topic then all bets are off anyway.

Security isn't about throwing more and more code at the problem. Its about making the right design decisions and balancing needs, functionality and risk.

Do you see the underlying point I'm making here? Lets not proliferate "special cases" - underlying code & API, TWikiVariables and user interfaces and the documentation to support them - when we can use a general mechanism.

-- AJA

The spec above is inconsistent with other tags that do similar things, and doesn't take into account the possibility that we may add other capabilities e.g. %USERINFO{"FredBloggs"}%. We should stick to the %verb{"object" modifier=""}% format.

USERINFO - retrieve details about the logged in user

  • By default, the retrieved info will be formatted as a comma-separated list comprising the username (login name), web, wikiname, and emails.
  • Syntax: %USERINFO%
  • Expands to: =guest, TWikiGuest, =
  • you can also use the format parameter to get different formatted results:
  • Syntax: %USERINFO{format="$username is really $wikiname"}%
  • Expands to guest is really TWikiGuest
  • The tokens $emails, $username, $wikiname, and $web are available for use in the format string. $web is the web where the user topic is defined (usually %MAINWEB%)
  • Related: USERNAME, WIKINAME, WIKIUSERNAME, TWikiUserAuthentication

Don't forget to deprecate USERNAME, WIKINAME and WIKIUSERNAME.


Does that mean we are going to preserve orthogonality of function by removing the now redundant and confusing USERNAME, WIKINAME and WIKIUSERNAME ?

-- AJA

I see CC's point, but TWiki uses sometimes VAR{"object"} and sometimes VAR{"action"}. I defined above syntax so that it is consistent with FORMFIELD{"format" topic="..."} and REVINFO{"format" topic="..."}.

USERNAME, WIKINAME and WIKIUSERNAME are used all over the place in documentation and in TWiki applications. We should not deprecate them!

-- PTh

I know that TWiki is inconsistent and uses VAR{object} and VAR{verb}. FORMFIELD already works correctly (FORMFIELD{"fieldname" format="") - the doc is wrong. The only inconsistent variables are: REVINFO, TOPICLIST and WEBLIST - and TOPICLIST and WEBLIST already support format="", in clear acknowledgement of the error. Everything else uses a format= parameter.

I am trying to make it consistent! Let's not compound previous errors by adding more inconsistency!

USERNAME, WIKINAME and WIKIUSERNAME are used all over the place in documentation and in TWiki applications - sorry, that doesn't mean they can't be deprecated, it just means they can't be removed.

But they do not need to be hard-coded. They can easily be implemented in preferences as follows:

   * Set WIKINAME = %USERINFO{format="$wikiname"}%
   * Set USERNAME = %USERINFO{format="$username"}%
   * Set WIKIUSERNAME = %USERINFO{format="$web.$wikiname"}%

Again, I stress that %USERINFO will probably be used in the future to get info about other users.

SVN 8510


Thanks for actioning on this, CC. I am very happy this change, I'm sure it'll prove useful for future expansion.

-- SP

Updated doc + ChangeEmailAddress.

SVN 8555.

-- SP

I'm making a change to remove $web , and instead adding a $wikiusername - as this is the only place that there truely was an assumption about the true format of wikiusername (everywhere else you can replace it with any string that rcs is ok with)

similarly replaced $login with $username, to be 'consistent'


-- SD

Summary Replace EMAILS with USERINFO
ReportedBy TWiki:Main.PeterThoeny

SVN Range Sun, 22 Jan 2006 build 8439
AppliesTo Engine

Priority Urgent
CurrentState Closed

Checkins 8509 8510 8555 8556
Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r17 - 2006-01-27 - SvenDowideit
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback