Sharepoint 2007 - есть ли способ определить, есть ли первая регистрация файла?

Я думал, что это будет намного проще, однако я не могу найти способ определить в моем обработчике событий, является ли ПЕРВАЯ регистрация файла...

Видите ли, я нарушаю наследование ролей и выборочно наследую разрешения для файлов в библиотеках документов, но я хочу сделать это только один раз, во время первой регистрации файла.

Я попытался добавить запись в "SPListItem.Properties" в событии ItemAdded, чтобы указать, является ли файл новым, однако в тот момент, когда я делаю "SPListItem.Update()", он исчезает..

Я играл с событиями ItemCheckingIn и ItemCheckedIn без успеха...

В настоящее время я надеюсь только на добавление SPField в ContentType, чтобы указать, новый файл или нет, но я действительно хочу избежать этого..

ЕСТЬ ИДЕИ????

ПОМОГИТЕ МНЕ, ПОЖАЛУЙСТА!

Источник

2 ответа

Решение

Так что я получил решение для этого. Извините, я не могу опубликовать здесь код, у меня нет доступа к Интернету на моей машине разработчика. Это должно быть достаточно хорошо для всех.

Решение: во время события CheckingIn я пытаюсь получить доступ к файлу, используя SHAREPOINT\system("SPSecurity.RunWithElevatedPrivileges()"). Во время первой регистрации файл является новым и не доступен для других пользователей, кроме загрузчика.

Поэтому, если мне не удается получить файл с помощью SHAREPOINT \ system, это означает, что он новый, и я сохраняю его Guid в словаре в своем классе EventHandlers.

Затем в событии CheckedIn я просто проверяю, содержит ли словарь Guid текущего элемента, если он - FIRST CHECK-IN, если нет - NOT FIRST CHECK-IN.

Конечно, после того, как я закончу с файлом, я удаляю запись из словаря.

Надеюсь, это поможет, если у вас есть какие-либо вопросы, которые вы можете задать:)

Источник

Я бы порекомендовал подумать не только о том, имеет ли системная учетная запись доступ, но также и о том, совпадает ли дата извлечения файла с датой его создания.

public bool IsFirstCheckIn(SPListItem item)
{
    // Item not null!
    if (item != null)
    {
        SPSecurity.RunWithElevatedPrivileges(delegate
        {
            // Open privileged Site
            using (SPSite pSite = new SPSite(site.ID))
            {
                // Open privileged Web
                using (SPWeb pWeb = pSite.OpenWeb(web.ID))
                {
                    // Create privileged SharePoint-Objects
                    SPList pList = GetList(pWeb, list.ID);
                    SPListItem pItem = GetListItem(pList, item.UniqueId);

                    // Check the Item
                    if (pItem == null)
                    {
                        // Can't access
                        return true;
                    }
                    else if (pItem.File != null && pItem.File.CheckedOutByUser != null)
                    {
                        // If the Item's File and checked out User is set, check if checked out date is equal creation date
                        return (pItem.File.CheckedOutDate.ToLocalTime() == pItem.File.TimeCreated.ToLocalTime());
                    }
                }
            }            
        });    
    }

    return false;
}

Использовать системную учетную запись, безусловно, хорошая идея, иначе настройки авторизации могут вызвать проблемы. Используйте "местное время" вместо "UTC-Time", SharePoint обрабатывает часовой пояс при сохранении!

Похоже, SharePoint использовал UTF-FileTime для хранения времени создания файла, но использовал часовой пояс, определенный для SPWeb или для SPUser, чтобы сохранить дату извлечения файла на основе "местного времени".

К счастью, значение DateTime знает, что это такое, и может преобразовать его в то же самое "местное время" при вызове ToLocalTime(). Странно, но при вызове ToUniversalTime() все равно будет File-Time;

Источник
Другие вопросы по тегам