View Issue Details

IDProjectCategoryView StatusLast Update
16427Feature requestsErgonomypublic2020-07-02 12:49
Reporterrudydehaas Assigned To 
Status newResolutionopen 
Summary16427: Feature requests: standardized logs and continued GUI improvement
DescriptionA couple of weeks ago I had to stop what I was working on for a few weeks. Unfortunately, my wife found work for idle hands and asked me to look at a problem the university here has - one limesurvey (a tool I have used before and like a lot) is well suited to help with.

Installed from the 4.2.5 and 4.2.8 tar files on debian with gnome/firefox it has two deeply frustrating, but ultimately trivial problems:

1 - no error log. Yes debug=1/2 helps, but it takes a week of scouring the docs to find it - what's wrong with doing what
everyone else does: /var/log/lime/error.log by default? Hosting services simply remap these to user spaces so everyone knows where the default logs are.

The bug turned out to be that some text messages and/or boxes in the gui simply don't show so the user sees nothing to tell him what's expected, that something is expected, or what's gone wrong - and when I reported an example consequence of the bug in operation, your bug reporting system silently deleted four of the five screen shots I uploaded because, apparently, it is limited to very small images.

So, please, could Limesurvey get a documented default error log?

And maybe increase the image size allowed on the bug reporting system?

2 - my last serious use of limesurvey was version 2.something and many years ago. The new interface in 4.X is much better (Many Thanks!) however it still has some things to leave a unix user bewildered. For example, I've got 500 faked users in my test CPDB table - display them to move a few to a test survey and the control for that is at the bottom of the screen five pages down - not the top. Took me two hours to find it.

So, please, could you continue the good work in making the GUI layout consistent? and think about the layout in terms of operations on larger numbers: several hundred at a time, not 10.
TagsNo tags attached.




2020-06-25 15:19

developer   ~58458

About default error log : in my opinion we **must not** activate by default. Because default directory is web accessible. We use some `thaccess` for apache, but no way for IIS or nginx. **Terrible** security issue to let log to be readed.

Debug = 2 are not for log :)

maybe we can :
1. Add 'fileError' in internal.php
2. but : set [enable]( to false
3. Put the information in config.php file

Can be part of (need to find times on this one)


2020-06-25 15:19

developer   ~58459

Else : think there are 2 different issue here.


2020-06-25 17:25

reporter   ~58484

Maybe you could meet both the security issue and user perception by checking what you're installing on:

if (host = some_unix -linux, android, macos etc) { default log on and located in /var/log/limesurvey/ }
else {log off and goes to ~\tmp\runtime if turned on by the user.}


2020-06-25 18:15

developer   ~58494

Lol … no …

Too complex and subject to error in some week.
Since it's easy to update in config.php

My opinion : is :
1. Allow set runtime path when install
2. Add the information about log

`if (host = some_unix -linux, android, macos etc) { default log on and located in /var/log/limesurvey/ }` no, really no … you can have 500 step of limesurvey on same server. log emplacement can not be auto-dermtimate : it's the admin guys to decide .


2020-06-25 18:16

developer   ~58495

PS: php error log still there


2020-06-25 18:38

reporter   ~58497

you say:
My opinion : is :

    Allow set runtime path when install
    Add the information about log
I like that - assuming you include letting the installer set (or at least see) the log path as part of setting the run-time path and then set debug levels interactively.

I have been using Opensocial (drupal, not MS - - ) in a social experiment for some time. Their version of the multi-admin problem is that the opensocial host admin creates many sub-admins each of whom is responsible for one ore more user groups. To accommodate their needs to see error msgs generated by their actions without giving them access to the full log, the opensocial developers (like many drupal users) allow the host admin to specify that log msgs go in the database. Sub-admins then access their own error msgs via the normal gui interface.


2020-06-25 18:46

developer   ~58498

> that log msgs go in the database

Sincerely : i let this for plugin , and here : you talk for a plugin to drupal with specific part and log part …


2020-06-25 18:53

reporter   ~58499


je ne comprends pas..

(If you mean you once proposed a plugin to do this, you're way ahead of me and I hope the Limesurvey developers accept the idea. )


2020-06-25 19:10

developer   ~58501

No : i mean : not in core, it must not be in core.

Since it's not so difficult to do it in plugin.

I never talk to other LimeSurvey dev to add a DB for log.

Issue History

Date Modified Username Field Change
2020-06-25 14:00 rudydehaas New Issue
2020-06-25 15:19 DenisChenu Note Added: 58458
2020-06-25 15:19 DenisChenu Note Added: 58459
2020-06-25 17:25 rudydehaas Note Added: 58484
2020-06-25 18:15 DenisChenu Note Added: 58494
2020-06-25 18:16 DenisChenu Note Added: 58495
2020-06-25 18:38 rudydehaas Note Added: 58497
2020-06-25 18:46 DenisChenu Note Added: 58498
2020-06-25 18:53 rudydehaas Note Added: 58499
2020-06-25 19:10 DenisChenu Note Added: 58501