| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69073
|
Wed Dec 4 10:37:32 2019 |
 | Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | V3.1.3 | Re: Change column width in list mode? | You need
.listframe td:nth-child(3) {
min-width: 250px;
}
/Stefan
| David Wallis wrote: |
|
In some of our logbooks, some columns are very narrow, which makes their content difficult to read. I have tried adding a custom css file like this:
listframe td:nth-child(3) {
width: 250px;
}
But I find that the column width does not change. I have verified via element inspection that the width attribute is active on the correct column (td).
Am I doing someting wrong, or is this not possible?
|
|
|
69075
|
Fri Dec 6 15:40:19 2019 |
| David Wallis | wallis@aps.anl.gov | Question | Linux | V3.1.3 | Re: Change column width in list mode? | Awesome, thank you!
| Stefan Ritt wrote: |
|
You need
.listframe td:nth-child(3) {
min-width: 250px;
}
/Stefan
| David Wallis wrote: |
|
In some of our logbooks, some columns are very narrow, which makes their content difficult to read. I have tried adding a custom css file like this:
listframe td:nth-child(3) {
width: 250px;
}
But I find that the column width does not change. I have verified via element inspection that the width attribute is active on the correct column (td).
Am I doing someting wrong, or is this not possible?
|
|
|
|
68539
|
Mon Jan 9 17:15:56 2017 |
 | Andreas Warburton | awarburt@physics.mcgill.ca | Bug report | Mac OSX | V3.1.2-edc5e85 | elogd crashes during SSL Mirror operations involving attachments | My MacOS (10.12.2) elogd version V3.1.2 is a recent git commit (edc5e85), due to the fix to my earlier-described issue solved in the thread here: https://midas.psi.ch/elogs/Forum/68519.
I am trying to (re-)set up Mirror functionality with a linux server running the standard public (V3.1.2-bd75964). I had initially updated the linux server so that it also had the latest git commit (edc5e85), but could then not even add new logbook entries that involved attachments to it. I therefore rolled the linux server back to the standard public 3.1.2 version.
On the remote Mac, synchronizations usually look like they are going to work fine, with Mirror simulate = 1 switched on. After I set Mirror simulate = 0, and if the server and remote logbook are already identical, I *occasionally* get the proper "All Entries Identical" synchronization result. Unfortunately, this is very rare, and usually there is a failure whereby the remote (Mac) logbook decides that a significant fraction of its entries (usually sequential, from some seemingly random entry all the way up to the last entry) are missing on the linux server and need to be submitted back to the server from the remote Mac.
When the local and remote logbooks are not identical, and a record in need of synchronization contains an attachment, there is again destructive behaviour similar to that described above, except that the Mac elogd executable usually crashes. (As in the case of the already-identical synchronizations described above, I only tested this after observing the correct expected behaviour first with Mirror simulate = 1.)
I'd be grateful for some help/suggestions. My current testing suggests that my problems are likely not elog-content dependent. (The logbook now undergoing synching has less than 10 entries in it.)
More generally, the issue of having things behave fine with Mirror simulate = 1, but then experiencing corruption/damage when switching to Mirror simulate = 0 seems serious to me.
Many thanks, Andreas
|
|
68547
|
Fri Jan 13 08:27:15 2017 |
 | Andreas Warburton | awarburt@physics.mcgill.ca | Bug report | Linux | Mac OSX | V3.1.2-edc5e85 | Re: elogd crashes during SSL Mirror operations involving attachments | The attached screenshot shows the behaviour after doing a synchronization (with Mirror simulate = 1) following first having ensured that the local (Mac) and remote (linux) ELOGs initially showed "All entries identical" when doing a simulated synchronization, and then having edited local entries 9707 and 9709 by uploading (different) attachments to them.
The fact that the synchronization is suggesting to renumber two different entry IDs to the same number looks like a bug.
Best regards,
Andreas W.
| Andreas Warburton wrote: |
|
My MacOS (10.12.2) elogd version V3.1.2 is a recent git commit (edc5e85), due to the fix to my earlier-described issue solved in the thread here: https://midas.psi.ch/elogs/Forum/68519.
I am trying to (re-)set up Mirror functionality with a linux server running the standard public (V3.1.2-bd75964). I had initially updated the linux server so that it also had the latest git commit (edc5e85), but could then not even add new logbook entries that involved attachments to it. I therefore rolled the linux server back to the standard public 3.1.2 version.
On the remote Mac, synchronizations usually look like they are going to work fine, with Mirror simulate = 1 switched on. After I set Mirror simulate = 0, and if the server and remote logbook are already identical, I *occasionally* get the proper "All Entries Identical" synchronization result. Unfortunately, this is very rare, and usually there is a failure whereby the remote (Mac) logbook decides that a significant fraction of its entries (usually sequential, from some seemingly random entry all the way up to the last entry) are missing on the linux server and need to be submitted back to the server from the remote Mac.
When the local and remote logbooks are not identical, and a record in need of synchronization contains an attachment, there is again destructive behaviour similar to that described above, except that the Mac elogd executable usually crashes. (As in the case of the already-identical synchronizations described above, I only tested this after observing the correct expected behaviour first with Mirror simulate = 1.)
I'd be grateful for some help/suggestions. My current testing suggests that my problems are likely not elog-content dependent. (The logbook now undergoing synching has less than 10 entries in it.)
More generally, the issue of having things behave fine with Mirror simulate = 1, but then experiencing corruption/damage when switching to Mirror simulate = 0 seems serious to me.
Many thanks, Andreas
|
|
| Attachment 1: Screen_Shot_2017-01-13_at_8.24.07_AM.png
|
|
|
68548
|
Fri Jan 13 21:05:49 2017 |
| Andreas Warburton | awarburt@physics.mcgill.ca | Bug report | Linux | Mac OSX | V3.1.2-edc5e85 | Re: elogd crashes during SSL Mirror operations involving attachments | When I switch from SSL = 1 to SSL = 0 and I use http:// instead of https://, the ability to upload attachments to logbook entries returns. With both Chrome and Safari browsers, with SSL = 1 the file upload hangs after only a small percentage of the file has been uploaded. I ran the following openssl diagnostic on my elogd port. Would anyone have advice on what might be causing such errors?
tapajo [/usr/local/elog/elog-latest] openssl s_client -connect elog.hep.xxx.xxx.xx:80xx -state -nbio | grep "^SSL"
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
SSL_connect:unknown state
depth=0 C = EU, ST = SomeState, L = SomeCity, O = SomeOranization, OU = SomeOrganizationUnit, CN = localhost
verify error:num=18:self signed certificate
verify return:1
depth=0 C = EU, ST = SomeState, L = SomeCity, O = SomeOranization, OU = SomeOrganizationUnit, CN = localhost
verify return:1
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL_connect:error in unknown state
SSL_connect:error in unknown state
SSL_connect:unknown state
SSL_connect:unknown state
SSL handshake has read 1733 bytes and written 871 bytes
SSL-Session:
SSL3 alert read:warning:close notify
SSL3 alert write:warning:close notify
| Andreas Warburton wrote: |
|
The attached screenshot shows the behaviour after doing a synchronization (with Mirror simulate = 1) following first having ensured that the local (Mac) and remote (linux) ELOGs initially showed "All entries identical" when doing a simulated synchronization, and then having edited local entries 9707 and 9709 by uploading (different) attachments to them.
The fact that the synchronization is suggesting to renumber two different entry IDs to the same number looks like a bug.
Best regards,
Andreas W.
| Andreas Warburton wrote: |
|
My MacOS (10.12.2) elogd version V3.1.2 is a recent git commit (edc5e85), due to the fix to my earlier-described issue solved in the thread here: https://midas.psi.ch/elogs/Forum/68519.
I am trying to (re-)set up Mirror functionality with a linux server running the standard public (V3.1.2-bd75964). I had initially updated the linux server so that it also had the latest git commit (edc5e85), but could then not even add new logbook entries that involved attachments to it. I therefore rolled the linux server back to the standard public 3.1.2 version.
On the remote Mac, synchronizations usually look like they are going to work fine, with Mirror simulate = 1 switched on. After I set Mirror simulate = 0, and if the server and remote logbook are already identical, I *occasionally* get the proper "All Entries Identical" synchronization result. Unfortunately, this is very rare, and usually there is a failure whereby the remote (Mac) logbook decides that a significant fraction of its entries (usually sequential, from some seemingly random entry all the way up to the last entry) are missing on the linux server and need to be submitted back to the server from the remote Mac.
When the local and remote logbooks are not identical, and a record in need of synchronization contains an attachment, there is again destructive behaviour similar to that described above, except that the Mac elogd executable usually crashes. (As in the case of the already-identical synchronizations described above, I only tested this after observing the correct expected behaviour first with Mirror simulate = 1.)
I'd be grateful for some help/suggestions. My current testing suggests that my problems are likely not elog-content dependent. (The logbook now undergoing synching has less than 10 entries in it.)
More generally, the issue of having things behave fine with Mirror simulate = 1, but then experiencing corruption/damage when switching to Mirror simulate = 0 seems serious to me.
Many thanks, Andreas
|
|
|
|
68724
|
Sat Jan 27 03:37:11 2018 |
 | Peter K | pkravt@gmail.com | Bug report | Linux | V3.1.2-bd75964 | Entries disappear after editing | Dear elog community,
We have a problem with elog V3.1.2-bd75964.
Sometimes entries disappear from the list after editing.
I found them in the .log files with attributes
Locked by:
Draft:
But they are not in the list anymore!
The only solution by now is manually remove these two attributes from the file,
but this is terrible.
How can I fix this?
Thanks,
Peter.
|
|
68725
|
Mon Jan 29 09:14:35 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | V3.1.2-bd75964 | Re: Entries disappear after editing | Drafts are message which somebody started to edit, but did not complete, like leaving the page without saving. If you don't like this, you can set "save drafts = 0".
The locking has a similar background. If you have locking on (vis "Use lock = 1"), then one person can "lock" a message, and other then cannot edit the same message. If you don't want that, switch locking off.
Best,
Stefan
| Peter K wrote: |
|
Dear elog community,
We have a problem with elog V3.1.2-bd75964.
Sometimes entries disappear from the list after editing.
I found them in the .log files with attributes
Locked by:
Draft:
But they are not in the list anymore!
The only solution by now is manually remove these two attributes from the file,
but this is terrible.
How can I fix this?
Thanks,
Peter.
|
|
|
68726
|
Tue Jan 30 14:26:24 2018 |
| Peter K | pkravt@gmail.com | Bug report | Linux | V3.1.2-bd75964 | Re: Entries disappear after editing | Thanks for fast response!
I LIKE locking and saving drafts.
The only problem is that the locked message disappeared from the list.
This does not happen every time one left the editor, but sometimes.
I can send you the problematic message as it was disappeared, before I deleted Locked by and Draft attributes.
I can't imagine why it is not shown in the list.
| Stefan Ritt wrote: |
|
Drafts are message which somebody started to edit, but did not complete, like leaving the page without saving. If you don't like this, you can set "save drafts = 0".
The locking has a similar background. If you have locking on (vis "Use lock = 1"), then one person can "lock" a message, and other then cannot edit the same message. If you don't want that, switch locking off.
Best,
Stefan
| Peter K wrote: |
|
Dear elog community,
We have a problem with elog V3.1.2-bd75964.
Sometimes entries disappear from the list after editing.
I found them in the .log files with attributes
Locked by:
Draft:
But they are not in the list anymore!
The only solution by now is manually remove these two attributes from the file,
but this is terrible.
How can I fix this?
Thanks,
Peter.
|
|
|
|