Re: Syntax for conditional list display, posted by Andreas Luedeke on Wed Sep 30 09:28:39 2015
|
Hi Terry,
if you really want to do it, you can find a way to make it work. But it is not straight forward and not what ELOG is made for. Here some ideas how it could work:
- ELOG allows you to have different commands for different users. You could allow "New" and "Edit" for normal users, but "Reply" only for administrators.
- You can use "
Subst on reply <attribute> = <string>" to set a specifc fields only on reply.
- You would hide "status" & "assignee" for new entries or edit
(Show Attributes Edit = <list>), and show a "set status" field instead.
- The line "
Subst on reply status = $set status" would take care, that only an administrator can set "status" with a reply to the original entry (+ a "set assignee" field, etc.). While normal users could set "set status", it would not change the "status" field. You could provide a comment or tooltip to explain that.
- The list view or single entry view should not show the "set status", but only the "status" attribute (
List display = <list>, Show Attributes = <list>).
- Use "
Propagate attribute = status, assignee" to take care, that the original entry gets their fields set accordingly.
This is how you could do what you want. But bugzilla can do a lot more if you are looking for a bug tracking software.
Cheers, Andreas
| Terry L wrote: |
|
Hi Eddy,
Thank you for your response. I had a feeling that was the case, but I had high hopes! :) The reason I would like this feature is because I am trying to use ELOG as a software anomaly tracking log, where any user can create an ELOG and fill out "category", "computer" etc, but only administrators can fill out the "status" & "assignee". If I am lucky, this will be an added feature in a future revision.
Thanks again,
-Terry
| Edmund Hertle wrote: |
|
Hey Terry,
I don't think this is possible, since in general you cannot define config settings in a way that it would only affect specific users. For example, you also cannot have different themes for different users (as stated here: https://midas.psi.ch/elogs/Forum/68112 )
Cheers
eddy
| Terry L wrote: |
|
Good Morning,
I would like to limit the ability to edit certain attributes in an ELOG logbook, depending on the user who is logged in. I.e. if "guest" or a standard "login user" is logged in, I only want to allow the user to edit "attribute1" & "attribute2" of say, 5 attributes. However, if an Admin user or specific user, say "Terry" or "Bob" is logged in, I want to allow ALL 5 attributes to be editable. To expand on this, I may want to even limit the visibility of the attributes as well.
I've read though "Condition Attributes" section of the help page, but it is not clear to me how/if I can do this? Is that section even relevant to what I want to accomplish?
Can anyone provide some guidance?
Thank you for your time & help!
Sincerely,
Terry
|
|
|
|
Re: Syntax for conditional list display, posted by Andreas Luedeke on Thu Oct 1 12:01:11 2015
|
Oups: there is a flaw in this approach! You can only get different commands for Anonymous and Login Users. You cannot select different command for Admin users: they will just have the "Config" command automatically.
You could allow anonymous users to make new entries and restrict login to administrators. But that is certainly not what you want, so forget my suggestion altogether.
| Andreas Luedeke wrote: |
|
Hi Terry,
if you really want to do it, you can find a way to make it work. But it is not straight forward and not what ELOG is made for. Here some ideas how it could work:
- ELOG allows you to have different commands for different users. You could allow "New" and "Edit" for normal users, but "Reply" only for administrators.
- You can use "
Subst on reply <attribute> = <string>" to set a specifc fields only on reply.
- You would hide "status" & "assignee" for new entries or edit
(Show Attributes Edit = <list>), and show a "set status" field instead.
- The line "
Subst on reply status = $set status" would take care, that only an administrator can set "status" with a reply to the original entry (+ a "set assignee" field, etc.). While normal users could set "set status", it would not change the "status" field. You could provide a comment or tooltip to explain that.
- The list view or single entry view should not show the "set status", but only the "status" attribute (
List display = <list>, Show Attributes = <list>).
- Use "
Propagate attribute = status, assignee" to take care, that the original entry gets their fields set accordingly.
This is how you could do what you want. But bugzilla can do a lot more if you are looking for a bug tracking software.
Cheers, Andreas
| Terry L wrote: |
|
Hi Eddy,
Thank you for your response. I had a feeling that was the case, but I had high hopes! :) The reason I would like this feature is because I am trying to use ELOG as a software anomaly tracking log, where any user can create an ELOG and fill out "category", "computer" etc, but only administrators can fill out the "status" & "assignee". If I am lucky, this will be an added feature in a future revision.
Thanks again,
-Terry
| Edmund Hertle wrote: |
|
Hey Terry,
I don't think this is possible, since in general you cannot define config settings in a way that it would only affect specific users. For example, you also cannot have different themes for different users (as stated here: https://midas.psi.ch/elogs/Forum/68112 )
Cheers
eddy
| Terry L wrote: |
|
Good Morning,
I would like to limit the ability to edit certain attributes in an ELOG logbook, depending on the user who is logged in. I.e. if "guest" or a standard "login user" is logged in, I only want to allow the user to edit "attribute1" & "attribute2" of say, 5 attributes. However, if an Admin user or specific user, say "Terry" or "Bob" is logged in, I want to allow ALL 5 attributes to be editable. To expand on this, I may want to even limit the visibility of the attributes as well.
I've read though "Condition Attributes" section of the help page, but it is not clear to me how/if I can do this? Is that section even relevant to what I want to accomplish?
Can anyone provide some guidance?
Thank you for your time & help!
Sincerely,
Terry
|
|
|
|
|
Re: Synchronizing mirror causes corruption of logbook entries with multiple logbooks defined?, posted by Andreas Luedeke on Fri Sep 3 14:43:16 2010
|
| Glenn Horton-Smith wrote: |
|
We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it? [...]
I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized. This suggests it isn't specific to Linux architecture, 64-bit or otherwise.
|
We plan to use ELOG with mirror servers in a larger scale here, so I'm interested to know more about your problem.
Could you boil down your configuration to a minimum that still allows a reproduction of the problem and post those configurations as attachments?
Then I would try to reproduce it here. Best case I'll find a bug fix, worst case I'll reconsider the use of mirror servers ;-) |
|
Re: Synchronizing mirror causes corruption of logbook entries with multiple logbooks defined?, posted by Renee Poutissou on Fri Sep 3 19:04:46 2010
|
| Andreas Luedeke wrote: |
|
| Glenn Horton-Smith wrote: |
|
We have been experiencing corruption of logbook entries by elogd mirror synchronization. Has anyone else encountered this? Is there a known cause and/or workaround for it? [...]
I made copies of both servers' files and ran two elogd servers on my Mac on different ports, compiled from a fresh checkout of 2.8.0, and the same behavior was observed as I repeatedly made test entries and synchronized. This suggests it isn't specific to Linux architecture, 64-bit or otherwise.
|
We plan to use ELOG with mirror servers in a larger scale here, so I'm interested to know more about your problem.
Could you boil down your configuration to a minimum that still allows a reproduction of the problem and post those configurations as attachments?
Then I would try to reproduce it here. Best case I'll find a bug fix, worst case I'll reconsider the use of mirror servers ;-)
|
I have been using the mirror mechanism for one year for the online T2K /ND280 (neutrino oscillation experiment at J-PARC, Japan). It has been a savior to allow access to all collaborators to the Elog. The experiment online computers are all behind a double firewall that allow only communication through ssh and http in one direction: from the inside to the outside. The master Elog is located in Canada and accessible remotely to all collaborators. The mirror Elog is located inside the firewall on one of the online machines in Japan and synchronization is setup to run automatically every 5 minutes. There are 10 logbooks defined for each of the sub-detector groups.
At first I encountered a big problem when messages were added on both sides. It turned out that Elog mirroring does not work when the two instances are running on different time zones. After I set the machine in Canada to run on Japan time (JST), no further problems have happened. Postings are routinely entered on either of the Elogs and synchronization works well. This feature is essential to having a workable Elog for the T2K experiment.
I had reported the problem of timezones to Stefan last year. He was going to put it on his wish list.
|
|
Re: Synchronization using https, posted by Stefan Ritt on Thu Jan 18 20:19:22 2007
|
| Alexandre Lindote wrote: | | Now we want to have several servers set up (in different institutions), and have them synchronized automatically. |
Synchronization works such that the "client" elogd (the one on which the synchronization is started) "emulates" a browser and accesses the other elogd server. Since SSL is not built into elogd, it can only use the http protocol, not https. If you want secure synchronization, the only chance you have is to make a SSH tunnel on which you run the http protocol for synchronization. |
Re: Synchronization using https, posted by Marcus Hauser on Tue Feb 13 15:11:18 2007
|
| Stefan Ritt wrote: |
| Alexandre Lindote wrote: | | Now we want to have several servers set up (in different institutions), and have them synchronized automatically. |
Synchronization works such that the "client" elogd (the one on which the synchronization is started) "emulates" a browser and accesses the other elogd server. Since SSL is not built into elogd, it can only use the http protocol, not https. If you want secure synchronization, the only chance you have is to make a SSH tunnel on which you run the http protocol for synchronization. |
Would it be possible to use rsync to syncronise two elogd servers on different servers via secure synchronization on the file level?
E.g.
rsync -av -e ssh /var/lib/elog/logbooks/ elog.remote.de:/var/lib/elog/logbooks/ |
|
Re: Synchronization using https, posted by Stefan Ritt on Tue Feb 13 15:36:08 2007
|
| Marcus Hauser wrote: | Would it be possible to use rsync to syncronise two elogd servers on different servers via secure synchronization on the file level?
E.g.
rsync -av -e ssh /var/lib/elog/logbooks/ elog.remote.de:/var/lib/elog/logbooks/ |
Do do this, you have to do the following:
- Stop both elogd servers on each side
- Do the rsync
- Restart the elogd servers
This is necessary because an elogd server does not rescan the database files unless it's restarted. Note that you only can synchronize on a day level. Like if in a single day new entries are made on both sides, you have a conflict. This is not the case if you do the internal elogd synchronization, because this works on an entry level (actually that was the reason why this internal synchronization was invented). So new entries on both sides which were made as the same day will be merged intelligently. |
|
Re: Synchronization Problems, posted by Stefan Ritt on Fri Sep 7 22:31:10 2007
|
| Nicole Ackerman wrote: | I'm currently running elog 2.6.5 on my (feisty ubuntu) laptop and desktop. I set up mirroring between the two which usually works, but occasionally I get an error (when sending from laptop to desktop) :
"Enty too long to display. Please increase TEXT_SIZE and recompile elogd."
When this happens my entry is shortened to 3 characters. This is frustrating as I have lost many important entries. I'm unsure why this is happening - they aren't the longest entries in my logbook (one was a one line linux command) and there doesn't seem to be anything "special" about the ones that do and do not sync. The last time I tried to sync I got this error on 3 entries and they appear to be corrupted - when I try to access them elogd stops responding.
On a presumably related note, every time I try to send an entry from my laptop to my desktop I get "Error sending local entry: Error transmitting message", though the entry has appeared to sync properly. I don't think I have ever had a problem transmitting from my desktop to my laptop.
Currently the only mirroring option I have added to my config file in on my laptop which is the IP of my desktop as the Mirror server.
I'm unsure what else I could post to help troubleshoot this problem - is it just something I've done wrong or that could be fixed with a reinstall?
|
I'm sorry for your trouble. The key to understand and fix this problem is reproducibility. Can you identify an entry which causes this error (of course back up the entry before trying). Then create a fresh logbook where you put only this entry. If you can reproduce the problem, can you send me that entry, together with your config files? Only if I can reproduce your problem, I can fix it.
Best regards,
Stefan |
|