05 November 2010, 20:43

Im having real problems with Mahara
Firstly some of my Views do not show up and yes I have added access
Year 10 View
Secondly all my Flash and Word documents do not open Access denied
I was able to retrieve most except my Year 11View
Can you please help me

06 November 2010, 1:07

Cynds here

• Views Access is not enabled. I save the access and when I reopen the View it vanishes
• Files have access denied Can anyone help??????????????????

09 November 2010, 13:16

Hi Cynds,

I doubt that anybody is able to help you with the information you provided. As I said in my emails, we are looking into the problem, but please be patient. mahara.org is not a hosted portfolio site like FolioSpaces for example, but the community site to discuss everything around Mahara.

Cheers

Kristina

17 November 2010, 15:13

I too am a little frustrated by this. I've read and only partly understood other threads on this topic. I'll give what I've found so far. Our installation is running Mahoodle with SSO, Mahara 1.3.2 with Moodle 1.9.9+ on a WAMP platform (Windows/Apache/MySQL/PHP).

This problem, for us, is very sporadict, and always involves attempting to drill down into sub-folders through a view. The latest example (a student view submitted to a teacher) has the following details:

• Our students have a "portfolio" folder in which sub-folders live for specific subject areas. This folder was dropped into a vew (crude, but I wasn't in charge of that design decision). Teachers drill down through it into the subject area folders, and then to specific files. In the last student view I looked at, a file in one sub-folder opened fine, whereas another did not.
• The "Access denied" was accompanied by an "Artefact 44675 not in View 697" message immediately below. Both the artefact and view #'s are real, existing in the student's view and files areas. If I downloaded, deleted, and re-uploaded...still no help.
• If I drop the subject area folder into the view (the subfolder through which the teacher drilled down), the file contained in it is suddenly available through both folders -- no errors. If I remove the subject area folder, the "Access denied" message returns.
• The "Access denied" message occurs for me (Mahara admin), the teacher, and the student. Access to the file through "Files" is fine.

PHP-Errors.log shows this error as the most recent entry after my last error message. Don't know if it's related...

17-Nov-2010 14:55:15] [WAR] 18 (E:\www\inetwork\auth\xmlrpc\lib.php:382) Undefined index: HTTP_REFERER
[17-Nov-2010 14:55:15] Call stack (most recent first):
[17-Nov-2010 14:55:15]   * log_message("Undefined index: HTTP_REFERER", 8, true, true, "[local Mahara pathway]\auth\xmlrpc\lib.php", 382) at "[local Mahara pathway]\lib\errors.php:444
[17-Nov-2010 14:55:15]   * error(8, "Undefined index: HTTP_REFERER", "[local Mahara pathway]\auth\xmlrpc\lib.php", 382, array(size 19)) at "[local Mahara pathway]\auth\xmlrpc\lib.php:382
[17-Nov-2010 14:55:15]   * AuthXmlrpc->request_user_authorise("01f8cc3dbdc16c472270575e769ef9292e5754f8", "http://ischool.fcps.net") at [local Mahara pathway]\auth\xmlrpc\land.php:94

Our cron was broken for a week and a half (credentials problem with the Windows event scheduler), fixed yesterday. To be sure, I went ahead and ran cron by hand just before testing this problem.This error  appeared in php-erros.log after that, but I don't know what they mean.

[17-Nov-2010 13:06:25] Call stack (most recent first):
[17-Nov-2010 13:06:25]   * log_message("core cronjob "import_cleanup_old_imports" didn't g...", 8, true, true) at [local Mahara pathway]\lib\errors.php:109
[17-Nov-2010 13:06:25]   * log_warn("core cronjob "import_cleanup_old_imports" didn't g...") at [local Mahara pathway]\lib\cron.php:167

...and others on exporting. Is cron still broken? (I'm not really that geeky...sorry.)

I do hope this is enough to help. Thanks.in advance.

17 November 2010, 15:52

Hi Jeffrey,

I don't think your cron is broken, I think those messages are just warnings (I've made a few changes to cron recently and I hope most of those noisy warnings will be gone in v1.4)

But cron *does* need to be running for files inside sub-folders inside views to get the right permissions, and it can take time for that to happen (usually a minute if that's your cron frequency).  If you see something called 'rebuild_artefact_parent_cache_dirty' in your cron logs and no obvious errors straight afterwards, then the sub-folder permissions thing should be working correctly.

18 November 2010, 11:43

Weeell, no cron log to look at, I'm afraid. We have our cron running every half-hour, which, by my stroll through other postings on this, is perhaps less often than needed. But it should be often enough to catch what I've been looking at. The "failure" I've been using as a test was not corrected overnight. For the sake of argument, I created another sub-folder, added the doc to it, ran the cron by hand from the server, and checked everything after it was finished. Still "Access denied."

I'm going to try to modify my event scheduler entry to spit out the log, and up the frequency. If you have anything else you could suggest, I'm all ears.

18 November 2010, 15:52

Jeffrey,

Yes, Mahara's cron is a bit strange; it refuses to run jobs when it thinks it's 'too late' (this behaviour has also been addressed for 1.4).

But have a look at this post:

 http://mahara.org/interaction/forum/topic.php?id=2302

You need to either

1. set your crontab to run cron.php once a minute; or
2. edit the various cron tables in the database so that none of the functions in there 'want' to run more frequently than your crontab allows.

R.

21 November 2010, 21:09

Richard:
       I opted for "door #1," and set my cron job for every minute. It has had no impact on the error message in my test case. I haven't tested it against new additions as of yet.
       At the risk of asking more than my PHP-poor and SQL-iffy brain may be able to absorb, exactly what is it that the cron job is attempting to correct? Is this a query I could run directly against the database, thereby correcting these problems as they arise, using the ID #'s the error spits out? As I mentioned, the problem has not been consistent or pervasive, so I'm just trying to get through this until I can either induce all of these students into avoiding sub-folders (there's over 2,000 using them), or obtain a more effective fix. The portfolio cluster leader at this school is trying to pull out of the project altogether, and although the system has proved pretty popular for social networking purposes, this school is our district pilot of its intended purpose, ePortfolios.
       Thanks.

22 November 2010, 15:57

Hi Jeffrey,

I'll tell you what I know about this, and you can have a go at tracking it down yourself (I don't think I'll have much time to do it in the next couple of weeks).

Mahara has a table called artefact_parent_cache that stores all the ancestral relationships amongst artefacts (artefacts include files, folders, and most other Mahara content).

As I understand it the original purpose of this table was to avoid having to do an unbounded number of joins on the artefact table when trying to work out whether a user can see some artefact which might be contained within a series of parent artefacts.  (Recent versions of postgres will allow us to avoid this problem altogether, but we're not there yet).

So for example, when a view v contains a folder x with some subfolders ultimately containing a file f, and Mahara tries to find out whether f is viewable by some user in the context of v, it doesn't really do a complete check to see whether f is ultimately contained in v, it checks whether the artefact_parent_cache *thinks* f is inside some other artefact which it already knows is in v.  It knows x is in v directly, but it doesn't think f is in v unless artefact_parent_cache has a record to say f is in x.

artefact_parent_cache is supposed to be kept up to date by two functions running on cron: rebuild_artefact_parent_cache runs once a day (or maybe hour?), and rebuilds the entire table based on the values of the parent column in all rows of the artefact table. rebuild_artefact_parent_cache_dirty runs every minute and only rebuilds rows of the table that have been marked as dirty (meaning either the parent or child artefact have been modified since the last run).  I think the reason it updates by cron is to avoid delays to the user as they're moving their files around inside a large hierarchy of folders.

Whether or not it's worth doing all this fiddling around with the extra table and the cron jobs I'm not entirely sure.  I do remember there was some disagreement about it when it first got added into Mahara, but I've never run any tests to see what the performance is like without it.  I suspect it's pretty useful to do it this way on some sites.

R.

23 November 2010, 17:31

Richard, Jeffrey, I've been able to verify that when rebuild_artefact_parent_cache_complete runs (once per day in my case) it is deleting entries in artefact_parent_cache even though the (parent) artefacts still exist in view_artefact.

Of course, this is why I've been experiencing the issue of artefacts (eg files within a folder) appearing OK when I first create a view, but getting the access denied errors when I go back a couple of days later. The problem can be overcome by putting a single file into a view because it bypasses the need for its entry in artefact_parent_cache. This is happening in 1.3.1 on MySQL.

Any further clues? Will a quick upgrade fix this?