Czy elementy treści mogą zostać automatycznie odblokowane po pewnym czasie?

10

Większość naszych użytkowników nie rozumie, że powinni oni zapisywać lub anulować, kiedy edytują swoje treści, dlatego stale mamy zablokowane dziesiątki artykułów i kategorii. Zdaję sobie sprawę, że administrator może to zrobić ręcznie, ale edycja trwa 24 godziny na dobę, 7 dni w tygodniu, i ciągłe przeglądanie wszystkich elementów decydujących o tym, czy edycja została porzucona, jest dość nużące.

Czy istnieje sposób na przekroczenie limitu czasu blokady?

PKB
źródło

Odpowiedzi:

5

Możesz zdefiniować godzinowe zadanie cron lub użyć phpMyAdmin i wykonać ten 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;

Uwaga: Zamień na josswój prefiks tabeli.

Powyższy kod SQL sprawdza w artykułach i kategoriach, które zostały sprawdzone odpowiednio ponad dwie godziny lub godzinę temu. Zakładam, że artykuł i kategorię należy zapisać w ciągu odpowiednio dwóch godzin i godziny. Możesz zwiększyć te liczby.

Farahmand
źródło
Pomyślałem, że będzie to zadanie dla SQL, ale liczyłem na jakąś ukrytą funkcję w nowszych wersjach.
PKB
1
AFAIK nie ma wbudowanej funkcji, ale można użyć wtyczki Autocheckin .
Farahmand,
5

Starając się unikać cronów, gdy tylko jest to możliwe, ale na podstawie odpowiedzi z @Farahmand umieszczam odmianę tego kodu w onUserLogout()zdarzeniu wtyczki użytkownika :

Kiedy każdy użytkownik loguje się sprawdza-in plugin któregokolwiek z ich treści, jak również wszelkie inne check-out, które mogły zostać porzucone. Chciałem, aby wpłynęło to tylko na niektóre grupy użytkowników i upewniłem się, że nie dotyczy to treści użytkowników administracyjnych (z naszych własnych wewnętrznych powodów - być może przesada w przypadku typowych instalacji, ale w naszym przypadku mamy niestandardowe grupy użytkowników, które mogą znajdować się w kilku standardowe grupy użytkowników, więc uwzględniają to nakładanie się).

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;
}

Jestem pewien, że SQL można dostosować do stref czasowych itp., Ale oto wynikowa instrukcja 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))
        )
PKB
źródło
2
fajny pomysł ten po wylogowaniu użytkownika
FFrewin
2
Niezła odpowiedź. Aby uniknąć ustawiania stref czasowych, można zastąpić checked_out_time < NOW() - INTERVAL 12 HOURz checked_out_time < JFactory::getDate('now +12 hours')- nie testowano.
Farahmand,