30 января 2010 в 14:56
Интересует следующие...
Возможно ли привязать публикации материала и просмотр их к времени не реальному, а к времени жизни акаунта...
т.е.
есть сайт расчитанный на 5 лет
после регирации пользователя он имеет просматривать только те материалы которые опубликованы для 1 дня жизни проекта...
проеле день (не от регистрации ) а от времени жизни акаунта (тоесть зарегили юзера на 5 дней ) и он может видеть только те материалы котрый попадают в промежуто этих 5 дней сначала 1 день второй и так далее... как 5 дней жизни заканчивается акаунт юзера блокируется... до момент пока админ не увеличит ему время жизни на сайте...
Комментарии
Где вы берёте эту забористую траву?
Это похоже на кастомный модуль,вот то что есть поближе по смыслу. Там интегрировано с модулем "Rules",может чего и вымутите
http://drupal.org/project/node_expire
"Банан огромен, а шкурка еще больше" (с) ))
насамом деле нужно ваше мнение и варианты решения что бы тз нормальное написать программеру.
Node Expire - это не то.
А есть ли смысл в регистрации? Делайте для юзера сессию и задавайте ей время сколько нужно.
Есть смысл.
тк она является частью системы.
расскажу попонятнее что нужно.
есть сайт с определенным сроком жизни, которое может увеличиваться при наличие нового материала для публикации.
каждому материалу (например аудио, видео) указыватся время публикации относительно жизни проекта. не реального времени!!!
это делается для того что бы каждый новый пользователь прошел по всем ступенькам сайта как и предыдущие залогиненые а не зарегилсячерез 5 лет и все на готовенько все ссылки уже есть...
что делать?
Я прочитал половину, подомал, что всё понял, но вторая половина ввела в ступор. Реально - ничего не понятно.
Давайте наводящими вопросами: будет несколько сайтов, не один?
один.
То есть Вы делаете один сайт, который будет удалён, если на нём не будут появляться новые материалы?
да нет.
есть сайт.
есть админ котрый только делает обновления.
есть пользователь котрый впервые прошел
и получает по маленькой дозе инфы часть 1 часть 2 часть 3
потом еще один зарегился он так же получает дозу инфв часть 1 часть 2 часть третью...
в это время первый юзер может уже получть 20 часть... инфы...
каждый пользователь проживает всю стадщию обновления...
---
обычно как зарегился и архивы инфы за 100 лет назд смотри и жди новых
мне такое не нужно!
необходимо чтобы каждый новый пользователь сайта полал свою собственную дозу инфы.
время десвия его акаунта заканчивается . замаражевается доступ.
через пол года реального времени получил еще доступ на год... дальше тикает время... его участия... и следующие по расписанию дозы он получат...
+ новью которое появляется после открытия доступа.
Ну подумаем категориями друпала. Доступ к тем или иным частям сайта можно давать на основе ролей,например "новичёк","бывалый"...Роли можно получать основе продолжительности участия. Вот те же rules стоит посмотреть
Заплатить деньги и сделать под себя
Так мне и будут делать.
Это если 10000 частей сколько же ролей будут и как их все остлеживать. это же не части раз в год или раз в месяц..........
мне треба алгоритм какой примерно нужно что бы тз написать и что можно своими силами сделать...
вопрос как к дням привязать (хотя бы теоретически) дни то не реальное время.
все же автоматизировано должно быть. чтобы админ время тратил только на новое и на регу юзеров. а не копался кому каую когда роль присвоить...
С каждым новым сообщением в данном топике, я понимаю всё меньше и меньше.
Если бы вы по-русски, без ошибок, описали, что вам требуется, то вам бы уже давно ответили, пока на ум приходит только hook_db_rewrite_sql()
P.S. Просьба без оскорблений, иначе потом обижаться придётся
все что нужно написано 3 раза разными вариантами. если что-то непонятно спрашивайте. все что надо в 10 слов уменьшается а вам тут по абзацам расписывают.
пи.сэ. и побольше словами алгоритмы а не - hook_db_rewrite_sql() (это не о чем не скажет)
Алгоритм:
Залезть в запрос, изменить условие WHERE в зависимости от даты регистрации. Без умения писать модули не лезьте
RxB
вы это для чего именно предлагаете?
дата регистрации для моего задания не используется. она сама по себе, как была так и существует.
нужно как-то умудриться задать внутреннее время для пользователя и сайта от которого все пляски идут по доступу к материалам.
пользователю дали добро на регистрацию + дали энное (пусть 30 дней) количество дней в течение которого будут для конкретного ЭТОГО пользователя появляться материал по заранее запрограммированному алгоритму.
провел человек 3 дня из 30 - ему доступны те материалы, которые привязаны к этим дням.
закончились 30 дней. юзер блокируется и что бы продолжить ему надо снова дать энное количество дней и дальше сценарий будет продолжен с момента (с дня) когда у пользователя закончились предыдущие дни.
Для решения вашей задачи
Регистрация, апрув, китайская пасха, это имеет принципиальную разницу? Всё равно готового решения под данную задачу скорее всего нет
да мне решения и не нужно ибо его и нет (я с таким ни где не сталкивался) мне нужен словесный алгоритм как это можно и можно ли осуществить...
для какого из пункта задачи?
Опять начинаем повторять одно и тоже по три раза
Алгоритм:
Залезть в запрос, изменить условие WHERE в зависимости от времени жизни аккаунта.
Время жизни хранить в профиле, в отдельной табличке, каким-то третьим способом
Я у вас пунктов не видел
подводя итого чего нужно можно выразиться еще и так
это как игра что бы ее пройти нужно быть участником всех этапов
так и тут (задачи) каждый пользователь проходит один и тот же сценарий заложенный в сайт.
т.е. пользователь не сможет попасть на финальный этап где раскрыты уже все раскладки и доступны все материалы. попасть на финал он сможет пройдя весь путь который может составлять 1-2 года 5 лет 20 лет...
ну и?
И пишите немного граммотней, прошу, иначе я отказываюсь оказывать помощь
я то вроде понял
но вот нафига???
ну вот я представил. у меня есть сайт которому 5 с лишним лет
зарегился сегодня юзер, а ему доступ к информации только за первый день существования сайта (ну там, нод с "привет, мы запустились"
во второй день он уже может читать целых 2 ноды (ну или сколько там осилил я 5 лет назад) и тд и тд
Но вот на зачем?
его же надо еще задать время жизни в днях. время жизни от регистрации это не то для моей задачи.
это фича предназначена для определенных типов материалов...
это не касается новостей и прочих текстовой информации которая уже не актуальна.
это мне нужно для публикации своих архивов. в течение определенного периода. если все выложить зараз чел придет - сольет все и уйдет. а так если ЭТО нужно человека можно держать нужно тебе количество времени.
ну сделайте платные архивы, зачем же извращаться?? (а с другой стороны, нафига выкладывать, если не хотите, чтоб качали?)
Это разве проблема? Я выше написал как поступить
ну допустим человек заплатит рубль и качнет все за раз а так он 10 лет по рублю и будет качать тоже самое частями... есть разница рубль или 10 рублей за тоже самое?
когда это реализовано будет будет следующие фичи прикручиваться то как бонус в днях для тех кто предоставил что-то архивное интересное. штрафы - если запустили в сеть что-то с этого сайта...
эта параметр дни - самый главный .
а платные архивы не решают тех задач что я поставил для сайта.
Насчёт дней не волнуйтесь, волнуйтесь насчёт того как будете объяснять программисту чего вы хотите
Так мне и нужно понять, что сказать программеру. Вот один человек понял практически. Если и Вы поймете - то дело в шляпе.
ну допустим человек заплатит рубль и качнет все за раз
а что, поставить 10 рублей нельзя?
я к тому, что Вы думаете как типичный программер.
а Вы позовите Толю местного (маркетолога) и спросите, будет ли это вообще кому-то нужно - сидеть у Вас на сайте чтобы получить "ЭТО" (не правда, у Вас там прон в ХД, чтоль
Как раз тут ничего программерского в размышлениях нет, внимание заостряется на мелочах типа "как посчитать дни", а не на реализации
это делается для определенного круга людей.
и что значит поставить 10
идея сайта такова - подавать все частями. и сценарий для каждого юзера будет одинаковый.
появилось вчера на сайте что-то а пользователь возми и зарегился сегодня. а материал уплыл... придет к нему через энное время лет... так как другие люди ждали энное количество лет что бы заполучить ту или иную информацию и тебе придется ждать (вопрос о сливание инфы и размещение на др ресурсах решается путем штрафов - нашел свой материал - извольте получить штраф причем отвечают все. не нравиться не регистрируйтесь (все эти правила прописаны будут)
такая вот схема. один за всех и все за одного.
я заостряю на этом внимание потому что могу это понять а реализацией программеры должны заниматься. или нет?
Я имею ввиду, что программист должен думать как посчитать дни, а не заказчик. И программисту решать, сложно посчитать дни или нет. Как правило, таких заказчиков, которые знают больше чем программист, крайне не любят. Вы за своими днями не замечаете настоящих подводных камней
Для подводных камней и существуют программеры с определенным типом мышления.
Существуют, но будет же так:
так вот и когда разрешит юзер проходит весь материал сайта по шагам и надо задать дни это самое тяжёлое
Программист: Why?
*прошла неделя*
iNFerNo: Ну так сколько будет стоить сделать такое????
Программист: Понимаете, тут такие проблемы:
1. *
2. *
3. *
...
n. *
По этому 500$ минимум.
iNFerNo: 500$?????? ЗА ЧТО? ТАМ НИЧЕГО ТАКОГО НЕТ ТОЛЬКО ДНИ ЗАДАВАТЬ И ВСЁ
По этому, уважаемый ТС, лучше бы вы написали техническое задание на русском языке, а не задавались вопросом "Как объяснить программисту как это делать"
http://forum.freelance.ru/index.php?showtopic=33381&pid=192068&st=0&#ent...
еси чо у меня тз на 20-30 страниц 12 шрифтом... по каждому модулю необходимому... (если пишу)
(+ иллюстрации то как это видят глаза)
Главное, чтобы ваше ТЗ было написано не таким стилем, каким вы нам задаёте вопросы
Так что дорогой rXb вы соизволили понять что требуется от программиста?
если нет то хотелось бы пару конкретных вопрос что не понятно.
само собой. все по ГОСТам.
На сколько я понял
то в принципе ничего сложного нет , естественно все решается через самописный модуль.
Примерно так:
Создается таблица с расписанием выдачи материалов, примерно такой структуры
DayOfRegister int - дней от регистрации
data text - серилизованный масив с nid нод
далее по вкусу или в hook_access или hook_nodapi (есть еще варианты) на основании
текущего пользователя и заполненного расписания показываются/скрываются/запрещается доступ
к тем или иным нодам ...
вроде все !
olk фишка в том что не от регистрации пляшем...
а от поля с датой которую выставляет админ заблокированному еще пользователю. когда дата выставлена юзер активируется (активный). и время тикает...
30 дней
29
10
и к этим поля и привязываются доступы к нодам...
как-то так наверное должно быть...
Ну и в чем проблема ? Цепляете стандартный модуль профиля (profile),
добавляете там поле «время жизни акаунта»,
и «текущий день жизни»
в таблице расписания вместо дней от регистрации, используете «время жизни акаунта» + «текущий день жизни»,
дальше алгоритм тот-же,
плюс в модуле через hook_cron, раз в сутки инкрементируете поле «текущий день жизни» и заодно блокирует пользователя если
«время жизни акаунта» < «текущий день жизни»
Всё сведётся к тому, о чём уже написал rxb - hook_rewrite_sql.
Если вдруг через хук не получиться - не проблема выдача определённы нод будет "ручная" через собственный модуль.
Парни, данное обсуждение напоминает гадания о состоянии кота Шредингера.
Мы нихрена не знаем, но однако же предлагаем свои варианты
не знаю что в вашем понимание администирование скажу как необходимо.
до того как начнется регистрация
необходимо подготовить базовую сборку проекта.
создаем материал (видео)
Вводим заголовок
прописываем день доступа (например 3 день или 572)
заполняем все необходимое содержание. и нажимаем сохранить.
1 юзер видет все эти ноды.
а если зайдет зарегенный то он увидет эту ноду (или получит доступ к ней) только когда на его счетчике в профиле накапет нужный день третий или 572)
менять роли это не тема так как придется созадавать 10000000000 ролей.
а так будет вип роль которая будет привязана к алгаритму... доступа определенных нод.
Ваша задача решается модулем который пишется в 1 день (ну и отлаживается дня три четыре на конкретных данных),
Просто надо сформировать корректную постановку задачи...
т.е. надо построить бизнес-процесс (в разрезе воркфлоу),
и описать все достижимые результаты, при всех возможных вариантах развития событий,
Даже по этому описанию не понятно:
1. «Расписание» только одно, или зависит например от типа материала или еще каких то данных (например роли пользователя)
1. В ноде прописывается конкретный день или диапазон.
2. В каком виде выводить доступные ноды (спиок, тизеры, полные ноды), нужнен ли пункт меню для данного списка,ограничен ли список кол-вом, нужны каки либо фильтры, нужнен ли порядок сортировки и т.д и т.п. поддерживать ли пейджинг, или запрещать доступ при переходе на конкретную ноду
3. Ограничения действует на конкретный день/диапазон или включая предыдущие ограничения (например видит ли пользователь с 572 днем жизни, ноды доступные на 571 день ?
4. Кто блокирует/разблокирует пользователя и как это происходит (например пользователь заблокировался, что делать после разблокировки, считать время жизни по новой или продолжать дальше и какой теперь у него день жизни ?)
5. Версия Друпал ?
Ну и так далее и т.п.
Тут даже не обязательно рисовать UML-диаграммы и сети петри , или конечные автоматы ...
Просто опишите сценарий по каждой возможной инвариантной ветке, и вам будет проще понять чего же вы хотите
Если вы все это распишете то:
Возьмусь реализовать модуль с таким функционалом за день-два
Цена 400 у.е. Предоплата 200 у.е. Доработки после реализации (при изменении начальных условий) 40 у.е. за чел/час.
Бред или не бред, давайте дождемся ответа автора топика
Мне это видится так ... возможно вам как то иначе ...
Не обязательно зацикливаться на node access
можно например в hode_alter, на op == 'load', подменять флаг публикации ноды ...
"Банан велик, а кожура еще больше..." Роберт Вильямс Вуд. Историю фразы желающие могут почитать в книге биографа Ситбрука
Насчет доступ запрещен.
закрытые ноды выводиться должны без ссылки на ноду...
заголовки - то что закрыто в данный момент
заголовки с линками - открытые...
в "расписание" может вписаться любой материал.
День прописываеться. и в коде выставлено например время для крона видима (по дефолту например 12 ночи по серверу) (или в настройках модуля)
день наступил - нода открыта пожизненно.
выводяться так же как и остальные ноды... (ни каких новых страниц не нужно ибо все ноды привязаны к сортировке по годам.... ) нода 1 относица к 2000 году нода 56 к 2009 году... - года ноды прописываются - год из таксономии.
день наступил - и нода видна пожизненно.
друпал шестой.
блокируется автоматом. дни закончились заблокировался аккаунт.
доступ только к профилю т.к. там кнопка будет, которую юзер нажимет, когда рубль закинет очередной и этим опевестит админа. админу приходит письмо, и он уже смотрит пришел ли рубль, и выставляет дальше дни, приплюсоывая их к старым дням...
так делается потому что - можно будет штрафовать на дни эти же, или набавлять бонусы за что либо...