AWS GuardDuty Add-on for Splunk: Why is local.meta not taking precedence over default.meta?

[jordanfosterpau]

Using AWS GuardDuty app and users unable to share report as it errors with:

User 'testuser' with roles { guard duty dashboard share, testuser, power, user } cannot write: /nobody/TA-aws_guardduty/views/testdashboard { read : [ * ], write : [ admin ] }, export: global, removable: no, modtime: 1518558159.740556000

The stanza in $SPLUNK_HOME/apps/TA-aws_guardduty/metadata/local.meta has:

[] 
access = read : [ * ], write : [ admin, aws_gaurdduty, guard duty dashboard share, power ] 
export = system 
version = 7.0.1 
modtime = 1518558159.740556000

Stanza (default.meta):

[]
access = read : [ * ], write : [ admin ]
export = system

So it should be taking precedence over default.meta but as shown in the error, only admin is set to write although local.meta shows other roles.
Other apps seem to be working. Tested/Compared to Search & Reporting and Splunk App for AWS (5.1.0)

Steps to Reproduce

As a user without 'admin' role, create a new dashboard in GuardDuty add-on. (no need to create panels)
Go to Save as on the dashboard, choose Shared in App, click Create Dashboard, and the error appears with incomplete roles in write permissions.
Go to manage apps and choose Permissions for GuardDuty add-on and verify other roles selected beside just admin.

So, why does it appear that local.meta is not taking precedence?

[jordanfosterpau · Accepted solution]

I found a work around.
I should have included the other stanza in default.meta to my OP.

[views]
access = read : [ * ], write : [ admin ]
export = system

I tried adding a [views] stanza into local.meta to see if it would take precedence and did. However, I was not able to use the webgui to make permission changes. I looked at some other apps and the system default and did not see a [views] stanza in those meta files, so I removed the [views] from local.meta and commented it out in default.meta.
Now I can alter permissions in the webgui and see those propagated to the dashboard permissions. Now users, with the proper role, can share their dashboards as expected.