CUNY Academic Commons

Thanks, Laurie. The crux of the issue is that, for some reason, the cron job that's responsible for switch the access-control on your images was not scheduled. It's not clear to me why this is the case. I tested a few times with your site and I was able to trigger the cron job without a problem. While testing, I did identify a couple areas for improvement of efficiency, and I put them in place https://github.com/cuny-academic-commons/cac/commit/b7323b59164c95cb37b2752222e8d66b73b77410

It's still not perfect. Our scheduled-task runner is running about 10 minutes behind. This is not terrible, but it means that tasks that ought to be done in a few seconds may take 10 or more minutes. When you chain these together, you could end up with a delay of 20 or 30 or more minutes. I'm going to reach out to Reclaim about increasing the workers devoted to Cavalcade so we can mitigate this problem somewhat.

Beyond this, there's the problem that users don't really have any indication what's going on when they change their blog_public value and the S3 ACL tool hasn't finished running (or, as in your case, isn't even scheduled). In a perfect world, we'd have systems that informed the admin what was happening, gave real-time info about it (processed 550/1200 items, or whatever), and perhaps even had a button that would allow you to run an update batch immediately. Unfortunately, building this kind of tool is quite time-intensive, and changing of blog privacy settings is not a super common event, so I don't know that it's worth the effort.

I'm going to spend some time thinking about this. I think that perhaps we ought to move the ACL batch system out of Cavalcade. Instead, we could hook it into 'init' or something, with some sort of 'update in progress' flag to ensure that only a single batch can run at a time. This feels clunkier, but it also avoids some of the problems described here (Cavalcade running behind, tasks not being properly scheduled). Ray, if you have thoughts about this, I'd welcome them.

I've rewritten the system to move away from Cavalcade-dependent scheduled tasks: https://github.com/cuny-academic-commons/cac/commit/9074ea45e662d773f9437918ab87714b86b26c36 After this change, when you change the Reading > Visibility setting from public to private or vice versa, all uploaded items will be queued for ACL change. Then, a batch will be processed each time the administrator loads the Dashboard, until the process is finished. This will be pretty seamless in most cases, since admins will generally go clicking around after they've changed their privacy settings. I also added a small admin notice so that admins are aware of what's happening. See attached screenshot. As you refresh the page and/or click around, this number will go down.

In my tests, this is working nicely. It slows down pageload a little bit while the batches are in progress, but this is a fairly minor thing, as admins change this setting only very rarely.

There's still some funniness in the way that the three icons on https://tlcdevsite.commons.gc.cuny.edu/ under 'What We Do' work. This seems to have something to do with the way that some plugin caches image paths. It's connected to S3 privacy, but is specific to that block (perhaps part of Otter Blocks, I'm not sure) and is not affected by the toggle behavior being discussed in this ticket. Laurie, if you're experiencing problems in that area, please open a separate ticket that describes them in detail. In the meantime, please feel free to check the process of toggling site privacy in order to see how the new batch routine works.

Seems like this one is resolved.