Могут ли элементы контента автоматически разблокироваться через определенное время?

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 проверяется в статьях и категориях, которые были проверены более двух часов или часов назад соответственно. Я предполагаю, что статья и категория должны быть сохранены в течение двух часов и часа соответственно. Вы можете увеличить эти цифры.

Farahmand
источник
Я подумал, что это будет работа для SQL, но надеялся на какую-то скрытую функцию в новых версиях.
ВВП
1
AFAIK нет встроенной функции, но вы можете использовать плагин Autocheckin .
Фараманд
5

Пытаясь по возможности избегать крон, но основываясь на ответе @Farahmand, я поместил вариант этого кода в onUserLogout()событие плагина пользователя :

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

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 можно настроить для часовых поясов и т. Д., Но вот результирующий оператор 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')- Не проверено.
Фараманд