Чи можуть елементи вмісту бути автоматично розблоковані через певний час?


10

Більшість наших користувачів не розуміють, що вони повинні зберігати чи скасовувати під час редагування вмісту, тому ми постійно маємо безліч статей і категорій, які заблоковані. Я усвідомлюю, що адміністратор може це зробити вручну, але редагування триває 24/7, і досить втомлено постійно переглядати всі елементи, визначаючи, чи було відмінено редагування чи ні.

Чи є спосіб якось встановити тайм-аут блокування?

Відповіді:


5

Ви можете визначити щогодинну роботу cron або використовувати phpMyAdmin та виконати цей SQL:

UPDATE `jos_content` c    SET c.checked_out = 0, c.checked_out_time = 0 WHERE HOUR(TIMEDIFF(CONVERT_TZ(NOW(), @@session.time_zone, '+00:00'), c.checked_out_time)) >= 2;
UPDATE `jos_categories` c SET c.checked_out = 0, c.checked_out_time = 0 WHERE HOUR(TIMEDIFF(CONVERT_TZ(NOW(), @@session.time_zone, '+00:00'), c.checked_out_time)) >= 1;

Примітка. Замініть josпрефікс таблиці.

Вищевказаний SQL перевіряється в статтях і категоріях, які перевіряли більше двох годин або години тому відповідно. Я припускаю, що статтю та категорію слід зберегти протягом двох годин та години відповідно. Ви можете збільшити ці цифри.


Зрозумів, що це буде завданням для SQL, але сподівався на якусь приховану функцію в нових версіях.
ВВП

1
AFAIK немає вбудованої функції, але ви можете використовувати плагін Autocheckin .
Фарахман

5

Намагаючись уникати корон, коли це можливо, але, грунтуючись на відповіді @Farahmand, я помістив варіант цього коду в onUserLogout()події User Plugin :

Коли будь-який користувач виходить із системи , плагін перевіряє будь-який їх вміст, а також будь-які інші виписки, які, можливо, були відмовлені. Я хотів, щоб це вплинуло лише на певні групи користувачів, і гарантувати, що будь-який вміст користувачів адміністратора ніколи не постраждав (з наших власних внутрішніх причин - можливо, перевищення типових установок, але в нашому випадку ми маємо власні групи користувачів, які можуть бути в декількох із них стандартні групи користувачів, тому вони враховували це перекриття).

function onUserLogout() {
    $groups_include = '2,4,10';    // Affect Registered, Publishers, and Custom Group
    $groups_exclude = '7,8';       // Don't affect Administrators or Super Users

    $db = JFactory::getDbo();
    $query = $db->getQuery(true);
    $query->update($db->quoteName('#__content'))
    ->set('checked_out = 0, checked_out_time = 0')
    ->where('( checked_out = '.JFactory::getUser()->id.' ) OR (
        checked_out_time < NOW() - INTERVAL 12 HOUR
        AND checked_out IN (SELECT GROUP_CONCAT(user_id) FROM scm_user_usergroup_map WHERE group_id IN ('.$groups_include.'))
        AND checked_out NOT IN (SELECT GROUP_CONCAT(user_id) FROM scm_user_usergroup_map WHERE group_id IN ('.$groups_exclude.'))
        )'
    );
    $db->setQuery($query);
    $db->execute();
    return true;
}

Я впевнений, що SQL може бути скоригований для Timezones тощо, але ось результуючий оператор SQL:

UPDATE `gdp_content`
SET checked_out = 0, checked_out_time = 0
WHERE ( checked_out = 30 ) OR (
        checked_out_time < NOW() - INTERVAL 12 HOUR
        AND checked_out IN (SELECT GROUP_CONCAT(user_id) FROM scm_user_usergroup_map WHERE group_id IN (2,10,11))
        AND checked_out NOT IN (SELECT GROUP_CONCAT(user_id) FROM scm_user_usergroup_map WHERE group_id IN (7,8))
        )

2
класна ідея цього після виходу з користувача
FFrewin

2
Гарна відповідь. Щоб уникнути коригування часових поясів, ви можете замінити checked_out_time < NOW() - INTERVAL 12 HOURна checked_out_time < JFactory::getDate('now +12 hours')- Не перевірено.
Farahmand
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.