Priority be given to changing blueprint and bundle names and deleting them please [#267634]

First I want to say that this module is a fantastic idea and very useful module for certain purposes and look forward to its development into a stable release. I really appreciate your insight and your work.

My issue is that even for alpha testing it becomes awkward to have to restore the database when wanting to change or delete the blueprints and bundles. At a certain point database restores are not really feasible even on a test site unless there is a careful selective restore of specific tables (I am not sure I could come up with that list of tables). I think this needs to be a priority to speed up testing by having it more flexible in this manner.

As far as my needs go, there doesn't need to be a permanent link to the group type instances. The big advantage of this module is creating a pre-packaged starting point for group administrators so they don' t have to re-invent the wheel. Once their group panels are instantiated, they can be logically and physically disconnected from the blueprint and can evolve however the group admin sees fit. I'm not into the code at this point but it seems pretty simple to implement this request if this approach is taken. I realize this might not support the unimplemented Push feature, which I think has limited value anyway, since you wouldn't know which instances had been blueprinted and which ones hadn't.

In summary whatever the architecture is, we really need the change/delete functionality.

Thanks

Comments

Comment #1

sdboyer CreditAttribution: sdboyer commented 7 June 2008 at 02:40

Thanks! It's great to hear people who share my excitement about this direction, even when they experience blueprints in its fairly cranky infancy :)

Your comment makes me wonder if it might have been a mistake to include that inline helptext about database restoration. I wasn't pitching it as a method that ought to be used; rather, I was intending it as a warning to people that they needed to be careful when using blueprints, and offering them an option for 'oh-crap' circumstances.

I'll agree with you as far as the fact that there does need to be more flexibility when it comes to being able to edit/delete blueprints once they've been created. The big reason that there isn't that capacity is because editing is broken - something's borked on the edit form for existing blueprints, making it impossible to change certain values (like, say, path) once they've been created. That's just a bug. Deleting the bundles is simply a question of deleting the corresponding group node type, or simply unmarking it as a group; there's a rudimentary system in place at the moment to handle orphaned bundle/blueprint data in the aftermath of such a change. It needs to be improved, but it will offer pretty considerable flexibility. As for more editing options corresponding to a bundle, though, I'm not quite sure what to say - all the options that exist are editable, as far as I know. What did you have in mind?

Where I definitely part ways is on the utility of pushing content. There's a strong argument to be made for this having this feature purely as a mechanism for allowing us all to be human - i.e., if we screw up a release, or realize later on that there really IS something worth adding to the default 'package' groups are being equipped with. I can't in good conscience put a module out there if I know that it could cause seriously intransigent data asymmetries in the normal course of its operation, with no real hope of resolving them. But beyond that, there are numerous use cases for which the capability of pushing new content out to existing groups is not only useful, but crucial to the paradigm of the site itself. I'm working on just such a case.

Of course, it isn't really isn't either/or. If you could give me some more details on the sort of edit/delete/'more flexibility' you'd like to see in the bundle/blueprint system, then I can respond more directly. At this point, though, my general reaction is that fixing the existing bug I mentioned isn't a very big challenge, but that casting aside some of the stricter aspects of what basically amounts to version control would be a serious mistake. Ideally, the version control should basically work transparently in the background and not really get in the way of what you're doing, even for less complex implementations of blueprints.