Tracker log

Given no response from Rob, this certainly sounds right to me. No tests are broken from the change. I've committed the change to trunk and it will be released in 2.0.

Issue state: Confirmed → In progress.
Added 706 day(s) ago.

Responsible manager: rafrombrc → rossp.
Added 706 day(s) ago.

Actually I take that back due to a false negative. The functional tests I've added show this not being a problem and I can't reproduce it on a real instance either. Can you try reproducing this with membrane and remember trunk? If you can still reproduce this just let me know and I'll resurrect this issue.

Issue state: Confirmed → Rejected.
Added 707 day(s) ago.

I've confirmed this in functional tests. Working on it now.

Issue state: Unconfirmed → Confirmed.
Severity: Medium → Important.
Responsible manager: (UNASSIGNED) → rossp.
Target release: None → 2.0.
Added 707 day(s) ago.

Issue state: Confirmed → In progress.
Added 714 day(s) ago.

Issue state: Confirmed → In progress.
Added 714 day(s) ago.

Good catch. Committed to trunk to be released in 2.0. Thanks!

Issue state: Unconfirmed → Confirmed.
Severity: Medium → Low.
Responsible manager: (UNASSIGNED) → rossp.
Target release: None → 2.0.
Added 714 day(s) ago.

Unfortunately this patch is inappropriate because it would grant the permission to the member for their own member object. IOW, a member should not be allowed, by default, to copy their own member object and create a new member object, nor should they be allowed to rename (move) their member object.

It's possible that the fix to #64 will address this as well. Can you try again with remember trunk (or 2.0 when I cut a release)? If you still experience the problem I'll resurrect this issue.

Thanks!

Issue state: Unconfirmed → Rejected.
Responsible manager: (UNASSIGNED) → rossp.
Target release: None → 2.0.
Added 714 day(s) ago.

This has been fixed on trunk and will be released in 2.0. Just an FYI for now.

Issue state: Unconfirmed → Confirmed.
Severity: Medium → Critical.
Responsible manager: (UNASSIGNED) → rossp.
Target release: None → 2.0.
Added 714 day(s) ago.

Plone 3.3.2 introduced a permission check in the portal_factory tool. It is now required to have 'Add portal content' in order to use the factory.

http://dev.plone.org/plone/ticket/8748

http://dev.plone.org/plone/changeset/30779

Added 738 day(s) ago.

There's a duplicate msgid in the member schema.

Both the "mail_me" and "must_confirm_password" boolean fields
are using the same I18N msgid for it's labels.

A patch is attached (w/o altering the pot file)

Added 842 day(s) ago.

An update: I no longer got this error after reinstalling Plone.

Added 926 day(s) ago.

when using portal factory (e.g. adding an item through plone add menu) on a FolderishMember based member, we get a Copy Error. Looks to me like owner should be able to "Copy or Move" content so that the content rename that is executed by portal factory is allowed. The attached patch adds these permission across all states and allows members to add content to their member object.

Added 928 day(s) ago.

Since sampleremember behaves properly it's not clear that this is an issue in membrane/remember/sampleremember. It may be a problem in your deployment or modifications. Ask for help on the list and if this is confirmed as a bug through such discussions we can re-open this ticket.

Issue state: Unconfirmed → Rejected.
Responsible manager: (UNASSIGNED) → rossp.
Added 938 day(s) ago.

Since it's not clear that this is a bug in membrane/remember, best to ask for help on the list first. If this is confirmed as a bug through such discussions, we can reopen this ticket.

Issue state: Unconfirmed → Rejected.
Responsible manager: (UNASSIGNED) → rossp.
Added 938 day(s) ago.

Issue state: Unconfirmed → Resolved.
Responsible manager: (UNASSIGNED) → rossp.
Target release: None → 1.1.
Added 938 day(s) ago.

Seems to work agains trunk/2.0dev now

Issue state: Unconfirmed → Rejected.
Responsible manager: (UNASSIGNED) → rossp.
Target release: None → 2.0.
Added 938 day(s) ago.

Thanks, required a little adjusting but it's on trunk now targeted for 2.0.

Issue state: Unconfirmed → Resolved.
Responsible manager: (UNASSIGNED) → rossp.
Target release: None → 2.0.
Added 938 day(s) ago.

While I'm tempted t agree that the proposed behavior might be more correct, I'm not sure this is so clear. Removing View from the container might cause various problems. What about sites where member profiles are public? What comlications might this cause since registration is done as Anonymous? I can imagine many more such questions.

Since this isn't clear and might cause so many problems, I'm gonna have to reject this for now. I'd certainly take a look at a patch or branch, however, if anyone ever did this.

Issue state: Unconfirmed → Rejected.
Severity: Medium → Low.
Responsible manager: (UNASSIGNED) → rossp.
Added 938 day(s) ago.

Rob, can you comment on this real quickly and then reassign to me?

Issue state: Unconfirmed → Confirmed.
Responsible manager: (UNASSIGNED) → rafrombrc.
Target release: None → 2.0.
Added 938 day(s) ago.