Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 210 of 795  Not logged in ELOG logo
ID Date Icon Author Author Emailup Category OS ELOG Version Subject
  66069   Fri Nov 21 18:21:36 2008 Question Dennis Seitzdseitz@berkeley.eduQuestionAlllatestRe: Re: $entry time not readable by Subst, else not datetime type? - possible Preset bug?

Dennis Seitz wrote:

Stefan Ritt wrote:

Dennis Seitz wrote:
Do you mean '$entry time', or did you create a new parameter? (I don't see $entry date in the elogd.cfg reference)


Yes, of course I mean '$entry time', sorry for the misspelling.


Well, we really appreciate the way you keep adding features and making improvements. I thought you might have slipped a new one in!



FYI, I think there's a little bug in the datetime vs $date implementation.

Here's a section of my config file implementing a "Last Edit" field:

Type Last Edit = datetime
Preset Last Edit =$date
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Start page = ?rsort=Last Edit

I expected that "Preset Last Edit =$date" would set Last Edit to the current date when I create a new entry. In fact that leaves the field empty, or at least not in datetime format.

I found that using this instead works:
Preset Last Edit =$entry time

which seems contradictory since
Subst on edit Last Edit = $date
works fine.
  66080   Tue Nov 25 17:01:55 2008 Reply Dennis Seitzdseitz@berkeley.eduQuestionAll2.7.3Re: Re: $entry time not readable by Subst, else not datetime type? - possible Preset bug?

Stefan Ritt wrote:

Dennis Seitz wrote:
FYI, I think there's a little bug in the datetime vs $date implementation.

Here's a section of my config file implementing a "Last Edit" field:

Type Last Edit = datetime
Preset Last Edit =$date
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Start page = ?rsort=Last Edit

I expected that "Preset Last Edit =$date" would set Last Edit to the current date when I create a new entry. In fact that leaves the field empty, or at least not in datetime format.

I found that using this instead works:
Preset Last Edit =$entry time

which seems contradictory since
Subst on edit Last Edit = $date
works fine.


Do you have an old version of elog? Using the current version with a configuration file:
Attributes = Author, Type, Last Edit
Type Last Edit = datetime
Preset Last Edit =$date
Locked Attributes = Last Edit
Start page = ?rsort=Last Edit

I get the correct behavior:



Yes, I'm using 2.7.3 - I'll try upgrading, sorry. I'll reply with the outcome.
  66102   Tue Dec 9 00:22:41 2008 Reply Dennis Seitzdseitz@berkeley.eduQuestionAll2.7.5Re: Re: $entry time not readable by Subst, else not datetime type? - possible Preset bug?

Dennis Seitz wrote:

Stefan Ritt wrote:

Dennis Seitz wrote:
FYI, I think there's a little bug in the datetime vs $date implementation.

Here's a section of my config file implementing a "Last Edit" field:

Type Last Edit = datetime
Preset Last Edit =$date
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Start page = ?rsort=Last Edit

I expected that "Preset Last Edit =$date" would set Last Edit to the current date when I create a new entry. In fact that leaves the field empty, or at least not in datetime format.

I found that using this instead works:
Preset Last Edit =$entry time

which seems contradictory since
Subst on edit Last Edit = $date
works fine.


Do you have an old version of elog? Using the current version with a configuration file:
Attributes = Author, Type, Last Edit
Type Last Edit = datetime
Preset Last Edit =$date
Locked Attributes = Last Edit
Start page = ?rsort=Last Edit

I get the correct behavior:



Yes, I'm using 2.7.3 - I'll try upgrading, sorry. I'll reply with the outcome.


Everything works fine with 2.7.5, thanks!
  66103   Tue Dec 9 00:25:52 2008 Idea Dennis Seitzdseitz@berkeley.eduRequestAll2.7.5Please add Subst on Duplicate

 I would like to be able to substitute some attribute values when an entry is duplicated. I don't see Subst on Duplicate available in the cfg file syntax. Can you add that?

 

Thanks

  66105   Wed Dec 10 03:11:01 2008 Reply Dennis Seitzdseitz@berkeley.eduRequestAll2.7.5Re: Please add Subst on Duplicate

 

Stefan Ritt wrote:

 

Dennis Seitz wrote:

 I would like to be able to substitute some attribute values when an entry is duplicated. I don't see Subst on Duplicate available in the cfg file syntax. Can you add that?

 

Subst on Duplicate does not make sense. Subst always works after you submit an entry, while Preset works before you enter the entry. When you Duplicate an entry, it looks like a new one, just with attributes and text from another entry. So when you submit that one, the system cannot distinguish if you entered a new one by yourself or if this is based on a copy of another entry. So what you probably need is Preset on duplicate.

Thanks for explaining.

I thought Preset would work with Duplicate since Duplicate creates a new entry, but it didn't. Then I tried Subst because Duplicating an entry opens it in Edit mode, so you are in effect Duplicating, and then Editing the entry. It just didn't occur to me to look for Preset on Duplicate.

  66106   Thu Dec 11 03:13:31 2008 Warning Dennis Seitzdseitz@berkeley.eduBug reportMac OSX2.7.5Attribute value lost when adding to another extendable attribute

Here is an excerpt from my config file:

Type Last Edit = datetime
Preset Last Edit =$entry time
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Preset on Duplicate Last Edit = $date

I have another attribute called Part that I've made extendable.

When I duplicate an entry, Last Edit is updated with the current date correctly. However, as soon as I click the Add Part button next to my extendable Part attribute, and the page reloads to show the entry box for the Part field, the Last Entry field is replaced with a "-".

I have to submit and then re-edit the entry to get Last Edit to have a valid value again.

 

 *EDIT*:

I noticed that any time the page reloads while in the entry screen this happens, e.g. by selecting plain instead of html format.


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  66112   Sat Dec 13 02:13:51 2008 Reply Dennis Seitzdseitz@berkeley.eduBug reportMac OSX2.7.5Re: Attribute value lost when adding to another extendable attribute

 

Stefan Ritt wrote:

 

Dennis Seitz wrote:

Here is an excerpt from my config file:

Type Last Edit = datetime
Preset Last Edit =$entry time
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Preset on Duplicate Last Edit = $date

I have another attribute called Part that I've made extendable.

When I duplicate an entry, Last Edit is updated with the current date correctly. However, as soon as I click the Add Part button next to my extendable Part attribute, and the page reloads to show the entry box for the Part field, the Last Entry field is replaced with a "-".

I have to submit and then re-edit the entry to get Last Edit to have a valid value again.

 

 *EDIT*:

I noticed that any time the page reloads while in the entry screen this happens, e.g. by selecting plain instead of html format.

 

 Thanks for reporting that problem. It has been fixed in SVN revision 2156.

 

 Excellent! Thank you.

  66323   Sat Apr 18 00:33:53 2009 Reply Dennis Seitzdseitz@berkeley.eduQuestionAll2.7.5Re: Config so that users can delete only their own entries?
Thanks for reminding me of that, it will do fine. A suggestion: Separate Restrict Edit into Restrict Edit and Restrict Delete or some functional equivalent. Then we have the choice to restrict one or the other or both. Is that worth doing?


Stefan Ritt wrote:

Dennis Seitz wrote:
I've tried

Deny_Delete = All
Allow Delete = $author

and just
Allow Delete = $author

But either users can delete anyone's entries, or they can't delete any entries.

Am I missing something? If not, can you add the capability to allow users to delete, but only their own entries?

Thanks as usual for a great piece of code!


You cannot put $author into any Allow or Deny option, only explicit login names (not "full" names). What you want however is
Restrict Edit = 1

which lets only the original author either delete or edit entries. If you use that option, you probably want as well
Preset Author = $long_name
Preset on reply Author = $long_name
Preset on duplicate Author = $long_name
Locked Attributes = Author

So a user cannot pretend to be somebody else. You also need a valid "admin user = ..." statement. Note that the admin user always can delete/edit entries. If no admin user is defined, everybody has automatically admin rights, so Restrict Edit has no effect.
ELOG V3.1.5-fe60aaf