Ticket #1542 (reopened enhancement)

Opened 14 years ago

Last modified 13 years ago

Not enough merging in GenericSetup import of layou

Reported by: gracinet Owned by: fguillaume
Priority: P1 Milestone: CPS 3.5.7
Component: CPSSchemas Version: TRUNK
Severity: normal Keywords:
Cc:

Description

Currently, one can add widgets instances or change widgets properties with an extension profile. But one cannot change the <table> element (layout tab in ZMI). One has to rewrite it entirely. Therefore an extension profile that'd want to add a widget to an existing layout, such as CPSMailAccess for members layouts, cannot coexist well with another one that changes *other widgets'* names, like CPSUserFolderLDAPSetup. Fortunately, one simply gets a warning upond rendering if <table> refers to a non existing widget.

A true merge for the <table> would be quite complicated. Just deciding that one may add a row to an existing layout would be enough imho.

Change History

comment:1 Changed 14 years ago by fguillaume

Yes, a simple

<table purge="False">
  <row> ...</row>
</table>

to add a row in an extension profile would be enough.

comment:2 Changed 14 years ago by gracinet

I now you want backwards compatibility, since CPS 3.4 is a stable version.

The problem is that we are already in non purge mode, and this is interpreted: the code that's supposed to purge doesn't. _initTable is the one that clears the existing table (simply because it's not incremental). If I change this, I break backwards compatibility, unless I have a way to specify that default purge mode for extension profiles is True for layouts.

comment:3 Changed 14 years ago by gracinet

  • Status changed from new to closed
  • Resolution set to fixed

Forgot that purge="False" has nothing to do with environ.shouldPurge(). Done in [34744]

comment:4 Changed 14 years ago by gracinet

  • Status changed from closed to reopened
  • Resolution fixed deleted

One last issue: no <table> tag at all should not mean to erase the table. This breaks backwards compatibility, but there should be really few people relying on this (read: 0).

comment:5 Changed 14 years ago by gracinet

  • Status changed from reopened to closed
  • Resolution set to fixed

Done in [34989]

comment:6 Changed 13 years ago by gracinet

  • Status changed from closed to reopened
  • Resolution fixed deleted
  • Summary changed from Not enough merging in GenericSetup import of layout to Not enough merging in GenericSetup import of layou
  • Type changed from defect to enhancement
  • Milestone changed from CPS 3.4.1 to CPS 3.4.2

After a bit of using it: playing the following twice adds of course two identical row:

   <table purge="False">
        <row>(...)</row>
   </table>

This is a hassle for upgrade runs of profiles. Also, it would be a good thing to insert rows. Since row ids would be overkill, I implement the two following attributes:

  <row insert-at="3">
  <row remove="5">

Moreover, the importer will check if there is an identical row as the one being inserted and pass if true.

Note: See TracTickets for help on using tickets.