Feature Proposal: Make the signature format a variable

Motivation

Signatures formats are now hardcoded in templates. They should be configurable, and even per user.

Description and Documentation

Create a variable SIGNATUREFORMAT that is defined in preference topics.

   * Set SIGNATUREFORMAT = -- <nop>%WIKIUSERNAME% - %DATE%

The templates would have something like this:

<input class="twikiInputFieldReadOnly" name="sig" ... value="%SIGNATUREFORMAT%" />

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: ArthurClemens - 03 Dec 2008

Discussion

This is somewhat related to DIsplayBrokenuserLinksBetter. I think the idea of a signature format is a good one, though I can't say I'm keen on the idea of everyone having an individual signature format that is imposed on everyone else. While it would allow personality to shine through, you could end up with a lot of images being loaded, and potentially a lot of people defining silly signatures.

It might be a better idea to think instead about how we sign things. At the moment we assume a signature is a wikiname that links to a topic somewhere else in the wiki. As a thought experiment, consider instead that it could be a special string: say pp:ArthurClemens (pp is standard nomenclature for per procurationem, or on behalf of). The special string can be interpreted and expanded as "the signature of the person who goes by the name Arthur Clemens". Then, when I view a topic, I see your signature rendered using my SIGNATUREFORMAT. Taking that a step further, pp:UseVariableForSignature@2 could mean the signature of the person who saved revision 2 of the topic UseVariableForSignature. The linking to a rev would result in a date - the date revision 2 was saved.

The main problems with this would be the copy-pasting of a signature from one place to another and the looking up of all that revision meta-data.

-- pp:CrawfordCurrie

My feeling from reading Arthurs proposal is not to create a promoted feature that invites people to create individual signatures.

But for the admin today the only way to change the copy/paste field signature below the edit window is to hack the templates.

It would be nicer to be able to tailor this site wise by either a DefaultPreference value or by configure setting.

I think the pp: idea is perhaps a little shooting over the target of what people really need.

-- KennethLavrsen - 03 Dec 2008 - 14:21

I don't agree. Once you sign something right now, the semantic that "this is a signature" is immediately lost - even more so with variable signature formats. This makes topic analysis much harder. Also, I want to get away from the "a user is a topic" assumption - it just doesn't hold water unless you are using the default user mapper.

Really, signatures should only ever be used in forum-style discussions (like this one) and in those types of discussion the signature format should be dictated by the forum, not by the poster.

-- pp:CrawfordCurrie - 03 Dec 2008 - 16:47

Why do we need to define how people want to use a signature?

Admins can always 'lock' a preference in FINALPREFERENCES, if they want to provide less freedom, can't they?

-- ArthurClemens - 03 Dec 2008 - 16:54

OK, that was a red herring, don't let it defocus from the core point; that when a signature is applied, the fact that is is a signature is lost. I proposed a patch to try and re-establish the link between the signature and the actual user record in the database in DIsplayBrokenuserLinksBetter. In any case that doesn't affect what you are proposing here, so ignore it and I'll stop trying to address the bigger picture.

As I said before, a configurable signature format is fine by me.

-- CrawfordCurrie - 04 Dec 2008 - 08:22

Seems this was accepted. I see no need for release meeting discussion after the last statements. OK for patch release also as it is a feature that only impacts two places. The Wysiwyg and the normal edit window. If it looks OK there it works.

Please implement with current signature as default.

-- KennethLavrsen - 28 Jan 2009

Implemented in Tasks.Item8607.

-- ArthurClemens - 23 Feb 2010