Re: csv import timestamp, posted by Andreas Luedeke on Thu May 14 22:16:03 2015
|
Hi Ferdinand,
"import" is meant to be used for files that have been exported with "find". Therefore it is not very flexible with the date format.
Todays date should look like that: "Thu 14 May 2015 22:12:00 +0200".
You have to convert your file that the date matches this format (BTW: I found this out by using the find - export feature; it may depend on a local configuration.)
Cheers
Andreas
| Ferdinand Gassauer wrote: |
|
Thanks
what is the format of the Date field in the csv file ?
My Date is date and not datetime.
| Andreas Luedeke wrote: |
|
Hi Ferdinand,
and that is exactly what happens when you import a csv file with a date field:
the creation date ($entry time) of the imported entries will be used from the "Date" column in the file.
I've just tried it and it works like a charm. Did you have any problems doing it?
Cheers
Andreas
| Ferdinand Gassauer wrote: |
|
I have to import a csv with a date field, which represents the creation date
this date should be used as "date" timestamp which is set automatically, otherwise all entries get the current datetime as timestamp
|
|
|
|
|
Re: Entry size too large for email notification, posted by Andreas Luedeke on Tue May 19 16:34:20 2015
|
Hi Jacky,
if I read the source code correctly then the maximum size of a base64 encoded email is hard coded to be 10 MB in elogd.h (recompile after changing it):
#define MAX_CONTENT_LENGTH 10*1024*1024
But I think that an 2.2 MB image should easily fit into that.
Andreas
| Jacky Li wrote: |
|
Hi,
I am doing an inline image that is about 2.2 MB. When I do a submit, I got the following message:
Error sending Email via <i>"<email server>"</i>: Entry size too large for email notification.
May I know what is the limit of the entry size and how do I change it? Thank you.
Jacky
|
|
|
Re: elogd moves elog entries, posted by Andreas Luedeke on Wed May 20 11:59:59 2015
|
> elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
> in the release announcement and in the release and migration notes. K.O.
That feature is one of the main reasons why the version jumped from 2.x to 3.x.
A free tip: changes in major revisions do indicate some kind of incompatibility.
But yes, the release documentation by bitbucket is not really that useful:
it is difficult for me too, to find out what changed with new releases.
I have to admit here, that I haven't read any GIT tutorial yet.
By the way: you are welcome to contribute to the release documentation!
On your actual problem: to go back to a former version of ELOG you can simply
- stop elogd 3.X,
- move all entries from the sub-directories one level up, and
- start the 2.X version of elogd.
I wouldn't really call this an "incompatibility", would you?
At least you can easily go back without much trouble.
Cheers
Andreas |
|
Re: elogd moves elog entries, posted by Andreas Luedeke on Wed May 20 18:46:27 2015
|
> Stefan told me that the change was because some users were having thousands of yymmdda.log files
> in the logbook directories, and that sorting them into subdirectories by year at least did something to bring some
> order. Possibly to get around the lazy archivers, I suspect.
I'm actually the culprit, who did ask for it.
If you want to know the full story, here it is:
We have our logbook data of our accelerator operation logbooks on AFS (Andrew File System).
And apparently AFS has a bloody stupid, hard coded limit:
the total length of all file names in one directory cannot exceed 64k.
Our operation logbooks go back for more than a decade and do contain many, many, many attachment files.
One day - very unexpectedly - we did hit that limit.
Removing temporary files (generated picture thumbnails) bought us time, and Stefan was nice enough to upgrade ELOG swiftly for us: a big "Thank You" to Stefan! |
|
Re: elogd moves elog entries, posted by Andreas Luedeke on Thu May 21 10:59:07 2015
|
I had no intention of causing any offence with my lazy archiving comment - hope I didn't, sorry if I did.
No offence taken :-)
Personally, I would have found it useful to put the attachments into a separate directory - or at least to allow
the possibility. Elog as it stands sometimes can, and sometimes cannot cope with that functionality - and even to try means messing around directly with the
yymmdda.log files. For me it would have saved me having duplicates of the same large attachment in two or three different logbooks, if I could always reference
the same Master copy of the attachment. This was at the time I was severely memory constrained, and in part forced me to change how I had operated elog, so for
me that need isn't as great as it once was.
David.
You can put a reference to the attachment of the other entry in your logbook: elog:67896/1
Or, if it is an image, you can just include it in your new entry like I did below.
Of course this only works if the other logbook is accessible on-line.
But how would you manage access rights to a common attachment folder?
Probably I just did not understand your idea.
Cheers
Andreas
|
Re: elogd moves elog entries, posted by Andreas Luedeke on Thu May 21 12:13:21 2015
|
> > elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
> > in the release announcement and in the release and migration notes. K.O.
>
> But yes, the release documentation by bitbucket is not really that useful:
> it is difficult for me too, to find out what changed with new releases.
I did know that I've read it summarized somewhere!
The changes with the different releases are documented here:
http://midas.psi.ch/elog/download/ChangeLog
It is actually not so difficult to find:
it is linked on the "Download" section http://midas.psi.ch/elog/download.html
"News for each version can be seen in the changelog (->http://midas.psi.ch/elog/download/ChangeLog)"
And for version 3.0.0 it states:
- Create one logbook subdirectory pear year
I admit that version 3.0 has never been announced and the changelog is not mentioned in the announcement of version 3.1.0
Maybe we'll do better in the future ;-) |
|
Re: Fixed text, posted by Andreas Luedeke on Tue May 26 11:26:12 2015
|
Dear Neal,
I don't understand your example. There is no such thing as a "subject field". You can define an attribute called "subject", like in this logbook.
But I would guess that you want to have five attributes "Time Off", "Reason", etc. that cannot be altered after an entry has been created? That's easy.
Or do you want to protect entries with specific content not to be deleted? That is not easy.
Please explain in more detail what you want to achieve, and I'll be happy to help.
Cheers, Andreas
| Neal Grafton wrote: |
|
I'd like to fix text or table in the subject field that can't be deleted or moved.
Can that be done in config? Example -
Time Off:
Reason:
Update By:
Estimated On time:
Detail:
|
|
|
Re: Fixed text, posted by Andreas Luedeke on Wed May 27 08:41:05 2015
|
Hi Neal,
you can preload words into one attribute field, but one field is either editable or not, you cannot protect single words in a field.
But the ELOG way to solve this would be to have multiple attributes: you would get one entry field for each attribute.
Just look at this logbook: it has the attributes Icon, Author, Author Email, Category, OS, ELOG Version and Subject.
You can change the content of each attribute (except of "Author", that field is made here to be not editable), but as a normal user you cannot change the names in front of the fields.
Did you've set up the demo logbook and played around with it? Because your question suggests to me that you don't figured out yet what ELOG does. (Or as a direct answer: no, it does not make sense to me ;-) )
But I'm sure you'll figure it out: ELOG is best learned by trial and error.
Kind Regards
Andreas
| Neal Grafton wrote: |
|
Sorry I call this field that you write in the subject field, a little confusing.
So is there anyway to fix the indicated words in place in this typing space so you can enter the text you want next to them but be unable to delete them. (does this make sense?)
Neal
| Andreas Luedeke wrote: |
|
Dear Neal,
I don't understand your example. There is no such thing as a "subject field". You can define an attribute called "subject", like in this logbook.
But I would guess that you want to have five attributes "Time Off", "Reason", etc. that cannot be altered after an entry has been created? That's easy.
Or do you want to protect entries with specific content not to be deleted? That is not easy.
Please explain in more detail what you want to achieve, and I'll be happy to help.
Cheers, Andreas
| Neal Grafton wrote: |
|
I'd like to fix text or table in the subject field that can't be deleted or moved.
Can that be done in config? Example -
Time Off:
Reason:
Update By:
Estimated On time:
Detail:
|
|
|
|
|