404 after deleting a draft #2963

Closed
acspike opened this Issue Oct 14, 2016 · 8 comments

Projects

None yet

3 participants

@acspike
Contributor
acspike commented Oct 14, 2016

Submit a form. Open for editing a second time and change a field to create an autosaved draft. Return to the form summary page without saving. Check the draft and delete. Then attempt to access the previously submitted form. 404.

This is happening with a form embedded in liferay.

@ebruchez ebruchez added this to the 2016.3 milestone Oct 15, 2016
@avernet
Collaborator
avernet commented Oct 15, 2016

@acspike Obviously, deleting the draft of a document shouldn't delete the non-draft version. Does it look like this is what is happening here? Do you know if this is happening if you're accessing the form directly, not through Liferay? Also, do you have any permissions defined on the form? And I imagine that your users are authenticated (otherwise they wouldn't have drafts), correct?

@avernet
Collaborator
avernet commented Oct 21, 2016

@acspike Do you have any feedback on my previous comment? If it's indeed an issue, we'd really like to fix this.

@acspike
Contributor
acspike commented Oct 22, 2016

Sorry. In the database the draft version is marked deleted and the non-draft version is not marked deleted. But the draft version's timestamp is newer (of course). The form shows in the summary. But when clicked 404. If I delete the draft record from the table in the database the form is accessible again.

I did a test today with another form (not through liferay) and had the same experience (seemingly easy to replicate). The form I tested today did have a few permissions (anyone: create; owner: read, update, delete). Yes, authenticated.

@avernet avernet closed this in b9f07a8 Oct 28, 2016
@avernet avernet modified the milestone: 2016.2.2, 2016.3 Oct 28, 2016
@avernet avernet added the Regression label Oct 28, 2016
@avernet
Collaborator
avernet commented Oct 28, 2016

Indeed, nice catch Aaron. And this looks like a regression caused by changes we had done for 2016.2. I've picked this on our 2016.2-pe branch, to be included in an upcoming 2016.2.2. Aaron, and in the meantime, just let us know if you need a patch for a build you're using.

@acspike
Contributor
acspike commented Nov 14, 2016

Hit this again today. I guess a patch could be helpful. Or depending on the timetable for 2016.2.2 I could wait.

@avernet
Collaborator
avernet commented Nov 14, 2016

@acspike I'm thinking it might be a good idea for us to do a 2016.2.2 quickly, as we have a number of fairly important fixes in the pipeline. I'll discuss this with Erik and will follow-up here.

@avernet avernet self-assigned this Nov 14, 2016
@avernet
Collaborator
avernet commented Nov 14, 2016

@acspike We've resolved to release 2016.2.2 with the fixes we have so far on the 2016.2-pe branch. It should, if everything goes according to plan, happen this week. Does that work for you?

@acspike
Contributor
acspike commented Nov 15, 2016

Yes, that's great. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment