Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status 500 when moving archived card to another list #3271

Closed
SethFalco opened this issue Aug 25, 2021 · 0 comments · Fixed by #5280
Closed

Status 500 when moving archived card to another list #3271

SethFalco opened this issue Aug 25, 2021 · 0 comments · Fixed by #5280

Comments

@SethFalco
Copy link

How to use GitHub

  • Please use the 👍 reaction to show that you are affected by the same issue.
  • Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

Describe the bug
When attempting to move an archived card to another list, the frontend shows it as if the action was performed successfully. Upon refreshing the page, all moved cards are moved back to where they were before.

In the network logs, I can see moving an archived card results in an error code 500. (internal server error)
Looking at the message, it looks like it should be more like a 403. (forbidden)

{
  "status": 500,
  "message": "Operation not allowed. This card is archived."
}

To Reproduce
Steps to reproduce the behavior:

  1. Create a board on Deck
  2. Create 2 lists on the board.
  3. Create a card on either list with any data.
  4. Right-click the card and click "Archive card"
  5. Click the … button at the top-left and select "Show archived cards".
  6. Drag the card to another list.

If you keep the network logs open during the above, you'll notice a 500 in dev tools, but the action will seemingly complete successfully on the frontend.

Expected behavior
I would expect either:

  • To be able to move archived cards. (It's nice to reorganize history.)
  • For the frontend to not allow dragging the cards to other lists while showArchived is true. (frontend assumes it's not allowed)
  • For the frontend to return the card to its original position if the user attempts to move it while showArchived is true. (Maybe with a user-friendly notification/toast.) (backend rejects the action)

If it will be rejected by the backend, I would expect the response code to be 403. (Or at least a 4XX code)

Screenshots
N/A

Client details:

  • OS: Ubuntu 20.04
  • Browser: Firefox
  • Version: 91.0.1
  • Device: Laptop
Server details

Operating system:

Web server:

Database:

PHP version:

Nextcloud version: (see Nextcloud admin page)

Where did you install Nextcloud from:

Signing status:

Login as admin user into your Nextcloud and access
http://example.com/index.php/settings/integrity/failed
paste the results here.

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your Nextcloud installation folder

Nextcloud configuration:

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your Nextcloud installation folder

or

Insert your config.php content here
Make sure to remove all sensitive content such as passwords. (e.g. database password, passwordsalt, secret, smtp password, …)

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

Logs

Nextcloud log (data/nextcloud.log)

Insert your Nextcloud log here

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log
c) ...
juliusknorr added a commit that referenced this issue Nov 12, 2023
juliusknorr added a commit that referenced this issue Nov 12, 2023
juliusknorr added a commit that referenced this issue Nov 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant