[rt-users] Issues with Article Permissions
Hello all, I'm having an issue when attempting to create a new article as the root (SuperUser rights) account. It simply says Permission denied I'm at a bit of a loss here. Root user has access to everything. Perhaps there is an issue with our configuration somewhere, but unsure. Has anyone else experienced this? Thanks, Matthew
Re: [rt-users] SelfService and custom status
Is it possible that your RT configuration has non-identical global rights for owners and requestors (Admin Global Group Rights)? On Thu, 5 Mar 2015 at 00:10 elif...@free.fr wrote: Hello Alex, Many thanks for you answer : -- Have you considered setting these users up as privileged instead, with minimal rights? This is not what we want, but I've done it for some tests just to check, and the problem is the same. I've come to the conclusion that even when the Requestor role is granted all the rights (general and for staff, at queue level), the privileged requestor does not see in the ticket the specific statuses from the lifecycle of the queue. The owner role, same rights, same ticket, the owner sees in the ticket the specific statuses of the lifecyle. Thanks again, Elisabeth On Sat, 28 Feb 2015 at 01:31 elif...@free.fr wrote: Hello, On our RT 4.2.6, I created a lifecycle support with specifics status, which is working fine. The requestor is unprivileged, but is granted the right ModifyTicket (globally), and ShowTicket, Watch and ReplyToTicket on the queue. The queue has the support lifecycle. On SelfService interface, the requestor sees his ticket, can display it, can reply, and can modify the status : but the status are not the ones of the lifecycle support, but the one of the default lifecycle ! I made a test as a requestor and changed to status stalled which does not exist in the lifecyle support. Now, as a superuser I cannot change the status at all, there's only stalled an stalled (unchanged) listed ! I've been searching for quite a long time, but now I can't figure out what is going wrong. The second point is that I intended to add a ResolveRight to the lifecycle support to allow unprivileged requestors to resolve their tickets via the SelfService interface. I'm wondering now if it's possible. Thanks for your help again, Elisabeth
Re: [rt-users] SelfService and custom status
Hello Alex, Many thanks for you answer : - Mail original - | Have you considered setting these users up as privileged instead, | with minimal rights? This is not what we want, but I've done it for some tests just to check, and the problem is the same. I've come to the conclusion that even when the Requestor role is granted all the rights (general and for staff, at queue level), the privileged requestor does not see in the ticket the specific statuses from the lifecycle of the queue. The owner role, same rights, same ticket, the owner sees in the ticket the specific statuses of the lifecyle. Thanks again, Elisabeth | On Sat, 28 Feb 2015 at 01:31 elif...@free.fr wrote: | | Hello, | | | On our RT 4.2.6, I created a lifecycle support with specifics | | status, which is working fine. | | | The requestor is unprivileged, but is granted the right | | ModifyTicket | | (globally), and ShowTicket, Watch and ReplyToTicket on the queue. | | The queue has the support lifecycle. | | | On SelfService interface, the requestor sees his ticket, can | | display | | it, can reply, and can modify the status : but the status are not | | the ones of the lifecycle support, but the one of the default | | lifecycle ! | | | I made a test as a requestor and changed to status stalled which | | does | | not exist in the lifecyle support. Now, as a superuser I cannot | | change the status at all, there's only stalled an stalled | | (unchanged) listed ! | | | I've been searching for quite a long time, but now I can't figure | | out | | what is going wrong. | | | The second point is that I intended to add a ResolveRight to the | | lifecycle support to allow unprivileged requestors to resolve | | their tickets via the SelfService interface. I'm wondering now if | | it's possible. | | | Thanks for your help again, | | | Elisabeth |
