<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet href="http://bugs.horde.org/themes/feed-rss.xsl" type="text/xsl"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
 <channel>
  <title>Check state permissions on ticket creation</title>
  <pubDate>Thu, 08 Jan 2009 13:56:59 -0500</pubDate>
  <link>http://bugs.horde.org/ticket/6414</link>
  <atom:link rel="self" type="application/rss+xml" title="Check state permissions on ticket creation" href="http://bugs.horde.org/ticket/6414/rss" />
  <description>Check state permissions on ticket creation</description>

  
  
  <item>
   <title>Recently I setup whups and found that when users are authent</title>
   <description>Recently I setup whups and found that when users are authenticated, they have the permissions to change the state of their ticket to whatever they want at the creation of the ticket. However Guest users are forced to use the default state defined by the administrator. I think their should be an enhancement in permissions or something to allow the administrator to specify whether or not authed users must use default states. </description>
   <pubDate>Sun, 09 Mar 2008 17:32:01 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/6414#t43625</link>
  </item>
  <item>
   <title>We should honor the Assign/Update queue sub-permissions for </title>
   <description>We should honor the Assign/Update queue sub-permissions for guests. That should take care of this.</description>
   <pubDate>Mon, 10 Mar 2008 01:15:37 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/6414#t43638</link>
  </item>
  <item>
   <title>... assuming that when you said &quot;authed&quot; users, you meant un</title>
   <description>... assuming that when you said &quot;authed&quot; users, you meant unauthenticated users?</description>
   <pubDate>Mon, 10 Mar 2008 01:16:19 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/6414#t43639</link>
  </item>
  <item>
   <title>Yes, I meant authenticated users when I said &quot;authed users&quot;.</title>
   <description>Yes, I meant authenticated users when I said &quot;authed users&quot;.</description>
   <pubDate>Mon, 10 Mar 2008 11:27:03 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/6414#t43660</link>
  </item>
  <item>
   <title>&gt; ... assuming that when you said &quot;authed&quot; users, you meant </title>
   <description>&gt; ... assuming that when you said &quot;authed&quot; users, you meant 
&gt; unauthenticated users?

I don't think that *all* authenticated users should have the ability to specify state of a ticket. Sorry for the confusion. I think the guest way works nice, but when the horde users go to submit a ticket, they have the ability to specify state; I don't think that should be the case by default. I think there should be a permissions setting to specify which (if any) authenticated users have permissions to specify ticket state at creation of ticket.</description>
   <pubDate>Mon, 10 Mar 2008 18:42:34 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/6414#t43681</link>
  </item>
  <item>
   <title>Oh. Well that's the assign/update sub-permissions (they're c</title>
   <description>Oh. Well that's the assign/update sub-permissions (they're child permissions of queues).</description>
   <pubDate>Mon, 10 Mar 2008 22:25:49 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/6414#t43683</link>
  </item>
  <item>
   <title>&gt; Oh. Well that's the assign/update sub-permissions (they're</title>
   <description>&gt; Oh. Well that's the assign/update sub-permissions (they're child 
&gt; permissions of queues).

No, you're missing what I'm trying to say. On my system, I have the child permissions their, but none of them (authenticated, guest, creator, etc.) are checked on any of the child permissions (of my queues), but still yet; authenticated (non-administrator) users can create a ticket at whichever state they choose, but guest users can not.  Thank you for your patience.</description>
   <pubDate>Tue, 11 Mar 2008 00:56:54 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/6414#t43687</link>
  </item>
  <item>
   <title>if they can then go and update the ticket to the new state, </title>
   <description>if they can then go and update the ticket to the new state, why do you want to force them to use two steps?</description>
   <pubDate>Tue, 11 Mar 2008 01:06:09 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/6414#t43688</link>
  </item>
  <item>
   <title>&gt; if they can then go and update the ticket to the new state</title>
   <description>&gt; if they can then go and update the ticket to the new state, why do 
&gt; you want to force them to use two steps?

I'm not wanting to force them to two steps.  On my system, I have 3 ticket states (unconfirmed, assigned, accepted) that are available to regular authenticated users when they create a ticket. The default state is uncomfirmed. Guest users can only create a ticket with &quot;unconfirmed&quot; as the state. Their should be a way to force authenticated users to use the default state defined for the ticket type.</description>
   <pubDate>Tue, 11 Mar 2008 03:34:25 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/6414#t43690</link>
  </item>
  <item>
   <title>So you're saying that once the ticket is created, those same</title>
   <description>So you're saying that once the ticket is created, those same users do not have permissions to update the ticket to be Assigned/Accepted?</description>
   <pubDate>Tue, 11 Mar 2008 14:53:15 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/6414#t43717</link>
  </item>
  <item>
   <title>&gt; So you're saying that once the ticket is created, those sa</title>
   <description>&gt; So you're saying that once the ticket is created, those same users do 
&gt; not have permissions to update the ticket to be Assigned/Accepted?

Yes, they don't have those permissions after the ticket is created; but they (somehow) have them at the time of ticket creation.</description>
   <pubDate>Tue, 11 Mar 2008 15:09:20 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/6414#t43719</link>
  </item>
  

 </channel>
</rss>
