Apache OpenOffice (AOO) Bugzilla – Issue 2778
Can we have an UNCONFIRMED state?
Last modified: 2003-12-27 10:23:17 UTC
there appears to be no way to vote for issues in Issuezilla
test case: do a search for vote on 'any' issue page and you will find that users cannot place votes perhaps this is why there are so few users posting issues? they have no voice...
Reassigning support@ issues to issues@www so louis can go through these.
assigning to support for resolution. louis
I'll take a look at this.
Accepting.
I looked in the "Edit components" page and found that all votes (except in www, where I just changed it to 2) are set to "max votes = 0". This is why no votes are allowed. I'm still figuring out whose responsibility it would be to decide the details on voting.
Stefan: I'm going to assign this to you, because I think you may be the correct person to determine how you would like to set up voting. If you go to the "Edit Components" page, and set "Votes Per User" to be higher than 1, the "Votes" section will appear on each bug page for that component. You can also change "Max Bugs Per Issue" and "Number of Votes Needed to Confirm". Please update and reassign to me if you have any questions. Thanks!
Hi, I played with the component "testproduct" and set MaxPerPerson 5 MaxOnIssue 1 NumberForConfirm 2 a) The initial state of issues isn't UNCONFIRMED. b) Every IZ user can confirm issues. Is there a way to change the default settings for new IZ users?
I'm not sure yet, but I will find out.
Stefan- if you assign issues to me, they may fall through the cracks, like this one did. I'm reassigning this to support.
Reading back, I realize that I wasn't clear. When I say "reassign to me", I usually mean "support@netbeans.org". I'll look into how to get issues to default to "UNCONFIRMED".
> I'll look into how to get issues to default to "UNCONFIRMED". But please only according to the field value (NumberForConfirm > 0).
We are discussing this internally (PCN6926; another client has alwo requested it). We're still researching whether this would require a code change or simply a behind-the-scenes configuration change.
Changing summary.
It looks to me as though if you set NumberForConfirm to greater than zero, people who don't have the "Confirm an Issue" setting can't submit an issue as NEW (it appears as UNCONFIRMED). However, it doesn't look like the "Confirm an Issue" setting is controllable by SourceCast Helm. Looking into it.
Created attachment 1245 [details] Instructions for implementing the Unconfirmed status
Just attached the instructions for setting the unconfirmed status and voting. Implementing this requires administrator permissions in IZ and could involve changes to user permissions that affect the entire domain. Could you provide more information on where you would like to see the Unconfirmed status? Did you have a particular project in mind? If this involved a site wide rollout, we'd want to discuss in details the result of each change. Thanks, Kristen
Michael, does this fit into your QA plans?
Yes, it definitely fits into my QA plans. I'd like to build a QA community that takes the unconfirmed bugs, checks for duplicates, edits the bugs until they meet the requirements of the bug writing guide lines and the dispatches the bugs to the appropriate folks. So I support that the status "unconfirmed" should be the initial status of any reported issue. I'm just not aware of the permission structure. Is everyone allowed to change the unconfirmed status to a different one? Would be great if this privilege could be given to certain users only and I guess IssueZilla provides that feature. But it is not a MUST for me. The voting issue is a completely different thing, I don't really want to set this feature up. If the community has a great proposal for it, I'll comment on that.
Thanks for the description. We (Michael and I) agreed that we would like to go ahead with voting/unconfirmed for "most" components (including www, whiteboard, ???). My understanding is, that - we have to change voting values (5/1/3) for each component by hand. - changing default state to unconfirmed has to be done by you (support) - default of "canconfirm" == false for new users will be done by you - revoke of "canconfirm" for all existing users will be done by you. A special service would be to set "canconfirm" == true for a given list of ~200 users programmaticly. Did I miss something?
Stefan, Yes, you should have the permisisons in issue tracking to be able to make all of these edits. The attachment describes the steps to activate this option in detail. The default state is automatically unconfimed for users who do not have "can confirm" priveleges. (New still appears in the dropdown menu which is confusing but it will be overwritten by unconfirmed) I'll look into setting the default state for new users and removing the can confirm state for existing users. I'm not sure what you mean in your last bullet item but you should also have the permissions to go ahead and add can confirm permissions for any user you choose. I was just trying to check your permissions to verify that you had everything you needed but when I entered your username your user profile (for issue tracking) did not appear. I'll look inot this as well. An important note on providing users with "can confirm". This cannot be set by project (component). Once a user has can confirm status permissions the user can use it on any project for which this option is set. Thanks, Kristen
Stefan, I misspoke. It was not the last bullet item that I was unclear on. I wanted to better understand what you meant by: "A special service would be to set "canconfirm" == true for a given list of ~200 users programmaticly." Thanks, Kristen
Stefan, I was just able to check your permissions and you have everything you need. Thanks, Kristen
Updating status whiteboard to include additional issue pcn 9166 which is looking into removing the default permission of "can confirm" for new users and removing "can confirm" permissions for all users. Thanks, Kristen
> I'm not sure what you mean in your last bullet item but you > should also have the permissions to go ahead and add can > confirm permissions for any user you choose. What I thought of is, that we have about 200 from 10000 users which should have can confirm permissions. After removing the can confirm state for all existing users we had to change 200 users by hand. Could you think of doing that with some kind of script based on a list of usernames?
Stefan, That sounds like a great idea. Could you attach a list of those 200 users to this issue? Perhaps we can take care of all the necessary edits to "can confirm" permisisons at the same time. I'll check with Engineering. Thanks, Kristen
Created attachment 1399 [details] List of users with canconfirm permission
Thanks, Stefan. I've given the list to engineering.
I raised the priority to 1. Please see my comments in 2778, why this is the case. We need both bugs fixed urgently.
Sorry, of course I wanted to say please let take a look at issue 4105 for additional comments regarding the urgency of this issue.
Adjusting priority from P1 since this is not a site down issue. We're stil working on the bug in 4105 that is blocking the implementation of the unconfirmed status. Thanks, Kristen
We've closed 4105. Users had can confirm permissions because the Edit issue permission was selected and overrides the fact that can confirm is not selected. We're now working on making sure that the list of users provided has can confirm and those not on the list do not. In order to prevent new users from being provided with the can confirm and edit any issue Issue tracking permissions by default when they register or are added to the system by an Administrator, you will have to remove the SourceCast permission "Issue Tracking- Change" from the Registered User role. Registered User can still have "Issue Tracking- Query" and "Issue Tracking- Submit". Once the permission is removed, a test user should be created to confirm that the Issue Tracking permissions, can confirm and Edit any issue have not been granted by default. Thanks, Kristen
*** Issue 5163 has been marked as a duplicate of this issue. ***
Increased priority of internal issue. Will update as soon as I have details.
I have received the detail from our engineer on how to go about getting this in place. The last piece of information I need is if we can programatically assign the domain-wide 'can confirm' permission to the user list.
Those users should now all be in the "can confirm" group and have the ability to alter issues as necessary. Please confirm.
Brian, it seems to me that the users we wanted to have canconfirm permissions, have them now. But we have two questions: - you obviously set up a canconfirm group in SourceCast to achieve this. How does this play together with the canconfirm permissions one can set fo each individual user in the IZ user administration? - how can we confirm that the canconfirm option has been revoked for all other users that were registered before we initially didn't give new users such permissions? Thanks, Michael
Mike - In answer to question one, as far as the domain role affecting the IZ permissions goes, no new user who is a registered user will have _any_ permissions in IZ. Question two, I'm not sure that permissions have been revoked on all users. I came across a few users (e.g. bharathi, bhaskar, bhb48) who still have this capability in IssueZilla. I have contacted our engineer on this issue and we are investigating what can be done about this, unless you know something about those particular users that justifies their having those permissions.
We have an approach in place to take care of the IZ permissions and it involves a low-level alteration of the database which we feel should only occur while the system is inactive. To that end, maybe the best time for this would be on Sept 7, when there is scheduled maintenance. If you have another suggested time, please let me know.
Brian, would be great to let me know, _what_ you're planning to do.
Michael - The approach is a low-level db update to remove the two bits that grant IZ users the "editissues" and "canconfirm" rights from all users, but the ~130 in the attachment of this issue. The work should not take very long (less than 20 minutes), but the sandbox will need to be down during that timeframe to ensure there are no conflicting updates happening at the same time. Operations does not want to perform this update during the scheduled maintenance downtime as they have that planned out with responsibilities already. Can you offer some time windows for us to make this change?
Brian, if you announce it in advance, any time is good for me. I guess the attached list is not up-to-date anymore, so I fear you'll steal some people permissions who should have them. To handle this, it would be good to have the downtime during the week and not at the weekend. Additionally I could try to update the list before with at least the people I know should have permissions.
Mike - An updated list of users would be in order given the time frame of our process. Once we get the new list, we will schedule it asap. How much advance notice do you need prior to our performing the work? I've also been told that the 4-6pm pacific timeframe has worked in the past. If that is still the case, we will use that again.
4-6pm pacific timeframe is ok for us.
Created attachment 2714 [details] Users which should have canconfirm permissions (Sept. 02)
Brian, attached find the new list, not too many additions. If you want to, please go ahead. As I mentioned earlier, it would be great to apply this change on a Thursday of a week the latest, so I could give users back permissions on Friday, in case we stole people permissions that should have them.
Thanks. I have forwarded the new list onto our engineers for inclusion into the sql update work.
Brian, please let me know when the update will be executed, we have an announcement ready including more information than just the downtime for maintenance reasons.
Brian, I need a date when you're planning to run the update. People are asking for the canconfirm permission, and I only want to give it to them after the clean-up. Otherwise they would loose the permission right away or I have to update the conconfirm user list all the time, which is not fun.
Brian/Michael, I don't want to hold you back from making the proposed changes. But I still try to understand the effect of the SC role "CanConfirm". I created two new users, posted issues with those accounts, gave the role "CanConfirm". My experience is, that the SC role "CanConfirm" doesn't change anything. The only bits, that count, are "CanConfirm" and "EditIssues" in IZ privileges. Brian, in your comment you said, that "no new user who is a registered user will have _any_ permissions in IZ". I agree and a new user doesn't have the SC role "CanConfirm". What do you think, the effect of attaching the SC role "CanConfirm" is? Thanks, Stefan.
Stefan - I think there is some misunderstanding here. Let me try to clear things up some. There is no SC "can confirm" permission, there is only an IZ "canconfirm" permission. But, there is a SC "canconfirm" _role_ which provides the issuetracking permission "change" and should also hold the IZ "canconfirm" permission. The IZ permission cannot be seen through the UI and I will have to consult with an engineer here to confirm that this permission is enabled for this role. Could you provide me with the names of the users you created so I can check their permissions on the system also? ------ Mike - Will today be acceptable for making the sql change? The engineers are just wrapping up their work on the fix.
Hi, I used users stx013, stx014. To clarify the terms I tried to talk about SC roles and permissions and IZ privileges. That's how things are named at the administrative UIs (SC's UI for roles and permissions and IZ's UI for privileges). As a SC domain admin (or by other special IZ privileges) we (st, ms, mh) are able to see and change privileges for IZ users (opposed to change SC roles and giving roles to SC users). > I will have to consult with an engineer here to confirm > that this permission is enabled for this role. Please go ahead and do that. My test result is, that giving the CanConfirm role to a SC users, doesn't give the IZ user the CanConfirm privilege. Feel free to correct me, if I'm wrong. The bottom line for me is, that the role CanConfirm is useless and we (IZ adminstrators) have to change IZ privileges. That also means, that we can't delegate these changes. In general I would like to see, that you have the appropriate means to test and verify issues. Shall we continue the conversation in personal mail? Thanks, Stefan.
Stefan - I think you are right, we should continue our conversation via email and let this ticket remain focussed on its original intent. Michael - the change has been made to the database. It happened without my complete awareness. The sql was in place for the alteration, but one of the engineers thought it was corrupt. Due to that, they wanted to put off the change for a day or two, but it was determined it was not corrupted and they went through with the change friday afternoon. The alterations were successful.
Brian, as expected one or the other user has been deprived of some permissions he had before the update. No big deal, we just give them back. Only two issues I have: 1. It would be great that if I next time ask not to apply changes like that on a Friday, to take my opinion into consideration. 2. Can we close this issue now? This ID is a great example of how bugs shouldn't look like, dozens of side-tracks, dozens of comments that got nothing to do with the real subject of the bug. If you and Stefan still need this ID for some reason, please let me know, I don't.
Hi, I expected that Brian closed the issue if it's resolved from his point of view. I don't need it - as we agreed to follow-up by email. Greetings, Stefan.
clsoing this issue.
As agreed by Louis I will close these resolved fixed support-owned issues now. If you have trouble with that, please re-open the issue.