ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
856
|
Sun Dec 19 19:00:06 2004 |
| Ulrich Trüssel | ulrich.truessel@familienhund.ch | Bug report | Windows | 2.5.5-2 | Re: Redirect to wrong hostname | know that illness... :-( but was the last of the family of 4 people
i'd like to ask for an other usefull change togehter with this and how url's are
handled by elog:
since there may be spaces in the name of a logbook (ex. "1stWordOfLogbook
2ndWordOfLogbook") it is very userfriendly to name logbooks. also it's easy th
make a reference for a other entry by copy and paste:
Display ThisURL = http://localhost:8080/$logbook/$message id
however, using spaces in the logbook name may give a wrong result, because the
url would be http://localhost:8080/1stWordOfLogbook
and the space as well as the 2ndWordOfLogbook//$message id is only normal text.
may it be possible stefan, to replace the space in an url (starting
with "http://") with a "+" or "%20"? this would allow to automate some things.
actual the logbook name has to be hardcoded.
> > I think you should be using tcp_hostname instead of gethostname if it is
> > specified.
>
> Sorry my late reply, I was ill for some time. I implemented your suggestion in
> revision 1.522 which is available from CVS.
>
> Note that there is also the "URL = xxx" option in the configuration file which
> lets you specify the whole URL including the host name. |
858
|
Mon Dec 20 17:18:16 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Windows | 2.5.5-2 | Re: Redirect to wrong hostname | Ok, I changed that in version 2.5.5-3. Note that one can also use the "elog:..."
substitution, like
Display ThisURL = elog:$logbook/$message id |
66793
|
Thu Apr 22 12:29:05 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.7.7 | Re: Recursively open a new attribute of the same type |
Diogo Alves wrote: |
Hi,
I have a logbook which, among other things, contains these attributes:
Options Ingredient = Egg, Oil
Options Quantity = 2, 0.1L
Now, I would like to, every time I select an ingredient and respective quantity, that another Ingredient and Quantity field opens up for me to procede addind them.
I've searched in the documentation and found nothing related to this. Maybe I missed it. Is it possible to do this?
Also, is there a way to display 2 attributes in the same row? Messing with CSS is probably the only answer ... correct?
|
Recursive attributes are not possible. All you can do is to define a certain number (like Ingredient1, Ingredient2, Ingredient3) and use Conditional Attributes to show them using the "Show Attributes Edit = ..." option.
To display two attributes in the same row, use
Format <attribute> = 1
for the second attribute. |
66795
|
Fri Apr 23 08:32:10 2010 |
| Diogo Alves | diogomiguelalves@gmail.com | Question | Linux | 2.7.7 | Re: Recursively open a new attribute of the same type |
Stefan Ritt wrote: |
Diogo Alves wrote: |
Hi,
I have a logbook which, among other things, contains these attributes:
Options Ingredient = Egg, Oil
Options Quantity = 2, 0.1L
Now, I would like to, every time I select an ingredient and respective quantity, that another Ingredient and Quantity field opens up for me to procede addind them.
I've searched in the documentation and found nothing related to this. Maybe I missed it. Is it possible to do this?
Also, is there a way to display 2 attributes in the same row? Messing with CSS is probably the only answer ... correct?
|
Recursive attributes are not possible. All you can do is to define a certain number (like Ingredient1, Ingredient2, Ingredient3) and use Conditional Attributes to show them using the "Show Attributes Edit = ..." option.
To display two attributes in the same row, use
Format <attribute> = 1
for the second attribute.
|
Ok, thank you for your answer.
I guess my next question is whether it is possible to have, for example, 2 attributes:
Options Ingredient1 =
Options Ingredient2 =
Extendable options = Ingredients1, Ingredients2
sharing the exact same possible list of values.
Thanks agin. |
66796
|
Fri Apr 23 08:33:53 2010 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.7.7 | Re: Recursively open a new attribute of the same type |
Diogo Alves wrote: |
I guess my next question is whether it is possible to have, for example, 2 attributes:
Options Ingredient1 =
Options Ingredient2 =
Extendable options = Ingredients1, Ingredients2
sharing the exact same possible list of values.
|
If you add via an option to one Ingredient, you have to add it to the other as well. There is no automatic way to do that. |
69782
|
Mon Apr 15 17:50:20 2024 |
| Stefan Ritt | Hastefan.ritt@psi.ch | Bug report | Windows | ELOG V3.1.3-793 | Re: Record date isn't set to current date when replying to elogs | Have you tried the config option "Preset on reply <attribute> = $date". On a reply, the <attribute> will be preset with the current date.
Stefan
Celeste Torkzaban wrote: |
Hello,
I started using the record date feature in one logbook, since we plan to copy over old entries Joplin/Onenote. When starting a new entry, I see that the record date is automatically set to the current date, but when I reply to an elog, the record date is automatically set to the record date of the elog I'm replying to. Is there a way to fix this?
|
|
67211
|
Wed Mar 14 14:45:23 2012 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Windows | 2.7.6 | Re: Record Proliferation |
Paraic Fahey wrote: |
Saving, using Submit sees recently updated fields cleared after hitting SUBMIT.
MOre significantly this then leads to a proliferation of instances of the same record being generated in the logfile and consequently on the logbook.
Has anybody a fix or advice on this?
|
I have not heard of that problem before.
The key to fix is to reproduce it, then teach me how to reproduce it. Only errors I can reproduce on my computer I am able to fix.
Best regards,
Stefan |
67213
|
Wed Mar 14 15:34:41 2012 |
| David Pilgram | David.Pilgram@epost.org.uk | Bug report | Linux | Windows | 2.7.6 | Re: Record Proliferation |
Stefan Ritt wrote: |
Paraic Fahey wrote: |
Saving, using Submit sees recently updated fields cleared after hitting SUBMIT.
MOre significantly this then leads to a proliferation of instances of the same record being generated in the logfile and consequently on the logbook.
Has anybody a fix or advice on this?
|
I have not heard of that problem before.
The key to fix is to reproduce it, then teach me how to reproduce it. Only errors I can reproduce on my computer I am able to fix.
Best regards,
Stefan
|
Does this occur if you are adding an attachment? As I am blessed with forever using ancient systems, I've seen fields and indeed text being cleared because they were entered between clicking on 'Upload' for an attachment and the .png files being generated and displayed. Answer here is patience - I use all too much of mine up in this exercise, sadly.
|
|