Streamlined comment approval?

[garvinhicking]

Hi!

That could be done with a token system like you mention, yes. The method that sends the moderation mail would need to create a one-time token, and send that token inside the links of the email.

A token would then only be valid for the single action of approving a comment.

Personally, I don't find that very interesting, but I would not mind if anybody wants to implement this into the serendipity core code. It would only be important that the approval token is not guessable, only approves the single comment that it is valid for, and will not lead to a user being logged in automatically to perform other tasks (due to security concerns).

I believe this will not be possible to achieve with the plugin API. The roots of the moderation emails is too deep to completely circumvent/bypasse it. Also, if the plugin aPI were to be used, it could lead to a user getting fully logged in and other tasks being performed...

If you need more help on specific function calls or so, I can definitely lend a helping hand.

HTH,
Garvin

[tnguyen]

is there a way to allow posting without approval?

i

[garvinhicking]

Hi Rob!

If I patch the code, would you like it as a replacement behaviour, or an optional behaviour?

I'd really love if it were optional. Maybe you can even figure out a way to make this an option of the antispam plugin? Or do you think, a global config option would be more suitable?

Do you have a preference for token storage (in a single file, as separate files in templates_c, or in the database)?

The serendipity_options Table could be suitable to save these kind of options, please have a look if that one can work out for you?

Because I am lazy, I'd like to make this work without having to change the database structure (requiring creating the structure upgrade code)...

Exactly my wish

1) modifying the .htaccess rewrite rules to allow permalinks to work with the additional uri parameter

Maybe you don't need a nice rule, but can work with /approve/tokenXXX instead? The /approve/ rewrite Rule should be qite flexible and allow two wildcard strings between / and / that you could use?

The part I don't get is how to prevent index.php from returning the entire blog framework, only a message, cause I don't understand where the:

define('DATA_COMMENT_APPROVED', true);

type lines get used later.

That one gets rendered/displayed inside the genpage.inc.php -> entries.tpl template parsing.

I'd suggest that if tokens are used, you could bail out with a simple Text/plain content type header to acknowledge approval? You wouldn't need an own template, espececially if your goal is to make your mobile phone not fetch terribly long pages...?

Regards,
Garvin

[garvinhicking]

Hi!

I think a global option would be better. I know they are stored in the serendipity_config table. How can I add another options (that I could then just access with a $serendipity['useComentTokens'] call)?

Those can be added to include/tpl/config_global.inc.php.

Are there functions for setting/querrying/deleting these? What is normally in this table?

No, just usual SQL code. Inside that table, Cookie Hash keys for automatted login are stored, as well as template options.

In my installation, I see the fields are: name,value,okey. I assume I could store the comment number and key in name and okey, (both keyed fields) and...store the post # in the name field as a check?

I'd suggest something like:

name: approval_[COMMENTID]
value: [HASH]
okey: [TIMESTAMP]

The entryid can be fetched through the comments.entryid table by referencing commentid, so you don't need to store it as well.

SO I could just generate the header and print a message right in index.php after the calls to serendipity_deleteComment or serendipity_approveComment? Can you point me to an example of this that I could just model it on?

Uh, currently there is no example of this. Currently all plugins and core mechanisms route output through templating. But since you want a lightweight output, you'd be the first here

Can I make changes against 1.2.1 (what I run)? I was trying to check in SVN to compare thee files 1.2.1 to 1.3.1 but am not sure how to line up release numbers to revisions numbers in SVN...Or I can just upgrade, I guess.

No, you will need to make changes against SVN trunk (1.4). I'd suggest you to upgrade, yes.

Best regards,
Garvin

[garvinhicking]

Hi!

[quote]
Would it be OK to add another parameter to these two functions?[/quote

Definitely! Those tokens should be added to the function signature, I see no problem with adding this to the core.

I'm excited to your solution

Regards,
Garvin

[garvinhicking]

Hi!

Great, there was less change to the code than I imagined.

I took the liberty to modify the patch in some places, namely creating functions for the index.php lookup, as well as the token lookup so it was not in the code two times.

If you find the time, please review the final patch:

http://svn.berlios.de/viewcvs/serendipi ... 5&view=rev
http://svn.berlios.de/viewcvs/serendipi ... 4&view=rev

Regards,
Garvin

[Don Chambers]

Excellent work Rob! Thanks for providing valuable new functionality to the community!!

[kleinerChemiker]

when will we be pleased with the new function? I can hardly await it