ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
69322
|
Tue Mar 23 23:05:20 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Question | Linux | 3.14 | automatically obtain entry ID from search |
Hi,
in our application I want to have, let's say in the simplest case, two logbooks. One as a database of samples we fabricated and one as a logbook for measurements. When a measurement on a sample is done and an entry is submitted to the 2nd logbook, I want to automatically edit or reply to the corresponding entry in the 1st logbook. For example I want to append a line in the free text field to have a full log of what happened to a sample there. We reference our samples with a unique auto-generated ID in both logbooks. Is is somehow possible to search the 1st logbook for that ID or any other attribute and obtain the elog entry ID since the elog client will need that ID for editing an entry? |
69402
|
Thu Oct 21 15:17:52 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Linux | 3.14 | wrong server HTTP status code when login failed |
Hi,
I am trying to access elog through a python client (https://github.com/paulscherrerinstitute/py_elog) and found a strage strange behavior which may be related server side problem. The python script generates get/post messages via the python requests library. This works fine so far and I can view and post messages. However, if a wrong user/password is provided, the server still returns HTTP status code "200 OK", although login failed. Instead, it should return something like "401 Unauthorized". This behavior later causes problems since the python client thinks login was successful. After experimenting around I think this could be caused by a server side misconfiguration. Any ideas?
I am not sure if this imformation is important: We use LDAP as user/password provider for elog. |
69403
|
Thu Oct 21 15:19:16 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Linux | 3.14 | Re: wrong server HTTP status code when login failed |
Seems like I've discovered another bug here related to umlauts in my name. :D
I was submitting this post and forgot to put an icon. Elog seems to have saved a copy of my message, which I could not edit since my username does not match the bugged name saved for this message.
Chris Körner wrote: |
Hi,
I am trying to access elog through a python client (https://github.com/paulscherrerinstitute/py_elog) and found a strage strange behavior which may be related server side problem. The python script generates get/post messages via the python requests library. This works fine so far and I can view and post messages. However, if a wrong user/password is provided, the server still returns HTTP status code "200 OK", although login failed. Instead, it should return something like "401 Unauthorized". This behavior later causes problems since the python client thinks login was successful. After experimenting around I think this could be caused by a server side misconfiguration. Any ideas?
I am not sure if this imformation is important: We use LDAP as user/password provider for elog.
|
|
69410
|
Mon Nov 15 11:35:55 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Windows | 3.14 | Restrict edit time = 0 behavior intended? |
Hi,
I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately. |
69411
|
Mon Nov 15 11:48:25 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Windows | 3.14 | Re: Restrict edit time = 0 behavior intended? |
Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?
Chris Körner wrote: |
Hi,
I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.
|
|
69416
|
Tue Nov 16 15:14:42 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Windows | 3.14 | Re: Restrict edit time = 0 behavior intended? |
Hi Sebastian,
thanks for the reply. It is just a bit confusing that these similar settings behave so differently. For me it is no big deal to set the time for every logbook independently instead of [global], but it leaves more room for configuration errors.
Best,
Chris
Sebastian Schenk wrote: |
Hi Chris,
my old entry was related to the admin options of edit time.
The option "Admin restrict edit time" was implemented later, see ab8b98c
As a workaround you should be able to give "Restrict edit time" a ridiculous high number in the specific logbook, which should overwrite the global.
In the documentation is no rule specified for diabling global settings for specific logbooks, as far as i know.
Best wishes,
Sebastian
Chris Körner wrote: |
Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?
Chris Körner wrote: |
Hi,
I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.
|
|
|
|
69424
|
Sat Nov 27 21:48:41 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Linux | 3.14 | $attribute replacement fails occasionally |
Hi,
In our setup we have multiple logbooks. I want a convenient way to search all logbooks for an attribute (in our case with the name Sample-ID) by just clicking it in the list display of any logbook.Therefore, in the [global] section I put "List Change Sample-ID = <a href="https://ourelog.com/$logbook/?all=1&Sample-ID=$Sample-ID"</a>. This transforms the attribute in list display into a hyperlink to the search results page. So far this works fine. In the results page, of course the option also applies, meaning the attribute is replaced by the link as well. But here something odd happens and the replacement does not work. The intended behavior is to replace $logbook in the link with the name of the logbook. Sometimes, however, the replacement yields something like "logbook" (missing $ and thus not replacing anything) or even weirder something like "60logbook". I have no idea what causes this. |
69428
|
Sat Dec 4 13:03:32 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Linux | 3.14 | Re: $attribute replacement fails occasionally |
This problen drives me crazy. Under some circumstances the List Change <attribute> function does not replace $attribute. It happens at random circumstances when I use the Find function to search all logbooks. In the resulting list, it fails reproducibly for certain entries of certain logbooks. But I cannot find what is special about those lokbooks or entries. In different Find requests it works perfectly fine.
I have added a screenshot. The yellow button is created by this command in [global] for all logbooks. It makes no difference to define it in all [logbook] sections. I would really appreciate help to debug this.
List Change Sample-ID = <a href="page?mode=summary&reverse=1&all=1&Sample-ID=$Sample-ID$&sort=Date" class="id_div">$Sample-ID</a>
Chris Körner wrote: |
Hi,
In our setup we have multiple logbooks. I want a convenient way to search all logbooks for an attribute (in our case with the name Sample-ID) by just clicking it in the list display of any logbook.Therefore, in the [global] section I put "List Change Sample-ID = <a href="https://ourelog.com/$logbook/?all=1&Sample-ID=$Sample-ID"</a>. This transforms the attribute in list display into a hyperlink to the search results page. So far this works fine. In the results page, of course the option also applies, meaning the attribute is replaced by the link as well. But here something odd happens and the replacement does not work. The intended behavior is to replace $logbook in the link with the name of the logbook. Sometimes, however, the replacement yields something like "logbook" (missing $ and thus not replacing anything) or even weirder something like "60logbook". I have no idea what causes this.
|
|
Attachment 1: Screenshot_2021-12-04_130843.jpg
|
|