все таки мне кажется что с двумя отдельными моделями Admin и Manager + include модуль с общими методами будет понятнее

связь 1 к N не порождает новую табл

смотря как это юзать

я имею ввиду, как в конечном счете будет работать эта связь

ну админы к примеру не могут вообще никак управлять или видеть чужих менеджеров

если не нравится admin_id можно просто parent_id. И хоть 100500 ролей тогда добавлять. Если роли наследуют друг друга.

т.е. группы админ + менеджеры должны быть полностью изолированы между собой

у тебя может быть так, что 2 админа будут связаны с 1 менеджером?

нет

ну тогда да, таблица не нужна

нет

Почему

А если попросят

у тебя может быть так, что 2 админа будут связаны с 1 менеджером?

Это уже M к N, тогда бы точно отдельная табл была)

потому что если будет 2 админа 1 менеджер, это как раз юзкес чтобы юзать одельную таблицу

т.е. группы админ + менеджеры должны быть полностью изолированы между собой

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

А если попросят

^

группа = админ юзер?

тогда на программном уровне нужно будет проверять, чтобы один админ был

два админа из разных компаний не могут иметь одного и того же менеджера

тогда на программном уровне нужно будет проверять, чтобы один админ был

ну это как бы не проблема

два админа из разных компаний не могут иметь одного и того же менеджера

а из одной?

не проблема, но лучше нормально спроектировать

а из одной?

админ должен быть один на компанию)

тогда не нужно будет ничего думать лишнего

админ должен быть один на компанию)

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

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

я пока не думал про модель компании отдельно. Впринципе Админ акк и олицетворяет компанию пока что

ну мне кажется правильнее будет выделить отдельную модель с связью 1 к 1, а компания будет 1 к Н иметь менеджеров

потому что у тебя тогда будет админ перемешиваться с компанией

и если у нее будет атрибуты не нужные для юзера это будет плодить ненужные атрибуты всем юзерам

связь 1 к 1 - это просто поле юзеру добавить )

ну в целом согласен, было бы удобно сразу сгруппирировать админа и менеджеров под одной компанией. @company.admin , @company.managers

ну можно и так, а можно и заготовку на будущее сделать и в компании хранить user_id

сначала у тебя будет has_one

а потом легко переделать на has_many

а почему не в юзера company_id ?

понял, Спасибо большое всем за помощь, прояснилось многое))

а почему не в юзера company_id ?

заготовка на возможное изменение чтобы было Н-ое кол-во компаний + зачем юзеру плодить эти ИД?

так это не мешает добавлять компании. Но можем в будущем привязать несколько админов

а то сегодня компания, завтра там не знаю, еще какая-то сущность, и модель юзера будет иметь 100500 форинкеев, но зачем?

по моей структуре админ 1, он владелец этой компании

по твоей - да, один

а админов можно как менеджеров инклюдить если нужно

по моей структуре админ 1, он владелец этой компании

ну я тоже это так вижу в целом

не всё нужно в юзера выносить. Нужно анализировать предметную область

верно, но она имеет свойство меняться и подумать лучше оптимальный вариант, чем первый простой

потому что кто знает, что клиент захочет через год

а потом переделывать и писать рейки на миграцию связей хоть не сложно, но зачем?

да, но так мы привязываем жестко одного юзера.

как владельца

нас же никто не ограничивает

добавить админов как членов компании, как менеджеров

а как они будут появляться в системе?

админ регать?

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

ну так правильно

такое, не самый надеждый способ

особенно если кейс добавления админа в компанию, который был зареган раньше твоего

то он выходит станет ее владельцем

пабам

админ регать?

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

регаешь нового и прязываешь всех от старого, вариант же)

хоть немного и костыльный

ну вот в моей логике костыля не будет) и зато можно гибко еще задавать права в рамках организации для каждого юзера, будь то админ или менджер, если вдруг и такое нужно будет сделать

у меня просто как-то был проект, похожего рода, когда есть юзера с компанией и у нее есть мемберы, с разным уровнем прав

и структура была примерно такого вида

самый простой варант как мне кажется- это добавить поле company_id, и обычные роли admin или manager

простой но не гибкий, особенно, раз все же логичнее вынести в компанию отдельно от юзера (к примеру у нее будет имя, это что мы у юзера будем еще хранить company_name?)

нет, отдельная сущность

форинкей в юзера

связь 1 к N именно так конвертится

в какую-то из табл выносим ключ с другой

вариант конечно рабочий, но я уже писал, какие ограничения он наложит, а чем по 10 раз переделывать проще сделать с меньшей кровью

ок)

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

вот да, спс наверное модулями лучше

Проясните идею с модулями? Пример с STI на мой взгляд вполне хорош, потому что предотвращает кучу геммороя при relations - когда надо разных пользователей к чему-то привязать, например. Несколько раз разносил по таблицам в проектах - пришел к выводу что ничего кроме какой-то ненужной волокиты не выиграл. Доступы вообще через cancan можно отдельно прописывать. А что дают модули и include Просто паттерн не совсем понятен.

И еще тут вообще размышления для аналитика на проекте - "роль" - это свойство юзера или свойство привязки юзера к объекту. Он может где-то быть админом, а где-то - юзером?

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

Согласен

Всем привет. Никто не сталкивался с проблемой долгой перезагрузки кода Rails приложение, когда что-то меняешь в исходнике (на рендер станицы уходит 15 секунд, в обычных условиях, оно меньше 1 секунды), я поинмаю, что надо код перезагрузить, но всеже время какой-то странное.

Спринг воткни попробуй

Так с ним

А что именно ты меняешь? Код или css js?

rb

когда js/css быстро

У меня так же я думал это нормальное повежение

У меня чисто апишка

Запрос шлется и просто будто ожидает чего то и потом только доходит до экшна

народ, вопрос. есть capistrano и ckeditor в проекте. при редеплое upload-папка с файлами, залитые с помощью ckeditor'а остаются в папке предыдущего релиза. как бы ручками можно перенести в текущий деплой эту папку, но это не тру. соотвесна, можно ли как-то этот вопрос "объяснить" в инструкциях капистрано? ну или в крайнем случае, на самом серваке

народ, вопрос. есть capistrano и ckeditor в проекте. при редеплое upload-папка с файлами, залитые с помощью ckeditor'а остаются в папке предыдущего релиза. как бы ручками можно перенести в текущий деплой эту папку, но это не тру. соотвесна, можно ли как-то этот вопрос "объяснить" в инструкциях капистрано? ну или в крайнем случае, на самом серваке

linked_dirs

понял, почитаю доку, спасибо

Господа, а не подскажите как правильно сделать что бы получить часть от хеша, например есть `user = { name: '0', email: '1', password: '2' } ` а нужно плучить только { name: '0', email: '1'} ?

user.slice :name, :email => {:name=>"0", :email=>"1"}

user.slice :name, :email => {:name=>"0", :email=>"1"}

благодарочка

есть еще какие-то настройки фильтрации, что бы ненужные данные не светились в логах

Господа, а не подскажите как правильно сделать что бы получить часть от хеша, например есть `user = { name: '0', email: '1', password: '2' } ` а нужно плучить только { name: '0', email: '1'} ?

{ name: '0', email: '1', password: '2' }.select { |k, v| k != :password }

user.slice :name, :email => {:name=>"0", :email=>"1"}

Это же рельсы только или я ошибаюсь?

Руби

рельсы, а надо чистый руби?

https://blog.bigbinary.com/2018/02/06/ruby-2-5-added-hash-slice-method