[EXTERNAL USER][ISSUE] - Allow External Share user to create issue
Description
Currently external users are unable to create issues and are limited to editing existing issues.
Suggested improvement
Enable external users to create issues using external share interface
Decision on implementation
Creation will be possible from board share. For starters, no additional share will be created for every new issue, created issue will be accessed through board share (configuring the board so that new issues are on it is responsibility of the client). Only basic data can be set during creation, but more can be added afterwards during edition (provided that edition is turned on in configuration).
<hide start>
Based on following client requests:
https://ossapps.atlassian.net/browse/SUP-3181
https://ossapps.atlassian.net/browse/SUP-5008
https://ossapps.atlassian.net/browse/SUP-5108
Linked issues
relates to
ESFJ-466
The "Code wrap" feature lacks a background when being edited using the issue creation editor
Withdrawn
ESFJ-469
The link option in the editor is not dark mode friendly and includes "Link target" which is an unnecessary tab
Released
Activity
Show:
@Krzysztof Bogdan Please review new documentation draft - https://warsaw-dynamics.atlassian.net/wiki/spaces/WD/pages/148242487/Issue+creation
@Parsa Shiva Please create ticket for things you found.
@Parsa Shiva Please create ticket for your findings. Those will be good improvements.
@Michał
Improvement Implemented - QA environment
No major bugs or blockers just some editor issues.
@Krzysztof Bogdan We need to add activity for this on both Jira (for internal users to see) and on ESFJ dashboard activity tab. Should I create task for that?
Issues
Code wrap not visible during edition, only after publishing it’s visible.
Link target tab is necessary? if so it is not dark mode friendly
Header dropdown moves with the scroller
@Kamil Zarychta One more commit for review (ckeditor is now used during issue creation). The code is on qa, so if it still looks good, please send to test.
@Michał code looks good
@Michał Could you summarize our conversation and put it in description?
Deciding on design - how it should work
Michał Szkrabko: Takie przemyślenie mnie naszło podczas pracy nad tworzeniem issuesów. Czy wolałbyś:
A. Mieć konfigurację per projekt (konfiguracja = które pola będą dostępne dla użytkownika do wypełnienia, w które system ma wpisać jakieś defaultowe wartości, oraz przede wszystkim czy w danym projekcie można w ogóle tworzyć nowe issuesy). W takim wypadku w konfiguracji byłaby opcja włączenia tworzenia issuesów dla każdego, kto ma udostępnionego jakiegoś share'a z tego projektu.
B. Mieć konfigurację per share. W takim wypadku można by było zrobić kilka share'ów udostępnionych różnym użytkownikom (albo nawet temu samemu użytkownikowi) i wtedy tworząc nowego share'a z ekranu share'a X użytkownik musiałby na przykład wypełnić jakieś pole, ale tworząc nowego share'a w tym samym projekcie ale z ekranu share'a Y miałby inną konfigurację i system na przykład wypełniał by to pole automatycznie jakąś ustawioną wartością. Albo generalnie można by było inne pola wypełnić.
Wg mnie prościej by było mieć jedną konfigurację dla projektu. Ewentualnie opcja C:
C. Konfiguracja per projekt, ale dodatkowo w konfiguracji share'a możliwość włączenia tworzenia issuesów. Wtedy jak ktoś by miał share'a z możliwością tworzenia issuesów to by mógł tworzyć, a inny miałby share'a bez włączonej opcji tworzenia issuesów to by nie mógł tworzyć. Tylko wtedy co jeżeli user ma 10 share'ów, z czego 1 ma włączoną opcję tworzenia issuesów, a 9 nie. Umożliwiać wciśnięcie przycisku tylko na tym jednym share? Chyba bez sensu. Wtedy przycisk na każdym o ile masz chociaż jednego z włączoną opcją tworzenia.
Krzysztof Bogdan: Teraz już wiem, że powinniśmy cały konfig pchać na share
Krzysztof Bogdan: poziom skomplikowania jest podobny
Krzysztof Bogdan: a użyteczność jest dużo większa
Krzysztof Bogdan: teraz mamy np konfig JQL/Filter view per projekt
Krzysztof Bogdan: masakra
Krzysztof Bogdan: która sam wymyśliłem :cry:
Michał Szkrabko: IMHO większy - chcesz stworzyć nowego issuesa a masz kilka share'ów z różnymi configami, musisz wybrać z którego configa skorzystać i w zależności od tego będziesz mógł inne pola wypełnić tworząc issuesa
Krzysztof Bogdan: No a co jak chcesz miec inny konfig?
Michał Szkrabko: i jak wtedy przy tworzeniu share'ów - masz 10 customowych pól obowiązkowych, tworzysz nowego share'a w JIRA, zaznaczasz, że chcesz umożliwić tworzenie nowch issuesów i definiujesz od nowa config dla wszystkich pól? Czy tez jakieś dziedziczenie że config per projekt z możliwością nadpisania per share?
Krzysztof Bogdan: Zacznijmy od lvl share
Krzysztof Bogdan: potem bedziemy wiedzieli co mozna ustawić w lvl projekt
Krzysztof Bogdan: wiec 'dziedziczenie' zostawmy na potem (nigdy? :) )
Michał Szkrabko: Config custom fieldów w JIRA masz dla projektu.. nie robisz osobnego configu custom fieldów dla boarda.. czy robisz?
Krzysztof Bogdan: zależy
Krzysztof Bogdan: custom-fieldy ustawiasz per share
Krzysztof Bogdan: kolumny w jql/filter view per projekt
Krzysztof Bogdan: board card layout nie da sie zmienic
Krzysztof Bogdan: aaa czy pytasz o Jira
Krzysztof Bogdan: nie o ESFJ?
Michał Szkrabko: o Jira
Krzysztof Bogdan: Poziom konfigracji w Jira masz per issue type
Michał Szkrabko: zastanawiam się czy w JIRA robi się różne konfiguracje custom fieldów wewnątrz jednego projektu.. i czy to faktycznie ma sens dla ES
Krzysztof Bogdan: ma
Krzysztof Bogdan: w zależności od issue type
Michał Szkrabko: a no ok, w zależności od issue type racja
Krzysztof Bogdan: ale jeżeli chodzi o tworzenie issue przez external usersa
Krzysztof Bogdan: to bardziej bym sie wzorował na JSM
Krzysztof Bogdan: a tam masz konfiguracje per link
Krzysztof Bogdan: (nasz share)
Michał Szkrabko: no dobra, niech będzie per share.. spróbuję to jakoś ładnie zrobić
Michał Szkrabko: Tylko w takim razie bym chyba zrobił jednak dedykowany typ share'a umożliwiający tworzenie issuesów. Można by było w niego wejść jak nie masz żadnych innych issuesów wyshare'owanych i miałby tylko przycisk "CREATE", oprócz tego przycisk CREATE byłby widoczny na każdym innym share. Inaczej userzy będą robić jakiś dummy share po prostu żeby umożliwić tworzenie, albo podpinać do boarda i później nie będą mogli tego znaleźć.
Krzysztof Bogdan: To spoko brzmi
Krzysztof Bogdan: dodaj może te wszystkie notatki/rozmowy do ticketa :)
Michał Szkrabko: oki :)
Michał Szkrabko: chcesz jeszcze zadzwonić coś przegadać, czy moja ostatnia wiadomość Ci rozwiała wszelkie wątpliwości?
Krzysztof Bogdan: To co chciałem powiedzieć, żeby ten konfig do create był minimanly na początku
Krzysztof Bogdan: tylko to co niezbędne
Michał Szkrabko: Ja to na początek bym spróbował bez żadnego configu.. summary i description do wypełnienia, a jak są jakieś inne pola required to sorry.
Michał Szkrabko: JIRA wywali błąd i nie utworzysz. Natomiast dalej już znalazłem opcję wczytywania configu z JIRA (nota bene metoda utworzona przez Ciebie chyba w 2021 roku i nie wykorzystywana do dzisiaja, ale zrobiłeś na zapas i teraz jest jak znalazł), config w tym specjalnym share umożliwiającym tworzenie miałby taką samą strukturę jak ten pobrany z JIRA i nadpisywałby to co jest w JIRA i na podstawie tak skonstruowanego configu wyświetlałyby się odpowiednie pola do wypełnienia. Config składa się z listy configów dla każdego issue type'a, wiec to już jest uwzględnione
https://jira.external-share.com/issue/559b75a2-7266-4342-b62c-797fcc70df6a
https://jira.external-share.com/issue/4b7a3e6b-b1de-4fea-9569-f9e93aff2287
https://jira.external-share.com/issue/34af0c37-dea3-4bd3-b034-aa2bfb18bb66
I see some updates in this ticket, do you have any news about the implementation of this feature?
Wish you a nice weekend,
Sami
@Krzysztof Bogdan @Kamil Zarychta
Please keep
Enabling external users to be automatically subscribed to their issues when they create them may have its merits and could be considered as a future enhancement.
https://ossapps.atlassian.net/browse/SUP-3181
https://ossapps.atlassian.net/browse/SUP-5008