[
https://issues.apache.org/jira/browse/JCR-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavel Heyman updated JCR-3946:
-------------------------------
Description:
Code in question for org.apache.jackrabbit.core.lock.LockImpl
{code:java}
public String getLockToken() {
if (!info.isSessionScoped() && (info.isLockHolder(node.getSession()) ||
isAdminUser(node.getSession()))) {
return info.getLockToken();
} else {
return null;
}
}
{code}
So if the a Non-Admin User creates a lock and the session is not scoped, they
are unable to retrieve the lock...which seems counter-intuitive since the
lockholder is very much related to session instantiated in the first place.
Shouldn't it be related more to session.getUserID()?
was:
Code in question for org.apache.jackrabbit.core.lock.LockImpl
{code:java}
public String getLockToken() {
if (!info.isSessionScoped() && (info.isLockHolder(node.getSession()) ||
isAdminUser(node.getSession()))) {
return info.getLockToken();
} else {
return null;
}
}
{code}
So if the a Non-Admin User (NAU) creates a lock and the session is not scoped,
they are unable to retrieve the lock...which seems counter-intuitive since the
lockholder is very much related to session instantiated in the first place.
Shouldn't it be related more to session.getUserID()?
> LockImpl getLockToken missing scenario
> --------------------------------------
>
> Key: JCR-3946
> URL: https://issues.apache.org/jira/browse/JCR-3946
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Affects Versions: 2.6.5, 2.10.1
> Reporter: Flavel Heyman
> Labels: LockImpl, locking, locks, session-scope
>
> Code in question for org.apache.jackrabbit.core.lock.LockImpl
> {code:java}
> public String getLockToken() {
> if (!info.isSessionScoped() && (info.isLockHolder(node.getSession())
> || isAdminUser(node.getSession()))) {
> return info.getLockToken();
> } else {
> return null;
> }
> }
> {code}
> So if the a Non-Admin User creates a lock and the session is not scoped, they
> are unable to retrieve the lock...which seems counter-intuitive since the
> lockholder is very much related to session instantiated in the first place.
> Shouldn't it be related more to session.getUserID()?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
