Cannot create or issues,tasks,subtasks only modify existing ones

[mikekidner]

When trying to create an issue or convert TODO to issue I get
completing-read-default: Wrong type argument: symbolp, "Story"
or
completing-read-default: Wrong type argument: symbolp, "Task"
or
completing-read-default: Wrong type argument: symbolp, "SubTask"
depending on what command I've previously called.

When trying to create a subtask, it gets to the end of the prompts but then
Making completion list...
REQUEST [error] Error (error) while connecting to https://eeeeeee.atlassian.net/rest/api/2/issue.
jiralib--rest-call-it: Wrong type argument: stringp, nil

I can update comments, descriptions, assignees but can't seem to do anything that involves creating a new issue.

I'm using the cookie workaround for authentication

Here's the backtrace

Debugger entered--Lisp error: (wrong-type-argument symbolp "Task")
read-from-minibuffer("Type: " nil (keymap (10 . minibuffer-complete-and-exit) (13 . minibuffer-complete-and-exit) keymap (menu-bar keymap (minibuf "Minibuf" keymap (tab menu-item "Complete" minibuffer-complete :help "Complete as far as possible") (space menu-item "Complete Word" minibuffer-complete-word :help "Complete at most one word") (63 menu-item "List Completions" minibuffer-completion-help :help "Display all possible completions") "Minibuf")) (27 keymap (118 . switch-to-completions)) (prior . switch-to-completions) (63 . minibuffer-completion-help) (32 . minibuffer-complete-word) (9 . minibuffer-complete) keymap (menu-bar keymap (minibuf "Minibuf" keymap (previous menu-item "Previous History Item" previous-history-element :help "Put previous minibuffer history element in the minibuffer") (next menu-item "Next History Item" next-history-element :help "Put next minibuffer history element in the minibuffer") (isearch-backward menu-item "Isearch History Backward" isearch-backward :help "Incrementally search minibuffer history backward") (isearch-forward menu-item "Isearch History Forward" isearch-forward :help "Incrementally search minibuffer history forward") (return menu-item "Enter" exit-minibuffer :key-sequence "\015" :help "Terminate input and exit minibuffer") (quit menu-item "Quit" abort-recursive-edit :help "Abort input and exit minibuffer") "Minibuf")) (10 . exit-minibuffer) (13 . exit-minibuffer) (7 . abort-recursive-edit) (C-tab . file-cache-minibuffer-complete) (9 . self-insert-command) (XF86Back . previous-history-element) (up . previous-line-or-history-element) (prior . previous-history-element) (XF86Forward . next-history-element) (down . next-line-or-history-element) (next . next-history-element) (27 keymap (114 . previous-matching-history-element) (115 . next-matching-history-element) (112 . previous-history-element) (110 . next-history-element))) nil ("Task") "Task" nil)
completing-read-default("Type: " ("Task" "Sub-task" "Epic") nil t nil ("Task") "Task" nil)
completing-read("Type: " ("Task" "Sub-task" "Epic") nil t nil ("Task") "Task")
org-jira-read-issue-type("MD")
byte-code("\300 \301\001!\302\303!\302\304!\003\003\003\003F\207" [org-jira-read-project org-jira-read-issue-type read-string "Summary: " "Description: "] 8)
call-interactively(org-jira-create-issue nil nil)
command-execute(org-jira-create-issue)

[robwithhair]

I'm experiencing this one too I believe.

[ahungry]

Did you try deleting all compiled .elc files etc. and ensuring everything is up to date?

[Fruchtenstein]

I see a similar situation with Emacs 26.1, Org-mode 9.1.3 and org-jira 4.3.1. After project selection, I get the following message:

In ‘org-jira-create-issue History’ source: ‘#[0 \304\302\300\305\303$\211\205�\0\306\307\310\301�""\207 [nil  initial-input nil helm-comp-read-get-candidates nil delete  helm-cr-default] 6 

(fn)]’ 
 (void-function initial-input)

[mjburling]

Apologies in advance for the spacemacs output, but looks like it's mostly relevant. I seem to be experiencing a similar problem

In ‘org-jira-todo-to-jira History’ source: ‘#[0 \304\302\300\305\303$\211\205�\306\307\310\301�""\207 [nil  initial-input nil helm-comp-read-get-candidates nil delete  helm-cr-default] 6]’ 
 (void-function initial-input)

System Info 💻

• OS: darwin
• Emacs: 26.3
• Spacemacs: 0.300.0
• Spacemacs branch: develop (rev. 57721d8e7)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(javascript markdown ansible yaml helm emacs-lisp git
            (org :variables org-enable-jira-support t jiralib-url "https://flywheelio.atlassian.net")
            (shell :variables shell-default-shell 'shell shell-default-height 30 shell-default-position 'bottom)
            spell-checking terraform)

• System configuration features: NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES THREADS

[boontdustie]

I am also trying to create an issues and getting an error. I'm seeing this in *Messages*

REQUEST [error] Error (error) while connecting to <jira-url>/rest/api/2/issue.
jiralib--rest-call-it: Wrong type argument: stringp, nil

Also using the cookie workaround for authentication.

[arichiardi]

I have run into this but it seems to be solved by adding the org-jira-mode to the buffer.

[ahungry]

How did you add the mode to the buffer? You mean M-x org-jira-mode to enable the mode? It would likely be expected that any buffer calling the interactive commands was in org-jira-mode and not in plain org-mode (this would rely on the user setting the proper major-mode on buffer open of existing files, as the mode would only be set by the package if it was one of the auto-opened files).

[Ferryworld]

org-jira-create-issue failure
helm-M-x-execute-command: Inorg-jira-create-issue History' source: #[0 \304\302\300\305\303$\211\205^Q^@\306\307\310\301^D""\207 [nil nil initial-input t helm-comp-read-get-candidates nil d\ elete helm-cr-default] 6]' (wrong-type-argument listp initial-input)

[NahsiN]

I run into a similar error when trying to create an issue

In ‘org-jira-create-issue History’ source: ‘#[0 \304\302\300\305\303$\211\205��\306\307\310\301�""\207 [nil  initial-input nil helm-comp-read-get-candidates nil delete  helm-cr-default] 6]’ 
 (void-function initial-input)

System Info 💻

• OS: darwin
• Emacs: 27.1
• Spacemacs: 0.200.13
• Spacemacs branch: master (rev. 40024fedb)
• Graphic display: t
• Distribution: spacemacs
• Editing style: emacs
• Completion: helm
• Layers:

[Pitta]

Adding to the pile. Anyone figure this one out?
I am not using the cookie workaround for auth.

[ahungry]

I can't reproduce this (any of the aforementioned problems) - if someone who has the ability to reproduce the failure could work on solving, I think it'd be a great help.

[Pitta]

So, it seems I was only partially suffering from this issue.

I can create issues and convert todo's, but only if I select a valid user in the user list for Assignee. If I try to select Unassigned (which is preferable), it chokes just like this.

I can, however, un-assign the ticket from emacs after I create it. So It's only on the mini buffer execution when issues are set to an unassigned user that things blow up.

[mjburling]

I can create issues and convert todo's, but only if I select a valid user in the user list for Assignee. If I try to select Unassigned (which is preferable), it chokes just like this.

This is exactly my experience using the creation workflow using the minibuffer. I'd love to help–maybe I can dedicate some time to this over the coming weekend.

[ahungry]

Thanks, this update in the bug report has isolated the error - when I create with Unassigned, I can see this failure, stringp expected, nil received, as the issue hashtable is as such:

Result: ((fields (project (key . "AHU")) (parent (key)) (issuetype (id . "10004")) (summary . "some epic with no assignee") (description . "some epic with no assignee") (priority (id . "3")) (assignee (accountId . ""))))

When I choose a person, accountId would be set to the large uuid for an account id. I'm guessing this regression occurred when work was done to change basic username references to account ids.

[ahungry]

Should be fixed in 0e9bb6d (at least, the interactive mini-buffer creation for new tickets).

This ticket has become a bit of a ball-o-mud, in that there are various unrelated issues being discussed (some appear to be encoding issues, some interactive creation issues, and quite a few are very old, so perhaps not relevant).

I'm going to close this - if anyone is still experiencing the error(s) they had in 2019, please let me know via a fresh issue.