Вот лог, когда мышь подключается без проблем.
104.803856] usb 3-6: new low-speed USB device number 6 using xhci_hcd
[ 104.825426] usb 3-6: New USB device found, idVendor=09da, idProduct=c10a
[ 104.825430] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 104.825432] usb 3-6: Product: USB Mouse
[ 104.825433] usb 3-6: Manufacturer: A4Tech
[ 104.825599] usb 3-6: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
[ 104.896584] hidraw: raw HID events driver (C) Jiri Kosina
[ 104.903300] usbcore: registered new interface driver usbhid
[ 104.903303] usbhid: USB HID core driver
[ 104.912513] input: A4Tech USB Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.0/input/input15
[ 104.913269] hid-generic 0003:09DA:C10A.0001: input,hiddev0,hidraw0: USB HID v1.10 Mouse [A4Tech USB Mouse] on usb-0000:00:14.0-6/input0
Вот лог, когда мышь отказывается подключаться. Даже при втыканий в разные ЮСБ порты
Опытным путем выяснено, что доп свойства можно также импортировать csv файлом.
Просто имя колонки должно начинаться с название доп свойства UF_blabla, также как например LOGIN or NAME.
Вот теперь как импортировать аватарки?
В бд битрикса PERSONAL_PHOTO хранится как ид файла изображение, интегер.
Теперь для каждого пользователся вручную, через админку устанавливать аватар?
Наверное есть какой то другой выход.
На старом сайте(WordPress) у пользователся есть данные о его профиле. (о - одиночное значение, м - множественное значение, в бд хранится в виде сериализованных данных)
Например(кроме стандатных):
Аватарка(о),
ссылки на его соц страничку (о),
телефон (о),
какие услуги он оказывает (м).
Вся проблема в том, почти все эти данные (90%) у пользователя в Битриксе хранятся в пользовательских свойствах, те которые начинаются с UF_*.
Не знаю почему так сделано. Архитектуру не я придумывал.
Таблица `b_user` содержит основные пользовательские данные: внутренний идентификатор, электронный адрес, логин, хэш пароля, хэш контрольного слова, дата регистрации и дополнительные предустановленные поля личных и рабочих данных.
Структура таблицы `b_user` :
опишу основные поля данной таблицы, сведения о которых могут помочь при манипуляциях с данными пользователя:
`LOGIN` - логин пользователя,
`PASSWORD` - хэш пароля пользователя,
`CHECKWORD` - хэш контрольного слова,
`ACTIVE` - активность пользователя ('Y', 'N'),
`NAME` - имя пользователя,
`LAST_NAME` фамилия пользователя,
`EMAIL` электронный адрес пользователя,
`LAST_LOGIN` - дата последнего авторизованного входа,
`DATE_REGISTER` - дата регистрации,
`LID` привязка к сайту,
`PERSONAL_* - поля персональных данных
`WORK_* - поля данных связанных с работой,
`ADMIN_NOTES` - комментарий админа,
`PERSONAL_BIRTHDAY` - дата рождения,
`EXTERNAL_AUTH_ID` - идентификатор внешнего сервиса авторизации,
`SECOND_NAME` - отчество,
`CONFIRM_CODE` - код подтверждения при восстановлении пароля,
`LOGIN_ATTEMPTS` - количество попыток авторизации,
`LAST_ACTIVITY_DATE` - дата последней активности.
Таблица `b_user_field` хранит набор пользовательских полей для различных модулей, типа блог, пользователи и т.п. Фильтрация по модулю осуществляется с помощью содержимого поля ENTITY_ID (в нашем случае для пользователя там будет указано USER).
Структура таблицы `b_user_field`
ENTITY_ID – идентификатор модуля,
FIELD_NAME – имя поля,
USER_TYPE_ID – тип поля(string, iblock_element, file и т.п.),
XML_ID
SORT – индекс сортировки,
MULTIPLE – является ли поле полем с множественным значением,
MANDATORY – обязательно ли поле,
SHOW_FILTER – показывать в фильтрации административного листинга,
SHOW_IN_LIST – показывать в списке административного листинга,
EDIT_IN_LIST - возможно ли редактирование в списке административного листинга,
IS_SEARCHABLE – возможен поиск по поля,
SETTINGS – дополнительные настройки в сериализованном виде, типа: (a:6:{s:4:"SIZE";i:20;s:4:"ROWS";i:1;s:6:"REGEXP";N;s:10:"MIN_LENGTH";i:0;s:10:"MAX_LENGTH";i:0;s:13:"DEFAULT_VALUE";N;})
Таблица `b_user_field_enum` предназначена для хранения значений типа поля enumeration:
Структура таблицы `b_user_field_enum` :
ID – идентификатор записи
USER_FIELD_ID – идентификатор пользовательского поля
VALUE – значение
DEF – значение используется как значение по умолчаниию
SORT – индекс сортировки
Мультиязычность для названий пользовательских полей реализуется с помощью таблицы `b_user_field_lang`.
Структура таблицы `b_user_field_lang`:
USER_FIELD_ID - идентификатор пользовательского поля
LANGUAGE_ID – идентификатор языка
EDIT_FORM_LABEL – фраза представления поля в форме просмотра и редактирования
LIST_COLUMN_LABEL –фраза представления поля в листинге
LIST_FILTER_LABEL – фраза представления поля в листинге фильтрации
ERROR_MESSAGE – фраза сообщения ошибки при работе с полем
HELP_MESSAGE – фраза помощи при работе с полем
Дополнительные пользовательские свойства хранятся в таблице`b_uts_user`, где каждое поле в структуре таблицы является пользовательским полем. Привязка осуществляется по полю VALUE – идентификатор пользователя, это единственное предустановленное поле в этой таблице, остальные поля соответствуют полям записи из таблицы `b_user_field`.
Пример структуры моей таблицы:
VALUE_ID
UF_CITY – пользовательское поле «город»
UF_СOUNTRY – пользовательское поле «страна»
Группы пользователей хранятся в `b_group` .
Структура таблицы `b_group` :
ID –идентификатор записи
TIMESTAMP_X
ACTIVE – активность группы
C_SORT – индекс сортировки
ANONYMOUS
NAME – имя группы
DESCRIPTION - описания
SECURITY_POLICY
STRING_ID
Связь между пользователями и пользовательскими группами осуществляется через таблицу `b_user_group`.
Структура таблицы `b_user_group`:
USER_ID – идентификатор пользователя
GROUP_ID – идентификатор группы
DATE_ACTIVE_FROM – время активности пользователя в группе с …
DATE_ACTIVE_TO – время активности пользователя в группе по …
Вы имеет ввиду развернуть виртуальныую машину с 1С битриксом в сети?
Удаленно или в локальке?
И подключаться по FTP для изменения файлов?
Но ведь машина будет одна для всех программистов и возникает проблема при дебагинге. Ведь дебагинг временно заможивает сервер апачи. Если один занимается дебагинггом, то второй не сможет?
