TOPIC:

Hi all,

I've been trying to get to the bottom of this problem since the beginning of October, and have implemented changes to permissions on the USER-FILES folder as suggested by John Smith; the permissions were 0755, with folder ownership set to root:root. It is now 0777, with folder ownership set to www-data:www-data. I also made the changes apply to sub-folders and files, which fixed the problem for most users except one (that I know of so far).

For the user who it did not work for (in the sense that newly created Learning Objects (LO's) were not editable), I ended up renaming the login name in MySQL to first.last_old, and asked the user to login, leaving Xerte to generate a new login ID for the user.

I then transferred ownership of all LO's that belonged to the user's old login by going to the templatedetails and folderdetails tables in the xertetoolkits database and changing the number of the login ID from the old one to the new one. The only folders that were not touched were the home and recycle ones belonging to the old login ID. This didn't really help matters, so I asked the user to logon to a copy of the Xerte website taken prior to upgrading to version 3.5.

The affected LO was editable in the version before the upgrade to 3.5, and so I exported it as an archived zip so that I could import it for editing in version 3.5. It didn't work; after importing the archived file, it still wasn't possible to edit it.

Is anybody able to offer any advice on how to get LO's created in the earlier versions of Xerte to be editable in the latest version, as the user has created quite a number of LO's, and it would be a shame if all LO's had to be recreated from scratch, as a lot of time has been invested in creating the material?

Thanks in advance for your help,

Chi-Phu

Hi,

Did you change templaterights as well for the user?

So many things happened, that it will be difficult to give an easy answer. Can a different user import the archived zip files?

If so, there is still something wrong with the user information in the database.

I assume you did run upgrade.php after the upgrading to 3.5.

Hi
I suspect you are mixing up two separate issues here.
It sounds like you've resolved the folder permissions although 0755 should be ok as long as the owner:group is the Apache user which in your case is www-data:www-data.

I could be wrong but I suspect the issue for the user is a separate problem that sometimes crops up with case sensitivity of usernames. Make sure the username in the database matches the username that is created as part of project folders in USER-FILES.

Any LO exported from a previous install should work fine when imported into 3.5 but you shouldn't need to do that. I would revert the username back to the original but if you've messed with other database values you need to be very careful.

Hi Tom,

Thanks for your reply.

I couldn't change values within templaterights in MySQL, as that table does not have a primary key.

And yes, I had to upgrade the database twice, probably because the installation of Xerte was a couple of versions out when the upgrade took place. It's currently at version 10.

I have since reverted the database back to the state before I recreated the login details for the affected user - this was done about ten minutes ago.

Hi Ron,

Thanks for your reply.

I'll speak to the user tomorrow, and check that the case sensitivity matches the folder name of the affected login.

I have also reverted the database back to the state before I recreated the Xerte login for the affected user, so we're back to the position where we started. Like Tom said earlier, there has been so many changes made, that it's going to be confusing keeping track of what has been done.

Hi Chi-Phu
That sounds like a good step to revert back to before you made changes to the database - assuming no users were creating projects in-between!

Between us Tom and I have installed and upgraded a large number of installations without problem but clearly the wider problem you had was with directory permissions which you’ve now resolved.

We have experienced an occasional issue where an individual user is not able to create projects or edit previous projects and yet all other users can and that’s the case sensitivity issue I mentioned. Usually making sure that the username and project folders match resolves the issue as long as there is not more than one account in the database with the same username.

Tom asked if other users can import the zip files. That’s because it’s likely that they can and that your issue remains with this single user. If you’ve been recursively changing permissions in USER-FILES make sure that you haven’t somehow missed the relevant project folders for this user and also make sure the permissions are the same for the import folder too.

HTH
Ron