Closed yfc845 closed 5 years ago
mrueegg
commented
5 years ago Hi Ian,
The error occurs where the plug-in tries to create a diff between the existing project users and the new ones from the DSL to decide what needs to be updated. Is there a user "admin" in the project permissions?
Best regards, Michael
yfc845
commented
5 years ago We used to define "Admin user" in permissions for many plans, now I have deleted all of these permissions from dsl groovies, and I can confirm that in any project admin is not defined there. Why is dsl still looking for such a user?
yfc845
commented
5 years ago Can you elaborate how dsl compares the diff?
If it uses something from db, then it will be an issue because I went into the db and did a search of:
bamboo=# select * from acl_entry where sid='Admin user';
and I can see thousands of records showing.
yfc845
commented
5 years ago At least I need some more detailed error info which can tell me in which plan there is the issue... or do you know a db query that returns any plan that has "Admin" defined in its permissions?
yfc845
commented
5 years ago OK, now I can confirm it is a mismatch when dsl do the comparison. I changed the option "action for not-referenced bamboo object" from "Delete" to "Ignore" and at least it succeeded... but we still need to change it back to "delete", what should I do?
yfc845
commented
5 years ago I did lots of tests, it looks like: In our previous dsl definition, we defined this:
permissions {
user(name: 'Admin user') {
permissionTypes PermissionType.VIEW,
PermissionType.EDIT
}
......and actually i found that this setting is not in the real plan UI, and after test I confirmed that this codes are wrong, we should use its username but here we used its full name. that is why dsl didn't add it correctly to all plans, although i don't understand why it is not giving us errors before...
so when the seed task is defined to use "delete" policy, it compares the new def with our current def, and our current def is looking for a username "Admin user", which never exists, then it will always fail.
So I guess now the only way to solve this is from db level, running something to remove/update all records with "Admin user" defined.
Do you have any idea?
mrueegg
commented
5 years ago @yfc845 I've just checked that the lower Bamboo version bound (6.2.0 when project permissions where introduced) verifies that the user exists before creating the project permissions. This is why I ask myself how Bamboo could create the permissions for a user that actually doesn't exist with that user name. Could you please tell us which version of Bamboo you used before upgrading to 6.9.0?
yfc845
commented
5 years ago @mrueegg Hi, we upgraded our bamboo from 6.6.0 to 6.9.0, then this issue came.
yfc845
commented
5 years ago No idea what happened, now my dsl build can pass with policy:delete. It is not complain for No Admin user. I asked my colleagues and nobody has done changes.
Anyway, is there a way to create project permission in dsl? We were always defining plan permissions before...
yfc845
commented
5 years ago Hi @mrueegg I think this ticket can be closed because somehow the dsl build passed before we have done any change...this is weird.
mrueegg
commented
5 years ago @yfc845 Thanks for your feedback. Please do not hesitate to re-open the ticket if the problem comes up again.
We are facing below error when running seed job:
Recently we upgraded our bamboo to 6.9.0, and today we found that you released dsl 1.9.15 which is said to be supporting bamboo 6.9.0, but after the upgrade the seed job still fails with the same error.
We don't have any "Admin user" defined in our dsl sourcecodes, why is it looking for it?
Notice that we have such a user in bamboo user directory:
Maybe dsl is looking for a user named "Admin user" but we only have "Admin User" or "admin" ?
Also notice that we used to have below codes in our dsl:
Because of this issue, we deleted every single code that has "Admin user" from sourcecode, but now it is still compaining about it...
Ian