Web based family history software

Question Improve routing following deletion of record

  • ddrury
  • Topic Author
  • Offline
  • Senior Member
  • Senior Member
More
13 years 4 months ago #1 by ddrury
Following the deletion of a Individual, Family, Source, Repository or Shared note using the Edit menu, webtrees gives the message 'Unable to find record with ID (nothing)' which of course it can't as that record has just been deleted.

In my opinion it would be more user friendly if webtrees went to a more useful place, maybe the listing of the item that has just been deleted (i.e the list of sources if a source has been deleted)

A subset of this was originally reported as bug 677811 which was rejected because of the wider coverage listed above

--
Dave

Local: Win 11 Pro, WSL2/Ubuntu20.04.4, Apache 2.4.51, PHP 7.4.26/8.1.7, MySQL 8.0.27
Production: Litespeed 8.0.1, PHP 8.1.9, MySQL 8.0.26

Please Log in or Create an account to join the conversation.

  • windmillway
  • Visitor
  • Visitor
13 years 4 months ago #2 by windmillway
Replied by windmillway on topic Re: Improve routing following deletion of record
To all concerned,

I propose to add the initial code I developed (firstly just to the shared note structure) that was originally in PGV shared notes, and then removed.
This will return the user to the List Shared note page, after the succesful deletion of any shared note by an Admin.
(If I can trap the note id and give a message on the list page saying "Shared Note Nxxx successfully deleted", then I will do when the page is refreshed after the deletion)

Would this suffice, OR does anyone disagree with/want to modify this proposal?

If then agreed, then this solution could be cascaded into the other objects as necessary at some later date.

Brian

Please Log in or Create an account to join the conversation.

More
13 years 4 months ago #3 by kiwi
Dave

Brian misunderstood my comment, so I have re-instated your bug report. I DO think it is a bug. I just meant to say it is not ONLY a bug with the shared note deletion.

I also agree that ideally after any deletion the user should be re-directed to somewhere meaningful. That will of course be complex, and may require different solutions for each type of record, and possibly also dependent on where they delete it from. It might even be impractical, I'm not sure. But until the matter is discussed (and thanks for raising the issue here) the bug should remain outstanding, in my view.

Lets see what they community thinks ....

Please Log in or Create an account to join the conversation.

More
13 years 4 months ago #4 by kiwi

windmillway wrote: Would this suffice, OR does anyone disagree with/want to modify this proposal?

If then agreed, then this solution could be cascaded into the other objects as necessary at some later date.

Brian

Hi Brian

Yes, I do disagree :-))

I think we should establish the correct principle for ALL records before we fix one individual type - otherwise the wider picture may be lost.

Please Log in or Create an account to join the conversation.

  • windmillway
  • Visitor
  • Visitor
13 years 4 months ago #5 by windmillway
Replied by windmillway on topic Re: Improve routing following deletion of record
Thanks Nigel for the clarification.

As this will be a wider scope, I would personally prefer to wait for comments after further discussion.
I have plenty to do with Google Maps V3 which I must get started on again.
Perhaps someone else may want to take this ("redirection after deletion of an object") on as a small project?

Please Log in or Create an account to join the conversation.

  • fisharebest
  • Away
  • Administrator
  • Administrator
More
13 years 4 months ago - 13 years 4 months ago #6 by fisharebest
Replied by fisharebest on topic Re: Improve routing following deletion of record
Are you planning to add this after the delete request - or the actual deletion.

For example, if a user does not have auto-accept enabled, then it would be quite reasonable to stay on the page - so that they can use the "accept changes" menu option to confirm the delete.

Also, many of the list pages can be slow on large sites. Automatically redirecting to a slow page may not be appreciated.

In terms of work flow, are better solutions? For example, if you are re-arranging some badly connect individuals, and you delete a spouse, it might be more useful to return to the remaining spouse, etc.

Perhaps keep the "not found" error message, but add some links. e.g to the home page, the list page, the search page, the previously linked records, etc.

Greg Roach - greg@subaqua.co.uk - @fisharebest@phpc.social - fisharebest.webtrees.net
Last edit: 13 years 4 months ago by kiwi.

Please Log in or Create an account to join the conversation.

More
13 years 4 months ago #7 by kiwi

Perhaps keep the "not found" error message, but add some links. e.g to the home page, the list page, the search page, the previously linked records, etc.

Sounds like a good solution. Just the sort of thinking I hoped we'd get by discussing it here.

Please Log in or Create an account to join the conversation.

  • windmillway
  • Visitor
  • Visitor
13 years 4 months ago - 13 years 4 months ago #8 by windmillway
Replied by windmillway on topic Re: Improve routing following deletion of record
Greg, neat idea.

Thinking a little more deeply about what Nigel said about where you are when you decide to delete something.
The obvious solution is to return to where you where when you had the idea to delete.
(Maybe with one other option, not sure) any more and you are just complicating things I reckon.

Maybe a popup window for the deletion of said object (as we do with edit_interface.php) is better.
Then returning to the "Full Page" where you where when you decided to delete.
This would also possibly take into acount any auto-accept options (or not as the case may be)

At the moment, the only place where you can delete a shared note (OR SOUR or REPO), (I think)
is via the main menu Edit option when actually viewing this note (or SOUR or REPO) as a FULL page
(note.php, source.php repo.php)
Perhaps this is wrong, and it should be able to be deleted from the event, or list, or whatever you are on at the time.
Last edit: 13 years 4 months ago by windmillway.

Please Log in or Create an account to join the conversation.

More
13 years 4 months ago #9 by WGroleau
Would it suffice to just re-phrase the diagnostic?

You could get a similar message by a page refresh after some other user deleted the record. Or after an admin accepts a pending deletion. In that case it can't send you "where you were before the record you decided to delete"

If webtrees can detect that the current viewer is the one who deleted it (i.e., some sort of entry in a log file, DB, or session variable), then it could instead of an error message, say that the deletion was successful, and they could just use the main menu bar or the browser history to take themself somewhere meaningful.

And if someone else deleted it, Cannot display <whatever> as it was recently deleted.

And if neither, a message similar to what happens now. For example, they clicked into the site via a a stale link outside.

--
Wes Groleau
UniGen.us/

Please Log in or Create an account to join the conversation.

More
13 years 4 months ago #10 by kiwi

windmillway wrote: At the moment, the only place where you can delete a shared note (OR SOUR or REPO), (I think)
is via the main menu Edit option when actually viewing this note (or SOUR or REPO) as a FULL page
(note.php, source.php repo.php)

That's true, but it doesn't apply to FAM or INDI records. There are multiple places you can delete those. Also, I suspect media items may be the most complex case.

In many cases "where you were" is what's causing this problem in the first place, as you "were" on the record you have just deleted! We probably want the system to remember where you were before you were at the place you were at when you decided to delete it !!! Not very practical.

I like Greg's suggestion more and more. Wes' idea is similar, in that it is an enhancement / improvement of the current message.

I don't think we want to start over-complicating it with trying to work out who did the delete, and having all sorts of log file entries of session variables for it. Just not worth the trouble. Keep it simple, then its less likely to break!

Please Log in or Create an account to join the conversation.

More
13 years 4 months ago #11 by WGroleau
Simple is good. OTOH, the log files do already contain things like
Code:
2010-11-27 22:29:38 edit Deleting gedcom record P147 71.97.158.126 WGroleau Groleau-SSDI.ged

--
Wes Groleau
UniGen.us/

Please Log in or Create an account to join the conversation.

  • fisharebest
  • Away
  • Administrator
  • Administrator
More
13 years 4 months ago #12 by fisharebest
Replied by fisharebest on topic Re: Improve routing following deletion of record
<<all sorts of log file entries of session variables for it.>>

Actually, it is *much* easier than that.

When I moved the pending changes from a file to the database, I added one little extra feature.... We don't delete the old/previous versions of edits. They simply sit in the database with a status of "accepted".

I had in mind that it would be used for an "audit" facility for a record, showing what/who/how it had been edited over time, as well as an "undo". But we could use it here - to fetch the previous (i.e. undeleted) version of a record.

Now, for privacy reasons, you may want to restrict which deleted details you show, and to whom. But it may be safe enough to show "This record was deleted on TIME, DATE by USER.".

You may want to restrict this to
1) logged in users
2) deletions that occurred in the last few hours

You may want to additionally show
1) families that were linked to a now deleted individual
2) individuals that were linked to a now deleted family
etc.

Greg Roach - greg@subaqua.co.uk - @fisharebest@phpc.social - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

Powered by Kunena Forum
}