Moodle

mdl_data's defaultsort ID not set properly at importing preset.zip

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.8.5, 1.9
  • Fix Version/s: 1.9.1
  • Labels:
    None
  • Database:
    MySQL
  • Affected Branches:
    MOODLE_18_STABLE, MOODLE_19_STABLE
  • Fixed Branches:
    MOODLE_19_STABLE

Description

When a preset.zip is imported, values from its preset.xml's <settings></settings> section will be written into the DB table mdl_data. One of these imported settings is the ID number of the field that should act as default sort key. Let's call this ID "PRESETSORTID". It is specified as
<defaultsort>PRESETSORTID</defaultsort>.

The smallest value of the id field of the appropriate mdl_data_fields SQL table is the ID number of the first field, let's call it FIRSTID. If you create a new database activity using a preset and completely delete that activity and re-create it, FIRSTID changes (increases).

The defaultsort field of the appropriate mdl_data SQL table should be filled with
DEFAULTSORTID = FIRSTID + PRESETSORTID -1, however it just gets filled with
DEFAULTSORTID = PRESETSORTID.

This prevents us setting the default sort field using a preset.zip. This is bad because there is currently no other way than using a preset. We only can set the default sort direction (<defaultsortdir>0=ascending or 1=descending</defaultsortdir>), but the default sort field currently is always the Date entered. This does not make sense in many cases.

Activity

Hide
Robert Allerstorfer added a comment -

The attached patch against MOODLE_19_STABLE fixes this bug. It would be nice to see it committed.

It allows to use

<defaultsort>1</defaultsort>

within a "preset.xml" packed into a "preset.zip" for getting the first field (field number 1) the default sort field. If the second field should be the default sort field, specify

<defaultsort>2</defaultsort>

and so on. The field numbers are counted as they appear in "preset.xml".

I'm very happy with that now

Show
Robert Allerstorfer added a comment - The attached patch against MOODLE_19_STABLE fixes this bug. It would be nice to see it committed. It allows to use <defaultsort>1</defaultsort> within a "preset.xml" packed into a "preset.zip" for getting the first field (field number 1) the default sort field. If the second field should be the default sort field, specify <defaultsort>2</defaultsort> and so on. The field numbers are counted as they appear in "preset.xml". I'm very happy with that now
Hide
Petr Škoda (skodak) added a comment -

the problem is that the 1,2 are different if you restore on a diffrent site, I saw some commnets about this by Penny in some other bug - we should IMHO store this in the definition of the field instead

Show
Petr Škoda (skodak) added a comment - the problem is that the 1,2 are different if you restore on a diffrent site, I saw some commnets about this by Penny in some other bug - we should IMHO store this in the definition of the field instead
Hide
Robert Allerstorfer added a comment -

The order of the fields within preset.xml will be kept at importing preset.zip, on all sites. Please take a look into my patch - it resolves 1,2,3,... into the actual field ID. This little patch is very handy for me and does not make any problems in the 1.9 branch.

Show
Robert Allerstorfer added a comment - The order of the fields within preset.xml will be kept at importing preset.zip, on all sites. Please take a look into my patch - it resolves 1,2,3,... into the actual field ID. This little patch is very handy for me and does not make any problems in the 1.9 branch.
Hide
Petr Škoda (skodak) added a comment -

fixed in cvs, thanks for the report!

Show
Petr Škoda (skodak) added a comment - fixed in cvs, thanks for the report!
Hide
Robert Allerstorfer added a comment -

Thanks for this nice improvement - now we can use the field's name instead of a number to specify the default search field - very user friendly.

A last thing related to the search field is that the automatically generated drop down list cannot be modified in any way, such as the asearchtemplate. There are always all user defined fields, which are sorted alphabetically, plus "Date entered" - always on top, plus "Author first name" + "Author surname" - always at the bottom, as shown in the two attached screenshots.

IMO, it would be logical to have at least all the user defined fields appearing first, and afterwards (maybe after a borderline), the 3 not user defined fields, so a user won't get too much confused. What do you think?

Show
Robert Allerstorfer added a comment - Thanks for this nice improvement - now we can use the field's name instead of a number to specify the default search field - very user friendly. A last thing related to the search field is that the automatically generated drop down list cannot be modified in any way, such as the asearchtemplate. There are always all user defined fields, which are sorted alphabetically, plus "Date entered" - always on top, plus "Author first name" + "Author surname" - always at the bottom, as shown in the two attached screenshots. IMO, it would be logical to have at least all the user defined fields appearing first, and afterwards (maybe after a borderline), the 3 not user defined fields, so a user won't get too much confused. What do you think?
Hide
Petr Škoda (skodak) added a comment -

Thanks Robert, it was addressed in MDL-14458

Show
Petr Škoda (skodak) added a comment - Thanks Robert, it was addressed in MDL-14458
Hide
Robert Allerstorfer added a comment -

Thanks Petr, now it looks perfect

Show
Robert Allerstorfer added a comment - Thanks Petr, now it looks perfect
Hide
Mathieu Petit-Clair added a comment -

Tested & closed.

Show
Mathieu Petit-Clair added a comment - Tested & closed.

Dates

  • Created:
    Updated:
    Resolved: