Ticket #6994 (closed Bug: fixed)
Plone 3 Global group-role can not be unselected
| Reported by: | narrowneck | Owned by: | rsantos |
|---|---|---|---|
| Priority: | critical | Milestone: | 3.0.6 |
| Component: | Users/Groups | Keywords: | role roles unselect global |
| Cc: | G.J.Perrin@… |
Description
In Plone UI
Site Setup > User/ Groups > Groups tab > Add New Group TestNewGroup (and title NOT the same as ID or other group or ID) Save Select some roles for TestNewGroup Apply Changes
All good so far.
Unselect the roles set for TestNewGroup Apply Changes
Original selected roles reappear reselected!
Same behaviour with subsequent roles. Once selected and applied a role can not be unselected and applied with success. No error messages just tick reappear in select boxes. Running in Debug mode and css debug. Plone 3.0 18 August.
Change History
comment:1 Changed 4 years ago by limi
- Owner changed from somebody to wichert
- Priority changed from major to critical
- Component changed from Unknown to Users/Groups
comment:2 Changed 4 years ago by limi
- Owner wichert deleted
OK, tried fixing this by using the :default marshaller option (similar to how it's done in Archetypes' boolean.pt), but I couldn't figure it out. Here's the relevant AT template example:
http://dev.plone.org/archetypes/browser/Archetypes/trunk/skins/archetypes/widgets/boolean.pt#L40
Anyone else want to give it a shot? :)
comment:3 Changed 4 years ago by rsantos
The problem is not in the interface. It is in 'PlonePAS.tools.groups.GroupsTool.editGroup'. It was ignoring the empty list of roles. I committed a fix to PlonePAS.
comment:6 Changed 4 years ago by patrimith
FYI fix was in http://dev.plone.org/collective/changeset/51366 51366.
comment:9 Changed 4 years ago by grahamperrin
- Status changed from closed to reopened
- Resolution fixed deleted
Advice please: for as long as I'm limited to version 3.0.2 of Plone (awaiting the installer for Mac OS X):
- as a rule of thumb, is it OK/recommended to install files such as the two shown at http://dev.plone.org/collective/changeset/51366?
comment:10 Changed 4 years ago by wichert
- Status changed from reopened to closed
- Resolution set to fixed
Don't reopen this bug - it has been fixed.
There is no rule of thumb, but in this case replacing those two files should work fine.
comment:11 Changed 4 years ago by grahamperrin
Thanks - the revised files do seem to resolve the issue in Plone 3.0.2.
comment:12 Changed 4 years ago by grahamperrin
Fix confirmed. Thanks.
Plone 3.0.4 CMF-2.1.0 Zope (Zope 2.10.5-final, python 2.4.4, darwin) Python 2.4.4 (#1, Dec 10 2007, 16:52:36) [GCC 4.0.1 (Apple Computer, Inc. build 5332)] PIL 1.1.6
comment:13 Changed 4 years ago by esrever_otua
- Status changed from closed to reopened
- Resolution fixed deleted
- Milestone changed from 3.0.4 to 3.0.x
This has regressed with the latest Plone release (3.0.5). See line 108:
http://dev.plone.org/collective/browser/PlonePAS/tags/3.1/Products/PlonePAS/tools/groups.py
versus the previously committed changeset:
comment:14 Changed 4 years ago by rsantos
Plone-3.0.5 is using PlonePAS-3.1. The fix is in branch 3.x (included in the buildout branch for plone-3.0) and somehow wasn't included in the last release of PlonePAS. I've forward-ported the fix to trunk. Hope we can have a new bugfix release before 3.0.6...
comment:15 Changed 4 years ago by wichert
- Status changed from reopened to closed
- Resolution set to fixed
This has been fixed, the fix just has not made it into a Plone release yet. That's no reason to keep this bug open though.
comment:16 Changed 4 years ago by esrever_otua
???? So.... Are we saying that it will be in Plone 3.0.6? Given that this is not actually fixed in any released version of Plone (and there have been two released since the fix was committed to svn), I would have been more inclined to leave this bug open until such time as there is actually a Plone release out there that is fixed.
Perhaps trac needs another state aside from open/closed: release_pending...

Yup, can confirm this for Plone 3.0 final. Should be fixed in 3.0.1, this is bad.
(I assume it's the old classic: checkboxes aren't in the request when a form is submitted without them, hence the values aren't changed)