As of April 12th, you must go to Progress SupportLink to create new support cases or to access existing cases. Please, bookmark the SupportLink URL and use the new portal to contact the support team.
I'm trying to create a PreSave hook on one of my collections that adds a write and read group to the entity's acl before saving it. However, when the entity is saved the _acl looks like this:
The interesting thing here is that the "groups" object doesn't follow the format as per the documentation. The documentation states that the _acl should be in the format below.:
# Regular entity with a detailed ACL structure included
"_id" : "4ff99979c0c014af6ee2773b",
"field1" : "value1",
"field2" : "value2",
"field3" : "value3",
"r": ["user_id_2", "user_id_3"],
"w": ["user_id_4", "user_id_5"],
"r": ["group_id_1", "group_id_5"],
"w": ["group_id_3", "group_id_4"]
You can see that "groups" should be an object with two arrays "r" and "w". Yet when I call myEntity._acl.addWriterGroup('group_id_1'), it creates a "groups" :  and my group_id_1 is nowhere to be seen.
I'm at a loss as to why it doesn't work. I've tried to manually create the "groups" as an object and then create "r" and "w" as arrays and then push my groupId in to it, but it results in a runtime error saying that it can't parse the JSON in that format. So one of two things is possible:
1. The format has changed and the documentation hasn't been updated
2. There is a bug in the addWriteGroup
Does anybody have any idea?
Can you share your BL PreSave code? Let me see if I can track the issue for you.
I'm basically trying to create a user group with the same Id as the user (this will form part of the code which will allow for the user to have delegates to perform actions on entities on their behalf). The code:
runs successfully, but results in the _acl having "groups" : 
Thank you for taking a look.
I am sorry that this feature isn't working for you, however you have run into a non-working piece of business logic. More unfortunately, this part of our implementation of groups is not going to be fixed and will be addressed in an overhaul to groups which is at least a few months away at this time.
I apologize for the inconvenience that this causes you, but for now the best way to manage this is to add individual users to the _acl field rather than using the implementation of groups.
The path that you are using now should continue to work indefinitely. In the event that we are going to make any changes to groups going forward, we would either version it at the API level, or we would soft deprecate the existing version of things. We try VERY hard not to break legacy code here at Kinvey, because some of the apps running on us are made by development firms and are sold to the (now) owners. Us breaking their code would cost them in downtime and further development costs, and we're very sensitive to that.
In the event that breaking changes are going to be made, we announce them as early as possible.