anas/divan
1
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects Releases Wiki Activity

catmap location link fix

Browse Source
This commit is contained in:
Hamid Reza Mohammadi 2026-10-04 18:00:36 +03:30
parent cd38157fce
commit 09449c347f
3 changed files with 48 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
GanjooRazor/Pages/Partials/GanjoorPage/PageTypes/_CatPagePartial.cshtml
View File

@ -182,7 +182,13 @@
if (marker.poemGeoTag.LunarYear != null) {
markOrder = marker.order + ' - ';
}
var poemDesc = markOrder + '<a class="actionlink" onclick="viewLocation(marker.poemGeoTag.Location.Latitude, marker.poemGeoTag.Location.Longitude)">' + marker.poemGeoTag.Location.Name + '</a> <br> <a href="' + marker.poemGeoTag.Poem.FullUrl + '">' + marker.poemGeoTag.Poem.FullTitle + '</a>';
// the location's own coordinates are embedded here as literal numbers, not as a
// "marker.poemGeoTag...." lookup - that onclick string is parsed and executed later,
// when the rendered link is actually clicked, in global scope, where "marker" would
// otherwise resolve to the shared/leaked loop variable below (whichever marker was
// built LAST), making every popup's link open the same one location regardless of
// which marker was actually clicked
var poemDesc = markOrder + '<a class="actionlink" onclick="viewLocation(' + marker.poemGeoTag.Location.Latitude + ', ' + marker.poemGeoTag.Location.Longitude + ')">' + marker.poemGeoTag.Location.Name + '</a> <br> <a href="' + marker.poemGeoTag.Poem.FullUrl + '">' + marker.poemGeoTag.Poem.FullTitle + '</a>';
if (marker.poemGeoTag.LunarYear != null) {
poemDesc += '<br> سال ' + persianizeNumerals(marker.poemGeoTag.LunarYear.toString()) + ' قمری';
}
@ -200,7 +206,10 @@
for (var i = 0; i < poemGeoTags.length; i++) {
var poemGeoTag = poemGeoTags[i];
marker = L.marker([poemGeoTag.Location.Latitude, poemGeoTag.Location.Longitude]);
// declared with "var" so it's local to this closure instead of leaking as an
// implicit global that every iteration overwrites (see the onclick fix above for
// why that leak was the actual user-visible bug)
var marker = L.marker([poemGeoTag.Location.Latitude, poemGeoTag.Location.Longitude]);
marker.poemGeoTag = poemGeoTag
marker.order = persianizeNumerals((i + 1).toString());
marker.addTo(layerGroup);

13
GanjooRazor/Pages/Partials/GanjoorPage/PageTypes/_PoetPagePartial.cshtml
View File

@ -320,7 +320,13 @@
if (marker.poemGeoTag.LunarYear != null) {
markOrder = marker.order + ' - ';
}
var poemDesc = markOrder + '<a class="actionlink" onclick="viewLocation(marker.poemGeoTag.Location.Latitude, marker.poemGeoTag.Location.Longitude)">' + marker.poemGeoTag.Location.Name + '</a> <br> <a href="' + marker.poemGeoTag.Poem.FullUrl + '">' + marker.poemGeoTag.Poem.FullTitle + '</a>';
// the location's own coordinates are embedded here as literal numbers, not as a
// "marker.poemGeoTag...." lookup - that onclick string is parsed and executed later,
// when the rendered link is actually clicked, in global scope, where "marker" would
// otherwise resolve to the shared/leaked loop variable below (whichever marker was
// built LAST), making every popup's link open the same one location regardless of
// which marker was actually clicked
var poemDesc = markOrder + '<a class="actionlink" onclick="viewLocation(' + marker.poemGeoTag.Location.Latitude + ', ' + marker.poemGeoTag.Location.Longitude + ')">' + marker.poemGeoTag.Location.Name + '</a> <br> <a href="' + marker.poemGeoTag.Poem.FullUrl + '">' + marker.poemGeoTag.Poem.FullTitle + '</a>';
if (marker.poemGeoTag.LunarYear != null) {
poemDesc += '<br> سال ' + persianizeNumerals(marker.poemGeoTag.LunarYear.toString()) + ' قمری';
}
@ -338,7 +344,10 @@
for (var i = 0; i < poemGeoTags.length; i++) {
var poemGeoTag = poemGeoTags[i];
marker = L.marker([poemGeoTag.Location.Latitude, poemGeoTag.Location.Longitude]);
// declared with "var" so it's local to this closure instead of leaking as an
// implicit global that every iteration overwrites (see the onclick fix above for
// why that leak was the actual user-visible bug)
var marker = L.marker([poemGeoTag.Location.Latitude, poemGeoTag.Location.Longitude]);
marker.poemGeoTag = poemGeoTag
marker.order = persianizeNumerals((i + 1).toString());
marker.addTo(layerGroup);

26
RMuseum/RMuseum.xml
View File

@ -15214,6 +15214,17 @@
as Importance above. Null/empty is treated as Unknown.
</summary>
</member>
<member name="P:RMuseum.Models.Ganjoor.ViewModels.PersonGraphNode.ConfirmedNewDespiteNameMatch">
<summary>
only meaningful when ExistingPersonId is null (a brand new person is being created).
Normally, if Name exactly matches an already-approved GanjoorRelatedPerson,
_MaterializePersonGraphAsync rejects the submission rather than silently creating a
near-duplicate node - the far more common case is a contributor who free-typed a name
instead of picking the existing person via the search-as-you-type selector. Set this to
true only when the name collision is known/intentional (e.g. two distinct Shahnameh
characters sharing a name) to let the new person be created anyway.
</summary>
</member>
<member name="T:RMuseum.Models.Ganjoor.ViewModels.PersonGraphRelationEntry">
<summary>
one edge in a PersonGraphSuggestion, between two nodes referenced by their LocalKey (Person1/
@ -22273,6 +22284,21 @@
submission-time check is ever bypassed).
</summary>
</member>
<member name="F:RMuseum.Services.Implementation.GanjoorRelatedPersonService._symmetricAffiliationTypes">
<summary>
affiliation types whose two sides are interchangeable (Person1/Person2 order carries no
meaning) - mirrors the convention already baked into SuggestNewPersonRelation.cshtml's
dropdown, where these are the only affiliation options with no "_Other"/"_Subject" pair
</summary>
</member>
<member name="M:RMuseum.Services.Implementation.GanjoorRelatedPersonService._CrossesSymmetricDirectionalBoundary(RMuseum.Models.Ganjoor.PersonAffiliationType,RMuseum.Models.Ganjoor.PersonAffiliationType)">
<summary>
true if modifying an affiliation edge from oldType to newType would cross the symmetric/
directional boundary - PersonAffiliationType.Other is excluded on either side, since its
direction (if any) is whatever the free-text Note says rather than something the type
itself implies, so moving into/out of Other is never treated as crossing the boundary
</summary>
</member>
<member name="M:RMuseum.Services.Implementation.GanjoorRelatedPersonService.SuggestPersonEditAsync(RMuseum.Models.Ganjoor.GanjoorPersonEditSuggestion)">
<summary>
submit a suggested edit to an already-approved person's own fields