Потому что вы должны указать ближайшему общему родителю .closest('tr')
, прежде чем переходить обратно вниз по дереву:
var codeText = $(this).closest('td').eq(1).text();
$(".checkBoxItem").on("change", function() {
var $tr = $(this).closest('tr');
var nameText = $tr.find('td').eq(0).text();
var codeText = $tr.find('td').eq(1).text();
console.log(nameText);
console.log(codeText);
});
<table>
<tbody id="expTableValues">
<tr class="no-border">
<td class="nameText"><label><input type="checkbox" class="checkBoxItem">Director</label></td>
<td class="text-center codeText">Balkar</td>
<td class="text-right"><a class="mouseOverTooltip rowIcon color-amber deleteCenter"><i class="fas fa-trash-alt" data-toggle="tooltip" data-original-title="Delete"></i></a><a href="#" class="rowIcon editCenter"><i class="fas fa-file-signature" data-toggle="tooltip" data-original-title="Edit"></i></a></td>
</tr>
</tbody>
</table>
<script src="//code.jquery.com/jquery-3.3.1.min.js"></script>
Также, поскольку вы уже используете классы nameText
и codeText
, еще лучше, сослаться на них:
var codeText = $(this).closest('td').eq(1).text();
[1111 ]
$(".checkBoxItem").on("change", function() {
var $tr = $(this).closest('tr')
var nameText = $tr.find('.nameText').text();
var codeText = $tr.find('.codeText').text();
console.log(nameText);
console.log(codeText);
});
<table>
<tbody id="expTableValues">
<tr class="no-border">
<td class="nameText"><label><input type="checkbox" class="checkBoxItem">Director</label></td>
<td class="text-center codeText">Balkar</td>
<td class="text-right"><a class="mouseOverTooltip rowIcon color-amber deleteCenter"><i class="fas fa-trash-alt" data-toggle="tooltip" data-original-title="Delete"></i></a><a href="#" class="rowIcon editCenter"><i class="fas fa-file-signature" data-toggle="tooltip" data-original-title="Edit"></i></a></td>
</tr>
</tbody>
</table>
<script src="//code.jquery.com/jquery-3.3.1.min.js"></script>
После небольшой проверки я обнаружил, что проблема заключается в этой строке в хранимой процедуре aspnet_Users_DeleteUser:
IF ((@TablesToDeleteFrom & 1) <> 0 AND
(EXISTS (SELECT name FROM sysobjects WHERE (name = N'vw_aspnet_MembershipUsers') AND (type = 'V'))))
Есть еще 3 аналогичные строки для 3 других таблиц. Проблема в том, что если пользователь, выполняющий хранимую процедуру, не имеет доступа к vw_aspnet_MembershipUsers, она не появляется при выборе из sysobjects. Мне интересно узнать, зачем нужен весь этот оператор EXISTS.
Независимо от этого, в следующем обсуждении, "Доступ к объектам sysobjects для просмотра таблиц пользователей без доступа непосредственно к таблицам пользователей в SQL Server Security", есть ответ. Предоставив "VIEW DEFINITION" для рассматриваемых представлений, утверждения EXISTS теперь будут успешными, и вам не придется предоставлять ненужные, нежелательные или чрезмерные разрешения пользователю в строке подключения вашего приложения.
I also had this issue and it was caused by missing views, to correct I just used the create script from another database and recreated all the vw_aspnet_* views.
Хорошо, угадайте что? Я считал это: http://forums.asp.net/t/1254087.aspx
Хорошо, спустя несколько минут после отправки моего сообщения я нашел решение :) Оказывается, что ИЗБРАННОЕ РАЗРЕШЕНИЕ должно было быть добавлено для пользователя ASPNET на представлении vw_aspnet_MembershipUsers.
Но это - все еще тайна, почему я не получил ошибку относительно отсутствия разрешения. Оператор EXIST просто возвращал false.
и дал производственное пользовательское разрешение ВЫБОРА и вуаля!Работает!Спасибо, ребята!
Я полагаю, что Вашим 'ССЫЛОЧНЫМ' ограничением является на самом деле Внешний ключ в базе данных, которая существует между aspnet_Users таблицей и aspnet_UsersInRoles таблицей. Я полагал бы, что пользователь, которого Вы судите, имеет, это - UserId в обеих таблицах, и прежде чем можно будет удалить его из таблицы Users, это должно быть удалено из таблицы UsersInRoles также.
Вы попробовали http://msdn.microsoft.com/en-us/library/system.web.security.roleprovider.removeusersfromroles.aspx, чтобы гарантировать, что все роли удалены от этого пользователя? Вы могли проверить также путем осмотра строк этих двух таблиц в базе данных.
If the error (or similar) still persists after granting the ASP user SELECT on the vw_aspnet_MembershipUsers, you may want to grant SELECT for some of the other vw_aspnet_???? views too. Especially "profile" and "UsersInRoles". Otherwise - for some reasons, the DeleteUser SP gets an empty result when SELECTING from those views and refuses to delete existing entries from them first.