Size: a a a

AUG for Developers

2020 April 06

AC

Anton Chemlev in AUG for Developers
это фантазия, если чо)
источник

ЕР

Евгений Русских in AUG for Developers
чот не выходит
источник

ЕР

Евгений Русских in AUG for Developers
код из их примера возвращает вроде как список с одним элементом (судя по фору), так что видимо в бандле больше ничего нет
источник

ЕР

Евгений Русских in AUG for Developers
при этом если сделать просто вывод этого бандла - он ваще жалуется что такой переменной нет
log.debug bundle
log.debug bundle.events
источник

ЕР

Евгений Русских in AUG for Developers
groovy.lang.MissingPropertyException: No such property: bundle for class: Script558
источник

AC

Anton Chemlev in AUG for Developers
тады облом
источник

ЕР

Евгений Русских in AUG for Developers
нашёл другой ивент, который триггерится. Кажись удалось обойти проблему) спасибо всё равно )
источник

AC

Anton Chemlev in AUG for Developers
все равно пожалуйста, Евгений)
источник

VK

Vladimir Kibe in AUG for Developers
Евгений Русских
судя по всему из RemoteIssueLinkDeleteEvent никак не получить стриггеривший лиснер issue.
Там только есть айди связи и глобалАйди, но если по ним искать - уже ничего не находит, т.к. связи то нет уже. Дичь какая-то. Получается скрипт сам не знает что его запустило
У меня получилось через глобал ид получить ишью.но то было remote create
источник

ЕР

Евгений Русских in AUG for Developers
Vladimir Kibe
У меня получилось через глобал ид получить ишью.но то было remote create
с созданием всё понятно, там по айди связи находишь связь и берёшь тикет. При удалении, айди связи есть, а связи уже нет.
источник

VK

Vladimir Kibe in AUG for Developers
Евгений Русских
с созданием всё понятно, там по айди связи находишь связь и берёшь тикет. При удалении, айди связи есть, а связи уже нет.
Удивительно что не смогли вложить обьект ишью,с которым произошло событие
источник

ЕР

Евгений Русских in AUG for Developers
Vladimir Kibe
Удивительно что не смогли вложить обьект ишью,с которым произошло событие
да ваще бред какой-то
источник

D

Dmitry in AUG for Developers
Всем добрый день! Никто не сталкивался с такой проблемой: bitbucket иногда, даже очень редко, делает одну гадость. Заменяет в исходном коде английскую С на русскую С. Соответственно это вызывает неиллюзорные проблемы на сборке. Проблема воспроизводится буквально раз в пару месяцев в различных репозиториях в случайных файлах при активной нагрузке bitbucket. Совершенно точно такие изменения не уходят с локального репозиторя, в коммитах за длинный период файлы, в которых возникает поломка, не появлялись. Если у кого-то было нечто подобное, был бы рад услышать мнения в какую сторону копать.
источник

D

Dmitrii in AUG for Developers
немного дополню, битбакет стоит на линуховом сервере. с кодировкой utf-8. а сами исходники идут из под винды и там 1251
источник

D

Dmitrii in AUG for Developers
могут быть изза этого проблемы?
источник

R

Robert in AUG for Developers
Robert
Суть обновить Jira 6.4.8 до 8.x.x
И столкнулись с тем что у нас collation cyrylic. А 8 версия требует Latin.
Я пробовал делать так: разворачивал свежую базу с нужным collation. Подключал Jira, импортировал из бекапа данные.
Свои данные вроде корректно переводит, но решил поставить плагин tempo timesheet, его модули некорректно завелись, начал искать причину. И увидел в базе вместо текста знаки вопроса - ???? ???

Вот и пытаюсь изменить collation по инструкции
https://confluence.atlassian.com/jirakb/how-to-fix-the-collation-of-a-sql-server-database-for-jira-776646810.html

На шаге экспорта данных сталкиваюсь с ошибкой: cannot be processed because more than one code page (1251 and 1252) are specified for it. (Sql server import and export wizard)

Как корректно перевести данные на правильный collation?

Или как пофиксить данную ошибку.

Или вообще может есть другое решение?
Развернул 6.4.8 на новой базе, поднял бекап, в базе текст в виде знаков вопроса.
Решили проверить, и поменял в базе varchar на nvarchar, текст стал в нормальном виде.

🤷‍♂🤔
источник

R

Robert in AUG for Developers
А ведь Jira начиная с какой-то версии меняет varchar на nvarchar.

Почему тогда при upgrade до 8.x.x у меня поля остаются в varchar?
источник
2020 April 07

ВР

Вячеслав Рыжов in AUG for Developers
Коллеги. Подскажите. Есть джира 8.5.1 и новые юзеры имеют ключ типа JIRAUSER10100 - я осознаю что это за изменения согласно документу https://confluence.atlassian.com/jiracore/gdpr-changes-in-jira-975041009.html?_ga=2.9424177.508292463.1585553606-412045951.1564595973 НО вот что мне НЕ понятно - у меня есть джира 8.3.2 и 8.4 и там такого НЕ происходит. Вопрос - почему?
источник

PK

Pavel K in AUG for Developers
В релиз нотах к 8.2 это была дарк фича
источник

PK

Pavel K in AUG for Developers
как и написано по ссылке
источник