Re: Howto force users to supply an email address when registering?, posted by Johan Nyberg on Sat Oct 22 00:21:03 2005
|
| Stefan Ritt wrote: |
| Johan Nyberg wrote: | | Is there a way to force the users to supply an email address when they register? |
I will happily implement such an email check if you supply me further information. Presume you enter an email address in the form user#domain.com (# instead @). Does your SMPT server then complain, too? What about user@com (without "domain.")? If you check all possibilities and let me know, I will put it in. |
Hi Stefan,
Sorry for the delayed reply. I have run some tests which I will send to you by email.
Johan |
Prefill attributes for new post, posted by Johan Forsberg on Tue Jan 12 11:35:55 2016
|
Hi all,
I have a use case for ELOG where I need to be able to "prefill" some attributes in the "cmd=new" form, based on the URL.
To illustrate, imagine a link that takes the user directly to the form for creating a new post, with the "Subsystem" attribute already filled out to "Vacuum".
Is this possible already? I've tried naively using URL parameters (e.g. "&Subsystem=Vacuum") but that does not work. If it's not implemented, I think it would be a useful feature to have (and quite important for my particular use case). I could create a new post first using the "elog" tool, with the desired attributes set, but it makes more sense to defer the actual creation of the post to the user, i.e. he/she might change their mind before pressing "submit".
Thanks,
Johan Forsberg, MAX IV Laboratory, Sweden |
|
Re: Prefill attributes for new post, posted by Johan Forsberg on Tue Jan 12 14:05:55 2016
|
Wow, than you both for the quick response! I agree it's quite a hidden gem, but the most important thing is that it works, thanks!
| Stefan Ritt wrote: |
|
Put a "p" in front of the attribute, like "&pSubsystem=Vacuum". This is kind of an undocumented feature just for the experts ;-)
| Johan Forsberg wrote: |
|
Hi all,
I have a use case for ELOG where I need to be able to "prefill" some attributes in the "cmd=new" form, based on the URL.
To illustrate, imagine a link that takes the user directly to the form for creating a new post, with the "Subsystem" attribute already filled out to "Vacuum".
Is this possible already? I've tried naively using URL parameters (e.g. "&Subsystem=Vacuum") but that does not work. If it's not implemented, I think it would be a useful feature to have (and quite important for my particular use case). I could create a new post first using the "elog" tool, with the desired attributes set, but it makes more sense to defer the actual creation of the post to the user, i.e. he/she might change their mind before pressing "submit".
Thanks,
Johan Forsberg, MAX IV Laboratory, Sweden
|
|
|
|
Monitoring a logbook for changes, posted by Johan Forsberg on Tue Jan 12 15:06:42 2016
|
Hi again!
I've another need that you probably already thought of :)
I'd like to be able to efficiently monitor a logbook for changes (new or edited posts) somehow. The most reasonable way I've found so far is to periodically poll a search that looks for posts after the time of the last poll. But that might note be very efficient, especially if the polling period gets short (or number of clients grows).
Is there some other feature that could be used for this? I was thinking maybe the ETag or Last-Modified HTTP header field could be used to show changes to a logbook by just reading the headers, but it would also require HEAD request support which does not seem to be there.
Cheers,
Johan |
|
Re: Monitoring a logbook for changes, posted by Johan Forsberg on Wed Jan 13 10:27:21 2016
|
Yeah, I found the RSS feed feature, but I could not get ETags/Last-Modified header fields which meant that I'd have to read and parse the entire feed every time. Maybe I made a mistake and they do work, but if not, I think it would make sense to implement as it should save work for both the server and the client.
| Johan Forsberg wrote: |
|
Hi again!
I've another need that you probably already thought of :)
I'd like to be able to efficiently monitor a logbook for changes (new or edited posts) somehow. The most reasonable way I've found so far is to periodically poll a search that looks for posts after the time of the last poll. But that might note be very efficient, especially if the polling period gets short (or number of clients grows).
Is there some other feature that could be used for this? I was thinking maybe the ETag or Last-Modified HTTP header field could be used to show changes to a logbook by just reading the headers, but it would also require HEAD request support which does not seem to be there.
Cheers,
Johan
|
|
|
Re: Monitoring a logbook for changes, posted by Johan Forsberg on Wed Jan 13 10:29:54 2016
|
Yeah, I suppose something like that would be both faster and more efficient than polling ELOG itself. Fortunately the ELOG disk format looks easily parsed.
Thanks for the pointer!
| Tamas Gal wrote: |
|
I recommend monitoring directly on the server. Here is an example of a very simply Python script (https://github.com/tamasgal/elog-slack) which monitors the files very efficiently and immediately pushes notifications to Slack (slack.com). Just look at the code, it's pretty straight forward and very easy to adapt it to other (web) services.
Btw. here is an ELOG entry of it https://midas.psi.ch/elogs/Forum/68224
| Johan Forsberg wrote: |
|
Hi again!
I've another need that you probably already thought of :)
I'd like to be able to efficiently monitor a logbook for changes (new or edited posts) somehow. The most reasonable way I've found so far is to periodically poll a search that looks for posts after the time of the last poll. But that might note be very efficient, especially if the polling period gets short (or number of clients grows).
Is there some other feature that could be used for this? I was thinking maybe the ETag or Last-Modified HTTP header field could be used to show changes to a logbook by just reading the headers, but it would also require HEAD request support which does not seem to be there.
Cheers,
Johan
|
|
|
|
Re: Monitoring a logbook for changes, posted by Johan Forsberg on Wed Jan 13 20:08:04 2016
|
Aha, that's interesting too! I'll have to look more carefully through the documentation... :)
| Stefan Ritt wrote: |
|
You guys know that there is the possibility to execute an arbitrary script on each submission of a new messge? Just use "Execute new = <script>". In the script you have access to all parameters of the message. That's maybe simple than to watch the file set.
| Tamas Gal wrote: |
|
I just noticed that there are multiple messages per file, so I have to adapt the parser. I'll update this thread when I'm done!
| Johan Forsberg wrote: |
|
Yeah, I suppose something like that would be both faster and more efficient than polling ELOG itself. Fortunately the ELOG disk format looks easily parsed.
Thanks for the pointer!
| Tamas Gal wrote: |
|
I recommend monitoring directly on the server. Here is an example of a very simply Python script (https://github.com/tamasgal/elog-slack) which monitors the files very efficiently and immediately pushes notifications to Slack (slack.com). Just look at the code, it's pretty straight forward and very easy to adapt it to other (web) services.
Btw. here is an ELOG entry of it https://midas.psi.ch/elogs/Forum/68224
| Johan Forsberg wrote: |
|
Hi again!
I've another need that you probably already thought of :)
I'd like to be able to efficiently monitor a logbook for changes (new or edited posts) somehow. The most reasonable way I've found so far is to periodically poll a search that looks for posts after the time of the last poll. But that might note be very efficient, especially if the polling period gets short (or number of clients grows).
Is there some other feature that could be used for this? I was thinking maybe the ETag or Last-Modified HTTP header field could be used to show changes to a logbook by just reading the headers, but it would also require HEAD request support which does not seem to be there.
Cheers,
Johan
|
|
|
|
|
|
Port specification with -p fails under RedHat Linux (2.0.4-1), posted by Joeri Mastop on Mon Jul 15 14:09:30 2002
|
Hello,
I noticed a strange behaviour with Elog 2.0.4 (i386 RPM) in Linux (RH 7.2).
I started Elog out-of-the-box with portnumber 888 ('sbin/elogd -p 888').
It runs just fine, but appears to listen to port 8080, the default! It
looks like the -p option on the command-line is ignored.
Anyone seen similar problems?
Joeri |
|