Hi Stefan,

Andreas

Just an update: I've re-compiled, reinstalled and restarted elogd for other reasons and now the corrupted strings are all gone. Everthing looks fine now.

But I never worry when a problem goes away before I could understand it: I'm confident that I will have plenty of time later, when the problem magically re-appears - likely I'll be called on a Friday night :-)

In response to an elog-hang issue I've been having on the Windows platform, I am building a new Unbuntu 14 TLS VM machine to host the identical configuration so that I can more easily debug when the hang happens again. I don't mind beefing up the hardware resources to either eliminiate that as a factor or resolve the problem. I'll have a higher end CPU to deal with 20 to 50 clients doing searches through the data (since the elog configuration currently does not provide a setting to limit how far back it can search with Quick Filters - pretty please add this basic setting!), but the main question I have now is what is a good amount of memory to add to the VM? I suspect even with 30 concurrent searches going CPU power will have more impact than memory in the case of elog. Can someone please confirm my suspicion and also recommend a suitable amount of memory I should install? My data volume is about 25 MB, all textual (no attachmemts), and the number of daily files goes back about 5 years. Any other tips for the build is very welcome.

Hi Alan,

Cheers, Andreas

My elog has a field for entering a list of email addresses, which goes into the "Email All" attribute. They need to be comma-separated, and an error is thrown if semicolons are used instead. Would it be possible to automatically change semicolons into commas before attempting to send the mail via SMTP? Neither character is allowed in email addresses so it shouldn't break anything to just do that silently. Thanks!

Dear experts,
   I have an elog with an attribute with fixed values, like this:

Attributes = Half
Options Half = +x, -x, both

It works fine, but I would like to find (or quick filter) all entries with Half=+x .

If I go to the search form, I can select +x from the dropdown menu for Half, but the search returns no result, even if I do have a number of entries with Half=+x. Likewise if I try to do the same with Quick filter.

I believe that this is due to the fact that the search uses regex, and "+" is reserved. I've tried to perform a search by entering manually and escaped "\+x", and it works as intended.

https://.../?mode=summary&reverse=0&reverse=1&npp=20&Half=%5E%5C%2Bx%24

However, since this attribute has a list of fixed values, it is not possible to entry manually something different "\+x" than what is defined in the config, that is "+x".

Is there a solution for this problem?

I would rather not change the attributes options (to, say, positive/negative), since that would mean changing manually a non negligible number of entries.

thanks,
  Stefano

Hi Stefano,
you could try to html encode the "+" and "-" sign in the option list
Options Half = +x, -x, both
Allow HTML = 1

But of course then you would need to change all existing entries.

It is just an idea; I did not try this out, it might not work anyway.

Cheers
Andreas

> Dear experts,
>    I have an elog with an attribute with fixed values, like this:
> 
> Attributes = Half
> Options Half = +x, -x, both
> 
> It works fine, but I would like to find (or quick filter) all entries with Half=+x .
> 
> If I go to the search form, I can select +x from the dropdown menu for Half, but the search returns no result, even if I do have a number of entries with Half=+x. Likewise if I try to do the same with Quick filter.
> 
> I believe that this is due to the fact that the search uses regex, and "+" is reserved. I've tried to perform a search by entering manually and escaped "\+x", and it works as intended.
> 
> https://.../?mode=summary&reverse=0&reverse=1&npp=20&Half=%5E%5C%2Bx%24
> 
> However, since this attribute has a list of fixed values, it is not possible to entry manually something different "\+x" than what is defined in the config, that is "+x".
> 
> Is there a solution for this problem?
> 
> I would rather not change the attributes options (to, say, positive/negative), since that would mean changing manually a non negligible number of entries.
> 
> thanks,
>   Stefano

Hi Stefano,
I've tested it: it does not work.
Neither in edit nor in list view the HTML encoded characters show correctly.
Only in the "Quick filter" menu they show as they should!
But then selecting them in the quick filter will not find any entries :-(

So the short answer: 
avoid characters with a special meaning for regular-expressions in attribute values, in particular if you want to use quick filters.

Cheers
Andreas

> Hi Stefano,
> you could try to html encode the "+" and "-" sign in the option list
> Options Half = +x, -x, both
> Allow HTML = 1
> 
> But of course then you would need to change all existing entries.
> 
> It is just an idea; I did not try this out, it might not work anyway.
> 
> Cheers
> Andreas
> 
> > Dear experts,
> >    I have an elog with an attribute with fixed values, like this:
> > 
> > Attributes = Half
> > Options Half = +x, -x, both
> > 
> > It works fine, but I would like to find (or quick filter) all entries with Half=+x .
> > 
> > If I go to the search form, I can select +x from the dropdown menu for Half, but the search returns no result, even if I do have a number of entries with Half=+x. Likewise if I try to do the same with Quick filter.
> > 
> > I believe that this is due to the fact that the search uses regex, and "+" is reserved. I've tried to perform a search by entering manually and escaped "\+x", and it works as intended.
> > 
> > https://.../?mode=summary&reverse=0&reverse=1&npp=20&Half=%5E%5C%2Bx%24
> > 
> > However, since this attribute has a list of fixed values, it is not possible to entry manually something different "\+x" than what is defined in the config, that is "+x".
> > 
> > Is there a solution for this problem?
> > 
> > I would rather not change the attributes options (to, say, positive/negative), since that would mean changing manually a non negligible number of entries.
> > 
> > thanks,
> >   Stefano