»

editevent

editevent — Edit or delete a user's past journal entry

Mode Description

Edit or delete a user's past journal entry

Arguments

mode

The protocol request mode: editevent

user

Username. Leading and trailing whitespace is ignored, as is case.

auth_method

The authentication method used for this request. Default is 'clear', for plain-text authentication. 'cookie' or any of the challenge / response methods are also acceptable.

password

DEPRECATED. Password in plain-text. For the default authentication method, either this needs to be sent, or hpassword.

hpassword

DEPRECATED. Alternative to plain-text password. Password as an MD5 hex digest. Not perfectly secure, but defeats the most simple of network sniffers.

auth_challenge

If using challenge / response authentication, this should be the challenge that was generated for your client.

auth_response

If using challenge / response authentication, this should be the response hash you generate based on the challenge's formula.

ver

(Optional) Protocol version supported by the client; assumed to be 0 if not specified. See Chapter 11: Protocol Versions for details on the protocol version.

itemid

The unique ItemID of the item being modified or deleted.

event

The revised event/log text the user is submitting. Or, to delete an entry, just send no text at all. Carriage returns are okay (0x0A, 0x0A0D, or 0x0D0A), although 0x0D are removed internally to make everything into Unix-style line-endings (just \ns). Posts may also contain HTML, but be aware that the LiveJournal server converts newlines to HTML <BR>s when displaying them, so your client should not try to insert these itself.

lineendings

Specifies the type of line-endings you're using. Possible values are unix (0x0A (\n)), pc (0x0D0A (\r\n)), or mac (0x0D (\r)). The default is not-Mac. Internally, LiveJournal stores all text as Unix-formatted text, and it does the conversion by removing all \r characters. If you're sending a multi-line event on Mac, you have to be sure and send a lineendings value of mac or your line endings will be removed. PC and Unix clients can ignore this setting, or you can send it. It may be used for something more in the future.

subject

The subject for this post. Limited to 255 characters. No newlines.

security

(Optional) Specifies who can read this post. Valid values are public (default), private and usemask. When value is usemask, viewability is controlled by the allowmask.

allowmask

Relevant when security is usemask. A 32-bit unsigned integer representing which of the user's groups of friends are allowed to view this post. Turn bit 0 on to allow any defined friend to read it. Otherwise, turn bit 1-30 on for every friend group that should be allowed to read it. Bit 31 is reserved.

year

If modifying only, the 4-digit year of the event (from the user's local timezone).

mon

If modifying only, the 1- or 2-digit month of the event (from the user's local timezone).

day

If modifying only, the 1- or 2-digit day of the month of the event (from the user's local timezone).

hour

If modifying only, the 1- or 2-digit hour from 0 to 23 of the event (from the user's local timezone).

min

If modifying only, the 1- or 2-digit minute of the event (from the user's local timezone).

prop_name

Set an arbitrary (but restricted) meta-data property to this log item. If a key is sent, but the value is blank or zero (0), then the value of the given name is deleted from this item's property list. See Chapter 12: Journal Item Meta-data for more information.

usejournal

(Optional) If editing a shared journal entry, include this key and the username you wish to edit the entry in. By default, you edit the entry as if it were in user "user"'s journal, as specified above.

Return Values

success

OK on success or FAIL when there's an error. When there's an error, see errmsg for the error text. The absence of this variable should also be considered an error.

errmsg

The error message if success was FAIL, not present if OK. If the success variable isn't present, this variable most likely won't be either (in the case of a server error), and clients should just report "Server Error, try again later.".