I have several red and blue outlined multimedia objects under several individuals' media tabs. I would like to accept the pending changes indicated by the blue outlined objects, thereby eliminating the red-outlined objects.
However, the Accept/Reject Changes feature is not shown in the Admin - Data and GEDCOM Administration menu.
Per Wiki, that feature was there at one time. If it is no longer included, how do I accept the aforementioned changes?
I've selected the "Show Pending Changes" block on my portal page, but that block does not show up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Frank
When logged in as an admin, with approval-level rights, this will appear in several places, but usually in the footer of every page of the site. Check your account status to be sure you have logged in with APPROVAL-ADMIN rights account, and not just an EDIT account. BTW, I never use that block as it sends a most annoying email (IMHO) that changes are pending. -Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Stephen. Yes, I read a post where you said you check often enough to where you don't need to be reminded.
I am logged in as an admin. I do have ADMIN-GEDCOM Access level selected, my changes are set to be automatically accepted.
I haven't seen the footer on any page.
Another significant factor seems to be that this happens when the check box to ignore the change date is checked. i.e. The "Do not change the CHAN (Last Change) record" is checked.
Since my changes are automatically accepted, if I uncheck that box in one of the blue outlined objects and click SAVE, the blue outline disappers and the red outlined object also disappers. But that defeats the purpose of the checkbox.
I could go through each media object, uncheck the checkbox, and click save to remove all the blue and red outlines, but that is a lot of effort and it defeats the purpose of the check box. However, I see no other way to accept changes made with that checkbox checked.
whaddayathink Stephen?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Haven't seen that one. If you have auto-accept on, and you're the only one making changes, then you shouldn't have any red/blue outlined boxes.
HOWEVER, you failed to previously mention that this was media related. I would suspect, with several imports and exports, and some errors in the process, you have screwed up your OBJE allocations and pointers and have probably duplicated some links. The media manager hates this and warns you with plenty of color and markings. If you look at the raw code for any one of the INDI's or FAM's that display this issue, I'm pretty sure you will see unlinked OBJE @Mxxx@ links within the code. -Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As an example, an INDI's media object was displayed twice under his Media tab - one in blue, one in red. I checked the raw GEDCOM record of the INDI using the edit function. The result looked normal:
1 FAMS @F132@
1 FAMS @F3098@
1 FAMC @F149@
1 NOTE @NI346@
1 OBJE @M52@
1 OBJE @m78@
1 OBJE @M14@
1 OBJE @M176@
Under the Media tab, and in the blue outlined frame, I chose Edit. I unchecked the box, Saved it, and the red and blue frames cleared. I then looked at the raw GEDCOM record again. There was no change in the raw record.
The way mine is working, if there is no CHAN record created, PGV recognizes a change occurred, but doesn't provide a way to accept the change - auto or manual.
For a test, I changed my rights to 'not auto accept changes'. I then made a simple change to a media object, I unchecked the CHAN record box, and then saved it. The red and blue outlines showed up. I then saw the footer you referred to and the option to accept / reject changes is available in the GEDCOM administration section. Only that one change showed up in the list of changes to approve.
This only seems to occur in media objects. I have never seen blue and red frames around anything else. I gave the other two people who are editing 'auto accept changes' privileges. They have not edited media.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Frank
First, 1 OBJE @m78@ is not the same as 1 OBJE @M78@. IF you have your prefix set to "M", you must be consistent in your use of prefixes.
Do you have four distinct media objects attached to this person? OR, do a couple of these (maybe M14 and M52) also point to M78 and M176?
This has nothing to do with the change record and only the links to media objects.
And BOY, are you brave. Despite being reasonable confident of the competency of 4 of my 400+ users, I've never even considered granting auto-accept privileges and can not foresee any reason to do so. PGV, with the colored boxes, allows them to confirm that they have made changes and they understand that every change is reviewed and approved or denied by the site admins. -Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I experimented a bit with m/M78. It was a photo shared by two different INDI's. I could never eliminate the colored frames from both people at the same time. I went back and forth saving the photo, which would eliminate the frames on that indi, but it would create two frames on the other. I then deleted the picture on one of the people and then re-linked it. It ended up with a M78 (capital) and now the frames work normally. I didn't realize the small m would cause that problem.
Good advice. I will just offer the others editing privileges without auto-acceptance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Stephen, it turns out the whole problem was caused by the m vs. M. Like you said, they aren't the same. I just deleted and re-linked at least 150 of those media links. What I did originally was to set a link to a picture, then share that link with others. And when I shared it, I just typed in a small m and the number. I had to delete everyone of those small-m-links and re-link with a capital M and the number. I think I've got them all. And the red and blue frames are finally gone.
Thanks for catching that! I'm glad you did. I bet this makes WT happier too.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Frank
More work than necessary, I'm afraid. Here's a good use of the batch search and replace updater - 'case sensitive'. Or you could have exported and used a good text editor, and replaced all instances of mxxx with Mxxx. Either way, glad you discovered what some consider a bug, but more a design feature in the software that the alphanumeric encoding of the XREF numbers is case sensitive and 's1234' is not the same source as 'S1234'. -Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree with the edit idea. I just didn't want to press my luck with things working as well as they are right now. I think WT had a difficult time with this too. Not yet sure, but I had some unexplained issues going on over there too.
I believe you are suggesting I export a fresh copy of the GEDCOM file, edit it and then import it. And that would have quickly fixed things. I considered doing that. I also thought of doing some sort of work like that to the mySQL database. But I believe the OBJ reference shows up at least in the INDI table, the media table, and in the media mapping table. Still not real comfortable with what each table does.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Frank
The postings in the SQL are quite intertwined and it can be dangerous to mess with, (and no offense) when you're not completely confident in the code and those relationships.
The advantage of the S/R batch operation is it allows a review of each and every change, prior to executing, if need be, and yet is still pretty fast unless there are thousands of changes to make. An external text edit would have accomplished the same result.
Almost any problem like this that you have in PGV, you will have in webtrees as it remains firmly grounded in thousands of lines of code from PGV. The multi-media handling properties are largely unchanged and would deliver identical results for the very same reasons that s1234 is not S1234 nor is M75 the same alphanumeric XREF as m75. This will never be true, but a revision of the multimedia handling is a longterm goal - just not pressing. We have made thousands of changes in the code since the port-over, squashing many little, but aggravating bugs, but most code changes have been made to continue the progress of speeding the code's calls on the DB, configuring the DB for cleaner operations and future enhancements with new structure, module management, and improving many interfaces, with considerable CSS cleanup. Upcoming enhancements include tossing the v2 Google Map API (now deprecated) and installing v3, significant improvements in administration menus and a change in handling user management.
It is unlikely that similar changes, enhancements or bug fixes will occur in PGV in the near-future as we remain without a lead programmer, at least at this time. -Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have several red and blue outlined multimedia objects under several individuals' media tabs. I would like to accept the pending changes indicated by the blue outlined objects, thereby eliminating the red-outlined objects.
However, the Accept/Reject Changes feature is not shown in the Admin - Data and GEDCOM Administration menu.
Per Wiki, that feature was there at one time. If it is no longer included, how do I accept the aforementioned changes?
I've selected the "Show Pending Changes" block on my portal page, but that block does not show up.
Frank
When logged in as an admin, with approval-level rights, this will appear in several places, but usually in the footer of every page of the site. Check your account status to be sure you have logged in with APPROVAL-ADMIN rights account, and not just an EDIT account. BTW, I never use that block as it sends a most annoying email (IMHO) that changes are pending.
-Stephen
Hi Stephen. Yes, I read a post where you said you check often enough to where you don't need to be reminded.
I am logged in as an admin. I do have ADMIN-GEDCOM Access level selected, my changes are set to be automatically accepted.
I haven't seen the footer on any page.
Another significant factor seems to be that this happens when the check box to ignore the change date is checked. i.e. The "Do not change the CHAN (Last Change) record" is checked.
Since my changes are automatically accepted, if I uncheck that box in one of the blue outlined objects and click SAVE, the blue outline disappers and the red outlined object also disappers. But that defeats the purpose of the checkbox.
I could go through each media object, uncheck the checkbox, and click save to remove all the blue and red outlines, but that is a lot of effort and it defeats the purpose of the check box. However, I see no other way to accept changes made with that checkbox checked.
whaddayathink Stephen?
Haven't seen that one. If you have auto-accept on, and you're the only one making changes, then you shouldn't have any red/blue outlined boxes.
HOWEVER, you failed to previously mention that this was media related. I would suspect, with several imports and exports, and some errors in the process, you have screwed up your OBJE allocations and pointers and have probably duplicated some links. The media manager hates this and warns you with plenty of color and markings. If you look at the raw code for any one of the INDI's or FAM's that display this issue, I'm pretty sure you will see unlinked OBJE @Mxxx@ links within the code.
-Stephen
As an example, an INDI's media object was displayed twice under his Media tab - one in blue, one in red. I checked the raw GEDCOM record of the INDI using the edit function. The result looked normal:
1 FAMS @F132@
1 FAMS @F3098@
1 FAMC @F149@
1 NOTE @NI346@
1 OBJE @M52@
1 OBJE @m78@
1 OBJE @M14@
1 OBJE @M176@
Under the Media tab, and in the blue outlined frame, I chose Edit. I unchecked the box, Saved it, and the red and blue frames cleared. I then looked at the raw GEDCOM record again. There was no change in the raw record.
The way mine is working, if there is no CHAN record created, PGV recognizes a change occurred, but doesn't provide a way to accept the change - auto or manual.
For a test, I changed my rights to 'not auto accept changes'. I then made a simple change to a media object, I unchecked the CHAN record box, and then saved it. The red and blue outlines showed up. I then saw the footer you referred to and the option to accept / reject changes is available in the GEDCOM administration section. Only that one change showed up in the list of changes to approve.
This only seems to occur in media objects. I have never seen blue and red frames around anything else. I gave the other two people who are editing 'auto accept changes' privileges. They have not edited media.
Frank
First, 1 OBJE @m78@ is not the same as 1 OBJE @M78@. IF you have your prefix set to "M", you must be consistent in your use of prefixes.
Do you have four distinct media objects attached to this person? OR, do a couple of these (maybe M14 and M52) also point to M78 and M176?
This has nothing to do with the change record and only the links to media objects.
And BOY, are you brave. Despite being reasonable confident of the competency of 4 of my 400+ users, I've never even considered granting auto-accept privileges and can not foresee any reason to do so. PGV, with the colored boxes, allows them to confirm that they have made changes and they understand that every change is reviewed and approved or denied by the site admins.
-Stephen
I do have four distinct photos on that one INDI.
I experimented a bit with m/M78. It was a photo shared by two different INDI's. I could never eliminate the colored frames from both people at the same time. I went back and forth saving the photo, which would eliminate the frames on that indi, but it would create two frames on the other. I then deleted the picture on one of the people and then re-linked it. It ended up with a M78 (capital) and now the frames work normally. I didn't realize the small m would cause that problem.
Good advice. I will just offer the others editing privileges without auto-acceptance.
Stephen, it turns out the whole problem was caused by the m vs. M. Like you said, they aren't the same. I just deleted and re-linked at least 150 of those media links. What I did originally was to set a link to a picture, then share that link with others. And when I shared it, I just typed in a small m and the number. I had to delete everyone of those small-m-links and re-link with a capital M and the number. I think I've got them all. And the red and blue frames are finally gone.
Thanks for catching that! I'm glad you did. I bet this makes WT happier too.
Frank
More work than necessary, I'm afraid. Here's a good use of the batch search and replace updater - 'case sensitive'. Or you could have exported and used a good text editor, and replaced all instances of mxxx with Mxxx. Either way, glad you discovered what some consider a bug, but more a design feature in the software that the alphanumeric encoding of the XREF numbers is case sensitive and 's1234' is not the same source as 'S1234'.
-Stephen
I agree with the edit idea. I just didn't want to press my luck with things working as well as they are right now. I think WT had a difficult time with this too. Not yet sure, but I had some unexplained issues going on over there too.
I believe you are suggesting I export a fresh copy of the GEDCOM file, edit it and then import it. And that would have quickly fixed things. I considered doing that. I also thought of doing some sort of work like that to the mySQL database. But I believe the OBJ reference shows up at least in the INDI table, the media table, and in the media mapping table. Still not real comfortable with what each table does.
Frank
The postings in the SQL are quite intertwined and it can be dangerous to mess with, (and no offense) when you're not completely confident in the code and those relationships.
The advantage of the S/R batch operation is it allows a review of each and every change, prior to executing, if need be, and yet is still pretty fast unless there are thousands of changes to make. An external text edit would have accomplished the same result.
Almost any problem like this that you have in PGV, you will have in webtrees as it remains firmly grounded in thousands of lines of code from PGV. The multi-media handling properties are largely unchanged and would deliver identical results for the very same reasons that s1234 is not S1234 nor is M75 the same alphanumeric XREF as m75. This will never be true, but a revision of the multimedia handling is a longterm goal - just not pressing. We have made thousands of changes in the code since the port-over, squashing many little, but aggravating bugs, but most code changes have been made to continue the progress of speeding the code's calls on the DB, configuring the DB for cleaner operations and future enhancements with new structure, module management, and improving many interfaces, with considerable CSS cleanup. Upcoming enhancements include tossing the v2 Google Map API (now deprecated) and installing v3, significant improvements in administration menus and a change in handling user management.
It is unlikely that similar changes, enhancements or bug fixes will occur in PGV in the near-future as we remain without a lead programmer, at least at this time.
-Stephen