Object Authorizations broken in AWI?

[Carsten Schmitz]

​Hi.

I am an Administrator, I have write permissions to '*', and I have all the privileges. We have no "not" rules anywhere.

Regardless, I can not save the "Object Authorizations" for any object (that "backwards" permission system hack that, I think, allows giving rights on an individual object to people or groups). It always says I don't have write permissions.

Is this a bug? Can anyone who believes he's a full blown admin with all the rights confirm?

Thanks :)

(edit: this is 12.3.1.)

------------------------------
These contain very good advise on asking questions and describing supposed bugs (no, you do not need to go to StackExchange for Automic questions, but yes, the parts on asking detailed, useful questions ARE usually relevant):

http://www.catb.org/~esr/faqs/smart-questions.html

https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

I will not respond to PM asking for help unless there's an actual reason to keep the discussion off of the public forums.
------------------------------
​

[Christoph Rekers]

Hi Carsten,

Are you part of "LESEZUGRIFF"?

Cheers
Christoph

------------------------------
----------------------------------------------------------------
Automic AE Consultant and Trainer since 2000
----------------------------------------------------------------
------------------------------

[Carsten Schmitz]

​Hi Christoph,

no, but I get the same error message for everything I try, "LESEZUGRIFF" is just an example for that screenshot. I also get the error for groups I am actually part of in that dropdown, for my own user object, or for "*".

Best regards,
Carsten

[Christoph Rekers]

I havn't checked it but I'm pretty sure that the User group needs to have at least R|W rights and that it is not sufficient that only you - as a member of that group - has R|W rights. So in summery: At least you or the user group - of which you are a member - needs to have at least R|W rights if you want to make use of the "Object Authorization" .

Cheers
Christoph

------------------------------
----------------------------------------------------------------
Automic AE Consultant and Trainer since 2000
----------------------------------------------------------------
------------------------------

[Carsten Schmitz]

You are right! Thanks!

Yet initially after reading your response, I didn't understand how exactly this was meant. I was still thinking you meant permissions to modify the object in the "normal" permission system. But that isn't it - it's about giving someone else and yourself Object Permissions at the same time. That's the solution.

I got on track fully when I made a new object and tried to give myself "R" rights only. That's when you get this type of error:

Then it dawned on me that this is an ill-fated lockout prevention! And lo behold, the key to not getting the red Java error is to always add oneself, or a group oneself is in that has RW along with the actually desired change in an atomic operation, like so:

So it's not exactly broken. But omg what a conceptual and UI mess this is. All in my humble opinion:

• the whole concept is a backwards hack of the permission system
• the error message has two forms, the "yellow one" and the "red one"
• neither of these is sufficiently descriptive
• and the best part: if "Alice" gives object permissions on an object to "Alice" (rw) and "Bob" (r), two individual users (which is possible, I tested it), and Alice leaves the company, then no Administrator, no set of permissions can ever delete these object permissions, delete the object itself, or even look at the object.
  
  Unless someone impersonates "Alice" (which will be especially fun if her account has been purged), the object will stay a Zombie object until the end of time.

Is this likely to happen? Yes. That's exactly what we had, and what triggered this question in the first place ...

Cheers :)

------------------------------
These contain very good advise on asking questions and describing supposed bugs (no, you do not need to go to StackExchange for Automic questions, but yes, the parts on asking detailed, useful questions ARE usually relevant):

http://www.catb.org/~esr/faqs/smart-questions.html

https://www.chiark.greenend.org.uk/~sgtatham/bugs.html

I will not respond to PM asking for help unless there's an actual reason to keep the discussion off of the public forums.
------------------------------

[Christoph Rekers]

I always tell admins: if you really wonna get f*cked up you give users the privelege "Deal with authorizations at object level". I've heard of users that had to leave the company and they wanted to make sure they were kept in memory ... and they created a job that created a file, a hugh file, every 5 minutes...takes a while, until you figure out what makes the hard drive fill up and how to stop that job...so, admins: CHECK YOUR USER'S PRIVILEDGES!!!

Cheers
Christoph 

------------------------------
----------------------------------------------------------------
Automic AE Consultant and Trainer since 2000
----------------------------------------------------------------
------------------------------

[Christoph Rekers]

Just checked whether it's sufficient that the user of a group has R|W rights => it isn't. And BTW: the object authorization is nothing new, it exists since V3. And the JavaUI message is the same as in AWI (s. screen shot below)

Cheers
Christoph 

------------------------------
----------------------------------------------------------------
Automic AE Consultant and Trainer since 2000
----------------------------------------------------------------
------------------------------

[Carsten Schmitz]

​and they created a job that created a file, a hugh file, every 5 minutes

I could swear I have seen plenty such jobs by folks who didn't even strive to leave a lasting legacy. The only way to prevent that is to take away from everyone the "use Automic" privilege ;)

Thanks for the Java UI screenshot. Yeah, I figured this has been a feature for quite some time, but it's still a badly designed one, imho.

Best regards,
Carsten