[PLIP-Advisories] Re: [Plone] #9328: content im-/export
#9328: content im-/export -+-- Reporter: csenger |Owner: csenger Type: PLIP | Status: new Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: Keywords: | -+-- Changes (by bohdan_koval): * cc: koval.bog...@gmail.com (added) Comment: Replying to [comment:6 optilude]: I'd also consider how we deal with partial import and export. It's going to be quite commont to import/export a particular folder and its children, for example. Partial export and import can be easily done, because transmogrifier is implemented as adapter for IFolderish interface and can be called in any folderish context. Another good thing about transmogrifier based ex-/import system is that it can be well tested. Transmogrifier pipeline consists of small sections, which can be individually tested. When I was writing quintagroup.transmogrifier package it was very easy to create unit tests for all blueprints. -- Ticket URL: https://dev.plone.org/plone/ticket/9328#comment:16 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9323: Ship with Vice for syndication
#9323: Ship with Vice for syndication ---+ Reporter: MatthewWilkes |Owner: MatthewWilkes Type: PLIP | Status: new Priority: minor |Milestone: 4.0 Component: Unknown| Resolution: Keywords: | ---+ Comment(by raphael): FWT vote: -1 unless someone convinces me why it needs to go into the core distribution. IMHO this can be handled as an add-on like today. It could certainly be advertised more aggressively if it were more mature. -- Ticket URL: http://dev.plone.org/plone/ticket/9323#comment:9 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9329: Manage actions through-the-plone
#9329: Manage actions through-the-plone ---+ Reporter: igbun |Owner: igbun Type: PLIP | Status: new Priority: minor |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: actions, controlpanel | ---+ Comment(by raphael): I've mixed feelings about this PLIP. One concern is that we would add even more confusion if we need to explain that there are now two different kinds of actions: those managed TTP versus those managed through ZMI although we are dealing with the same action machinery. I also don't by the argument of being nicer. To use actions sensibly you need to know TALES. If you require that you can also handle the ZMI. I'd turn it around and use the future perspective (moving away from CMF actions) as an argument in favor of this PLIP if we can be confident that whatever will come up can be handled through the same UI - ideally without changing it later even. So if this could be turned into a path moving forward (like managing CMF actions now while supporting action tiles or whatever later on) I'd be +1 on this. -- Ticket URL: http://dev.plone.org/plone/ticket/9329#comment:17 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9319: Merging archetypes.fieldtraverser into Product.Archetypes
#9319: Merging archetypes.fieldtraverser into Product.Archetypes --+- Reporter: thet |Owner: Type: PLIP | Status: new Priority: minor |Milestone: 4.0 Component: Archetypes| Resolution: Keywords: Archetypes, traverse | --+- Comment(by raphael): I'm not sure everybody understands the motivation behind this PLIP. At least as I understand it the development of archetypes.fieldtraverser has been initiated by the fact that our current machinery does NOT work for binary data when using AnnotationStorage (AS). AS on the other hand has several advantages over todays default (AttributeStorage) like better performance, lower risk of name clashes, possibility to turn fields into properties (in the Python sense) etc. At least for those reasons I'm using archetypes.fieldtraverser today already myself. The fact that archetypes.fieldtraverser also adds an expanded convenience API might come in handy but I'd consider that secondary. Now, this could continue as an add-on but (1) it has to monkey patch Archetypes quite a bit and that should be avoided (2) it would let us move to AnnotationStorage as default storage for all field types - and don't tell me Archetypes is going to die any time soon ;-) It's used so much in the wild that it will continue even after Plone itself moved away from it if only through all those add-ons that will then pull it in as a dependency. Therefore, I'm +1 on this PLIP. -- Ticket URL: https://dev.plone.org/old/plone/ticket/9319#comment:10 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9331: Invite to share
#9331: Invite to share -+-- Reporter: djay |Owner: djay Type: PLIP | Status: new Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: Keywords: | -+-- Comment(by raphael): FWT vote: -1 for Plone core (but a big +1 for an add-on) -- Ticket URL: http://dev.plone.org/plone/ticket/9331#comment:12 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9321: Reimplement the search form with an eye on usability
#9321: Reimplement the search form with an eye on usability -+-- Reporter: csenger |Owner: csenger Type: PLIP | Status: new Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: Keywords: | -+-- Comment(by raphael): FWT Vote: +1 based on the new proposal -- Ticket URL: http://dev.plone.org/plone/ticket/9321#comment:14 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9328: content im-/export
#9328: content im-/export -+-- Reporter: csenger |Owner: csenger Type: PLIP | Status: new Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: Keywords: | -+-- Comment(by raphael): FWT Vote: +1 although I think that can just as well be an independent add-on -- Ticket URL: http://dev.plone.org/plone/ticket/9328#comment:19 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9330: Add ability to choose role when adding new site members
#9330: Add ability to choose role when adding new site members -+-- Reporter: aclark |Owner: aclark Type: PLIP | Status: new Priority: minor|Milestone: 4.0 Component: Unknown | Resolution: Keywords: | -+-- Comment(by raphael): FWT Vote: +1 if we are using groups and not roles -- Ticket URL: http://dev.plone.org/plone/ticket/9330#comment:19 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9327: unified interface for lists of content
#9327: unified interface for lists of content +--- Reporter: elvix |Owner: elvix Type: PLIP| Status: new Priority: minor |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by raphael): FWT Vote: +1 provided the old stuff stays available for some transitional period as well. -- Ticket URL: http://dev.plone.org/plone/ticket/9327#comment:14 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9327: unified interface for lists of content
#9327: unified interface for lists of content +--- Reporter: elvix |Owner: elvix Type: PLIP| Status: new Priority: minor |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by MatthewWilkes): I've thought about this some more in the last few days, and gradually convinced myself to become +1, but not sure if it'll happen in time. Therefore, FWT Vote (changed): +1 -- Ticket URL: http://dev.plone.org/plone/ticket/9327#comment:15 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #8801: Move action icon support into actions, remove CMFActionIcons
#8801: Move action icon support into actions, remove CMFActionIcons +--- Reporter: hannosch|Owner: davisagli Type: PLIP| Status: new Priority: minor |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by erikrose): +1, assuming... * We can get some DeprecationWarnings into 3.x * This change is documented in the Developer's Upgrade Guide to Plone 4 -- Ticket URL: https://dev.plone.org/plone/ticket/8801#comment:15 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #8802: Move our upgrade / migration infrastructure to GenericSetup
#8802: Move our upgrade / migration infrastructure to GenericSetup ---+ Reporter: hannosch |Owner: davisagli Type: PLIP | Status: new Priority: minor |Milestone: 4.0 Component: Upgrade/Migration | Resolution: Keywords: | ---+ Comment(by erikrose): GS currently runs into problems in real-life situations where things gets removed from sites without being properly uninstalled, refusing to install further products until the improperly removed products are dug up and reinstalled (https://weblion.psu.edu/trac/weblion/wiki/GenericSetup#Troubleshooting). GS makes me a little nervous. Could the proposed code run into similar problems? I vote -1 until the risks are enumerated. -- Ticket URL: http://dev.plone.org/plone/ticket/8802#comment:15 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #8805: Do not ship with NuPlone anymore
#8805: Do not ship with NuPlone anymore ---+ Reporter: hannosch |Owner: Type: PLIP | Status: new Priority: minor |Milestone: 4.0 Component: Templates/CSS | Resolution: Keywords: | ---+ Comment(by erikrose): +1 as long as we ship with some installable-through-the-Plone theme, a la #9315. Also, for upgraders' sake, NuPlone must be made compatible with 4.0 ''or'' be able to be uninstalled cleanly (if it isn't already). -- Ticket URL: http://dev.plone.org/plone/ticket/8805#comment:21 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #8809: Make KSS optional
#8809: Make KSS optional +--- Reporter: hannosch|Owner: Type: PLIP| Status: new Priority: minor |Milestone: 4.0 Component: KSS (Ajax) | Resolution: Keywords: | +--- Comment(by erikrose): I'd rather not change a bunch of stuff that's just going to change again in 5. FWT vote: -1. -- Ticket URL: http://dev.plone.org/plone/ticket/8809#comment:24 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9186: Set Image IDs from Title field
#9186: Set Image IDs from Title field +--- Reporter: erikrose|Owner: Type: PLIP| Status: new Priority: minor |Milestone: 4.0 Component: Archetypes | Resolution: Keywords: | +--- Comment(by erikrose): Abstaining since this is my PLIP. -- Ticket URL: http://dev.plone.org/plone/ticket/9186#comment:24 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9236: Include CachableRedirects or equivalent functionality so that 301 redirects don't pound Zope
#9236: Include CachableRedirects or equivalent functionality so that 301 redirects don't pound Zope +--- Reporter: jonstahl|Owner: Type: PLIP| Status: reopened Priority: minor |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by erikrose): FWT Vote: +1 as long as purging is implemented. In response to rossp, IIRC, this can't be done straightforwardly in CacheSetup due to the really wacky way into which Plone fires off redirects. It all funnels through the error reporting template, which then checks to see if the error is 404. I would like to hook the config into CacheSetup, perhaps via alecm's suggestion of an empty skin template. -- Ticket URL: https://dev.plone.org/plone/ticket/9236#comment:16 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #8814: Replace SecureMailHost with a standard Zope mailhost
#8814: Replace SecureMailHost with a standard Zope mailhost +--- Reporter: hannosch|Owner: alecm Type: PLIP| Status: new Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by erikrose): Does SecureMailHost presently fire off DeprecationWarnings? If not, I think we should before ripping it out. FWT vote: -1 until some deprecation warnings are added in some (possibly 3.x) release. -- Ticket URL: http://dev.plone.org/plone/ticket/8814#comment:18 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9214: support logins using e-mail address instead of user id
#9214: support logins using e-mail address instead of user id ---+ Reporter: davisagli |Owner: maurits Type: PLIP | Status: new Priority: minor |Milestone: 4.0 Component: Unknown| Resolution: Keywords: | ---+ Comment(by erikrose): Having spent a lot of time in the PAS and membership code, I'm concerned at adding more branches in there; there are a lot of cleanups that should happen first. * As alecm says, we need need NEED to stop using loginname to reference users internally; userid is the correct immutable key. I routinely change loginnames when clients move from Plone's built-in auth to our Kerberos auth. * The OpenID plugin has to do some truly awful hacks (the same ones I do in WebServerAuth) to be able to authenticate a non-enumeratable user; that needs to get fixed in PAS. * The setting of the last-login time and, IIRC, the firing of some important events are essentially hard-coded into the login_form. These should be moved elsewhere so non-form-based login can be a first-class citizen. I wonder if email-based login could be better implemented as an add-on once we improve the hook situation in PAS and the rest of the auth code. FWT vote: -1 for now. I think the idea is good, given that so many people seem to request this, but I want to be sure we implement it in a maintainable way rather than just glomming more branches onto an already hard-to-follow subsystem. -- Ticket URL: https://dev.plone.org/plone/ticket/9214#comment:24 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #8814: Replace SecureMailHost with a standard Zope mailhost
#8814: Replace SecureMailHost with a standard Zope mailhost +--- Reporter: hannosch|Owner: alecm Type: PLIP| Status: new Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by alecm): I think the only method we'd have to deprecate is secureSend. I'll probably end up patching that into our new mailhost along with a deprecation warning. The patched method could then be removed in a later release. There are also some convenience regexps and similar in SMH that developers may be importing and relying on. We may want to consider providing some BBB imports for those, since they can be quite convenient. -- Ticket URL: http://dev.plone.org/plone/ticket/8814#comment:19 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9320: Add global status bar for site notifications
#9320: Add global status bar for site notifications +--- Reporter: limi|Owner: mj Type: PLIP| Status: new Priority: n/a |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: | +--- Comment(by raphael): FWT vote: -1 for Plone core - +1 for add-on -- Ticket URL: http://dev.plone.org/plone/ticket/9320#comment:14 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9186: Set Image IDs from Title field
#9186: Set Image IDs from Title field +--- Reporter: erikrose|Owner: Type: PLIP| Status: new Priority: minor |Milestone: 4.0 Component: Archetypes | Resolution: Keywords: | +--- Old description: '''Proposed by:''' Erik Rose[[BR]] '''Seconded by:''' (Step right up!) == The Problem == The Image type chooses the IDs of new objects differently than other types: rather than transforming the Title (My Dog Watches Me Eat becoming my-dog-watches-me-eat), they use the name of the uploaded file. This has several disadvantages: 1. Inconsistency with other types. 8.5 (yes, there was a half) out of 14 of our Plone user's group attendees today find the current behavior surprising or counterproductive. Only 1 actively prefers the current behavior. The rest don't see any problem in changing it. 1. Many common use cases involve images whose filenames are autogenerated and uninformative. All these cases result in URLs like `Picture%201.PNG`, which are uninformative, subjectively funny looking, and hard to remediate without first renaming and then re-uploading a large file: * Screenshots on a Mac come with titles like `Picture 1` and, because their lifetimes on disk are typically short, aren't often renamed. * Pictures from cameras look like `P1090404.JPG`. * Flickr images look like `3425573738_90e84302e8.jpg`. 1. When screenshots are routinely uploaded to the same folder (say, a site-wide `images` folder), everybody but the first uploader of `Picture 1.png` is met with an error—There is already an item named Picture 1.png in this folder.—and has to do a context switch back to another app to rename the file (which, if the user had good reason to name the local file Picture 1, is pretty intrusive). 1. The case of image extensions differs depending on platform. Windows tends to use capital `.JPG`; Mac, `.jpg`. Such inconsistency makes URLs hard to guess. 1. There's no other way in Plone, short of manually enabling short-name editing, to end up with capital letters in URLs. == The Proposal == * Have Images choose their IDs based on entered Titles, as with other types. * Make the Title field required, as with other types. Choosing an image file should stick its name in the Title field via JS if that field was empty, thus effectively providing the current behavior as an option as well as showing the user what's about to happen. * ~~If browsers are awful and require file extensions in URLs~~ (which they don't), ~~compute them from the uploaded MIME type using the existing `guess_content_type()` machinery or something. This solves the inconsistency where some files say `.jpg`, others `.jpeg`, and still others `.JPG`.~~ == Addendum: the File type == P.S. Though this PLIP shouldn't succeed or fail based on this, we might also consider making a similar change to the behavior of the File type. New description: '''Proposed by:''' Erik Rose[[BR]] '''Seconded by:''' (Step right up!) == The Problem == The Image type chooses the IDs of new objects differently than other types: rather than transforming the Title (My Dog Watches Me Eat becoming my-dog-watches-me-eat), they use the name of the uploaded file. This has several disadvantages: 1. Inconsistency with other types. 8.5 (yes, there was a half) out of 14 of our Plone user's group attendees today find the current behavior surprising or counterproductive. Only 1 actively prefers the current behavior. The rest don't see any problem in changing it. 1. Many common use cases involve images whose filenames are autogenerated and uninformative. All these cases result in URLs like `Picture%201.PNG`, which are uninformative, subjectively funny looking, and hard to remediate without first renaming and then re-uploading a large file: * Screenshots on a Mac come with titles like `Picture 1` and, because their lifetimes on disk are typically short, aren't often renamed. * Pictures from cameras look like `P1090404.JPG`. * Flickr images look like `3425573738_90e84302e8.jpg`. 1. When screenshots are routinely uploaded to the same folder (say, a site-wide `images` folder), everybody but the first uploader of `Picture 1.png` is met with an error—There is already an item named Picture 1.png in this folder.—and has to do a context switch back to another app to rename the file (which, if the user had good reason to name the local file Picture 1, is pretty intrusive). 1. The case of image extensions differs depending on platform. Windows tends to use capital `.JPG`; Mac, `.jpg`. Such inconsistency makes URLs hard to guess. 1. There's no other way in Plone, short of manually enabling short-name editing, to end up with capital letters in URLs. == The Proposal == * Have
[PLIP-Advisories] Re: [Plone] #9186: Set Image IDs from Title field
#9186: Set Image IDs from Title field +--- Reporter: erikrose|Owner: Type: PLIP| Status: new Priority: minor |Milestone: 4.0 Component: Archetypes | Resolution: Keywords: | +--- Description changed by erikrose: Old description: '''Proposed by:''' Erik Rose[[BR]] '''Seconded by:''' (Step right up!) == The Problem == The Image type chooses the IDs of new objects differently than other types: rather than transforming the Title (My Dog Watches Me Eat becoming my-dog-watches-me-eat), they use the name of the uploaded file. This has several disadvantages: 1. Inconsistency with other types. 8.5 (yes, there was a half) out of 14 of our Plone user's group attendees today find the current behavior surprising or counterproductive. Only 1 actively prefers the current behavior. The rest don't see any problem in changing it. 1. Many common use cases involve images whose filenames are autogenerated and uninformative. All these cases result in URLs like `Picture%201.PNG`, which are uninformative, subjectively funny looking, and hard to remediate without first renaming and then re-uploading a large file: * Screenshots on a Mac come with titles like `Picture 1` and, because their lifetimes on disk are typically short, aren't often renamed. * Pictures from cameras look like `P1090404.JPG`. * Flickr images look like `3425573738_90e84302e8.jpg`. 1. When screenshots are routinely uploaded to the same folder (say, a site-wide `images` folder), everybody but the first uploader of `Picture 1.png` is met with an error—There is already an item named Picture 1.png in this folder.—and has to do a context switch back to another app to rename the file (which, if the user had good reason to name the local file Picture 1, is pretty intrusive). 1. The case of image extensions differs depending on platform. Windows tends to use capital `.JPG`; Mac, `.jpg`. Such inconsistency makes URLs hard to guess. 1. There's no other way in Plone, short of manually enabling short-name editing, to end up with capital letters in URLs. == The Proposal == * Have Images choose their IDs based on entered Titles, as with other types. * The Title field remains unrequired. Choosing an image file should stick its name in the Title field via JS if that field was empty, thus effectively providing the current behavior as an option as well as showing the user what's about to happen. * On creation form submission, the object's ID is assigned as follows: * If the Title field is the same as the name of the uploaded file, the ID is the contents of the Title field, without going through the typical Title-field-normalization filter. This maintains the current behavior as an option. * If the Title field is different than the name of the uploaded file, the ID is the normal munged Title field contents. * ~~If browsers are awful and require file extensions in URLs~~ (which they don't), ~~compute them from the uploaded MIME type using the existing `guess_content_type()` machinery or something. This solves the inconsistency where some files say `.jpg`, others `.jpeg`, and still others `.JPG`.~~ == Addendum: the File type == P.S. Though this PLIP shouldn't succeed or fail based on this, we might also consider making a similar change to the behavior of the File type. New description: '''Proposed by:''' Erik Rose[[BR]] '''Seconded by:''' (Step right up!) == The Problem == The Image type chooses the IDs of new objects differently than other types: rather than transforming the Title (My Dog Watches Me Eat becoming my-dog-watches-me-eat), they use the name of the uploaded file. This has several disadvantages: 1. Inconsistency with other types. 8.5 (yes, there was a half) out of 14 of our Plone user's group attendees today find the current behavior surprising or counterproductive. Only 1 actively prefers the current behavior. The rest don't see any problem in changing it. 1. Many common use cases involve images whose filenames are autogenerated and uninformative. All these cases result in URLs like `Picture%201.PNG`, which are uninformative, subjectively funny looking, and hard to remediate without first renaming and then re-uploading a large file: * Screenshots on a Mac come with titles like `Picture 1` and, because their lifetimes on disk are typically short, aren't often renamed. * Pictures from cameras look like `P1090404.JPG`. * Flickr images look like `3425573738_90e84302e8.jpg`. 1. When screenshots are routinely uploaded to the same folder (say, a site-wide `images` folder), everybody but the first uploader of `Picture 1.png` is met with an error—There is already an item named Picture 1.png in this folder.—and has to do a context switch back
[PLIP-Advisories] Re: [Plone] #9324: Use Amberjack to offer guided help for first-time users
#9324: Use Amberjack to offer guided help for first-time users ---+ Reporter: limi |Owner: Type: PLIP | Status: new Priority: n/a|Milestone: 4.0 Component: Documentation | Resolution: Keywords: | ---+ Comment(by raphael): FWT Vote: -0 I don't get why that should be in core -- Ticket URL: http://dev.plone.org/plone/ticket/9324#comment:18 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9329: Manage actions through-the-plone
#9329: Manage actions through-the-plone ---+ Reporter: igbun |Owner: igbun Type: PLIP | Status: new Priority: minor |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: actions, controlpanel | ---+ Comment(by igbun): OK, after reading carefully all arguments and chatting with some of the people who commented this PLIP, I believe we should postpone it, even if accepted for Plone 4. As Raphael states, we should be confident that the UI will also fit whatever the future brings for actions. We're pretty far from that right now. So, I'll happily re-submit this PLIP for Plone 4.1, if it still makes sense. Then we should have more information to base our decisions on, including: a more enlightened perspective of the future of actions; an add-on product providing this feature; we'll all be older and wiser :) -- Ticket URL: http://dev.plone.org/plone/ticket/9329#comment:18 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[Framework-Team] Having Hanno around
It occurred to me during today's call that a lot of our discussions hinged on what's happening in Plone 5: ensuring smooth transitions, not changing things that are about to change again, and so on. Might it be handy to have Hanno on our calls, since he's elbow-deep in Plone 5 every day? Erik ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[PLIP-Advisories] Re: [Plone] #9314: Plone Developer Pack option for installers
#9314: Plone Developer Pack option for installers +--- Reporter: smcmahon|Owner: smcmahon Type: PLIP| Status: new Priority: minor |Milestone: 4.0 Component: Installers | Resolution: Keywords: | +--- Comment(by witsch): not sure if it's too late, but i'd also nominate [http://pypi.python.org/pypi/mr.freeze/ mr.freeze] [http://pypi.python.org/pypi/Products.signalstack/ Products.signalstack/]. both are extremely useful! -- Ticket URL: http://dev.plone.org/plone/ticket/9314#comment:17 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[Framework-Team] Doodle for next meetings
I've put up a Doodle calendar so we can readjust our meeting time if need be: http://www.doodle.com/4qd32ckeimc69x48 . Either they just added timezone support, or I just figured it out, so we don't have to convert in our heads anymore. :-) Regards! Erik Rose ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[PLIP-Advisories] Re: [Plone] #9314: Plone Developer Pack option for installers
#9314: Plone Developer Pack option for installers +--- Reporter: smcmahon|Owner: smcmahon Type: PLIP| Status: new Priority: minor |Milestone: 4.0 Component: Installers | Resolution: Keywords: | +--- Comment(by smcmahon): Replying to [comment:17 witsch]: not sure if it's too late, but i'd also nominate [http://pypi.python.org/pypi/mr.freeze/ mr.freeze] [http://pypi.python.org/pypi/Products.signalstack/ Products.signalstack/]. both are extremely useful! As Hanno just pointed out: remember the dev pack is more of an integrators pack, so GloWorm and stuff is good. developers won't use the installer anyways and want to have it all custom with vimacs plugins... Or, in my words: if you know how to send a USR1 signal, you're not the target audience. -- Ticket URL: http://dev.plone.org/plone/ticket/9314#comment:18 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #7822: Make standard file content types use ZODB BLOB support
#7822: Make standard file content types use ZODB BLOB support +--- Reporter: limi|Owner: witsch Type: PLIP| Status: assigned Priority: major |Milestone: 4.0 Component: Infrastructure | Resolution: Keywords: focusarea | +--- Comment(by witsch): Replying to [comment:33 klm]: [...] just trying to factor in what might be pitfalls to address when the time comes to decide about adoption. i know you are, and like i said, much appreciate it... :) -- Ticket URL: http://dev.plone.org/plone/ticket/7822#comment:35 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9319: Merging archetypes.fieldtraverser into Product.Archetypes
#9319: Merging archetypes.fieldtraverser into Product.Archetypes
--+-
Reporter: thet |Owner:
Type: PLIP | Status: new
Priority: minor |Milestone: 4.0
Component: Archetypes| Resolution:
Keywords: Archetypes, traverse |
--+-
Comment(by witsch):
Replying to [comment:8 davisagli]:
This would be a win for accessing the value of schema-extender fields --
context/++atfield++myfield instead of
python:context.getField('myfield').getAccessor(context)() ...but we don't
ship with archetypes.schemaextender.
just as a note: `plone.app.blob` currently requires
`archetypes.schemaextender`, so unless it sees a major rewrite (and if the
[ticket:7822 blob plip] is accepted, of course), we might end up shipping
with it. please see [comment:ticket:7822:36 my comment] over in #7822 for
the motivation behind this...
--
Ticket URL: https://dev.plone.org/old/plone/ticket/9319#comment:13
Plone http://plone.org
Plone Content Management System
___
PLIP-Advisories mailing list
plip-advisor...@lists.plone.org
http://lists.plone.org/mailman/listinfo/plip-advisories
[PLIP-Advisories] Re: [Plone] #9322: Ensure that Plone 4 can upgrade Zope on Windows and Mac OS X via binary eggs
#9322: Ensure that Plone 4 can upgrade Zope on Windows and Mac OS X via binary eggs +--- Reporter: limi|Owner: smcmahon Type: PLIP| Status: new Priority: n/a |Milestone: 4.0 Component: Installers | Resolution: Keywords: | +--- Comment(by limi): I think it should definitely be tracked as a PLIP, the whole point is that this isn't possible to do right now, and is new functionality that needs to be tested and kept in shape as a critical part of the release, IMO. Sounds like a PLIP to me. :) -- Ticket URL: http://dev.plone.org/plone/ticket/9322#comment:11 Plone http://plone.org Plone Content Management System ___ PLIP-Advisories mailing list plip-advisor...@lists.plone.org http://lists.plone.org/mailman/listinfo/plip-advisories
