Андрей Николаев

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

Вы не правильно составляете запрос. Вы посылаете не TASKID = 2, а структуру из content которая содежит json от http_build_query и уже нужного массива.

Замените:

$data = array('TASKID' => $number);
$curl_post_data = array(
    'content' => http_build_query($data)
);
$curl_post_data = json_encode($curl_post_data);

На:
$curl_post_data = array('TASKID' => $number);

Т.е. получается пользователь при регистрации сам себе группу выбирает. Такое вообще можно на битриксе сделать?

Да, такое сделать возможно.

а самое главное целесообразно ли c точки зрения его архитектуры?

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

Можно ли это сделать? Можно.
Существует ли это в данный момент? Нет.

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

Попробуйте отлавливать на событии OnAfterUserLogin - в нем уже есть $arParams, в котором есть USER_ID (в случае успешной авторизации). Единственное, нужно предусмотреть корректную обработку backurl.

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

1С-Битрикс нормально работает только в двух вариантах:
1) Вы регистрируете пользователя и оформляете заказ на него
2) Вы обязательно требуете авторизации у пользователя перед созданием заказа

Как вы можете видеть, авторизация проверяется на более низком уровне и вы никак не сможете это сделать.

Вы просто не внимательно почитали документацию по продукту.
Если покопаться в документации (я привожу пример из блога, но в документации это тоже есть), то можно увидеть, что скидки применяются последовательно по матрице применения. Сначала отрабатывают ВСЕ скидки минимального приоритета, то есть по П(риоритету) и С(оритровке): П1С1, П1С2, П1С10, а затем уже П2С1, П2С4.... Таким образом П1С2 будет выполнена раньше П2С1.

Таким образом порядок правил у Вас такой:
10% на бренды ААА и БББ, новую коллекцию если не отработало идем дальше
50% на бренд ССС, новую коллекцию если не отработало идем дальше
30% на всю новую коллекцию

Для того чтобы диагностировать эту ситуацию нужно:
1) Скриншоты условий скидок (как они прописаны в правилах корзины 1 и 2 вкладки)
2) Данные по 3м товарам: к какой категории они относятся (и вообще все параметры которые задействованы в п.1)

Эм... а что у Вас за жесть со скобками происходит?

Это не нормально

=if ({=Variable:TODAY{{=datediff({=Variable:DATE1}, {=System:DATE}, '%d' ) }}} <4, 'true')

Для корректной работы создайте 2 переменных:

1) Количество дней (тип "Число"), которое будет хранить разницу между двумя числами
2) Условие (тип "Да/Нет"), которое будет хранить соответствие условий количества дней

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

В блоке изменение переменных можно прописать соответствующие значения
Для получения разницы:
=datediff({=Template:DATA1}, {=System:Now}, '%d')

Для сравнения
=if({=Variable:diffDate}<4, 'Y', 'N')

Надеюсь меня тут поругают и ответят как надо было побороть эту проблему.

Конечно поругают: вы ведь делаете кривой велосипед, вместо того чтобы взять и использовать штатную CUser::ChangePassword (ее описание в API).

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

Изучить документацию по Приложениям24 и начать их создавать :)

Возможно в меня сейчас что-нибудь прилетит, но мы используем Битрикс24 (собственно его же и внедряем).
Сделка прекрасно разбиваемся по направлениям:
- Проект
- Сопровождение
- Домены
- Лицензии

Для разработчиков используем Redmine, а для тех.поддержки Okdesk.

Получается следующий кейс: все новые обращение поступают в лиды, их обрабатывают сейлы (сотрудники отдела продаж), они определяют куда это все отправляется.
Далее заключаются соответствующие договоры.
- Лицензии (они же регулярные/разовые продажи продлений).
За Н дней до окончания лицезнии напоминание ответственному менеджеру, печать документов по лицензии, согласование цены и особых условий (для крупняков, госов и т.п.)

- Домены
То же, что и с лицензией, за исключением того что там нет согласования, а из документов только счет/акт

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

- Проект
Длительная штука, там есть интеграция с Redmine по количеству задач и потраченных часов.

Все внутренние коммуникации, евенты и т.п. берет на себя битрикс24. Учет рабочего времение (формальный, т.е. не сколько отработал, а работал ли вообще).
Рядовые сотрудники получают задачи в Redmine / Okdesk, а портал у них для общей информации по компании.

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

P.S. Jira кусается по цене сильно