: 4581 | 108544 | 12346

New database property "Inherit design and ignore exceptions" 
New idea submissions, commenting and voting are no longer available on this site. Logins have also been disabled.
Use this IdeaSpace to post ideas about Domino Server.

: -23
: 2
: 25
: Domino Server / Data Storage and Management
: template, templates, design inheritence, design refresh
: Hynek Kobelka8110 25 Nov 2009
: / Email

If a database refreshes/replaces its design from its master template then in each separate design element the property "Prohibit design refresh or replace to modify" or "Inherit from the design template:" can prevent that this element is inherited.
While this functionality is intended and usefull in many situations, most of the time you want to have EXACT copies of of the design from your template. The current setting makes it difficult to guarantee that this is the case for many databases. You would need to manually check all design elements if none of it has a property set which prevents a refresh.
Therefore it would be nice to have an additional database property "Ignore design refresh exceptions".If this property would be checked, then the designer-task (or a manual design refresh/replace) would completely replace all the design elements from the template to the db and removing or overwriting any existing design-element even it if had the property "Prohibit ..." or  "Inherit from ..." set.
This would give a developer or admin more confidence that after he has done a design refresh/replace on an old database, that really ALL his changes are now in place.

1) Peter Presnell26654 (25 Nov 2009)
Sorry, I don't like this idea at all. It seems to go against the exact reason you would mark a design element so that it is not refreshed. I would suggest if you have database where you want all the design elements to be refreshed you remove the prohibit design from all the design elements. There are utilities that do this (e.g. Teamstudio) and it is also possible to write an agent to do this yourself. That way it is clear what is supposed to happen. Imagine someone adding their own view or folder to the database and then having it removed because it was not in the base template.
2) Aecio Neto15 (25 Nov 2009)
Same result can be achieved by not checking the 'inherit design from...' checkbox.
3) Hynek Kobelka8110 (25 Nov 2009)
Maybe some more information:

"...if you have database where you want all the design elements to be refreshed you remove the prohibit design from all the design elements..."
Thats the point. But how do you know if there is such a design element ?
Looking through the whole design? But what if you have a hundred identical dbs?
Write an agent which does it for you ? A developer can do it but for most admins this is way too much (and these are the ones who need it) Buying an external tool would be an option. But i really think that such a function should be provided by the software itselve.Moreover an agent or tool does not really solve the problem, because i would have to use them over and over again to look if not somebody changed/added some design elements. Whereas with the db-property the daily designer-task would take care of it for me.

Private folder/views (which are used very rarely) are not much of a concern here, because this is excactly what i want to get rid of. If the application allows their usage (like the mail-template does) then i would not use this db-property.

I did not understand your comment. But i guess you also mean that it is enough to go through all design elements and check if none is "Prohibited .." or connected to a different template. In this case see my explanation above.

To make it short i would enable this property only if i want the design to be absolutely IDENTICAL to the template.Guarnteed. Without any exceptions. And something i can relay on and check within a second.

From my experience design elements which are "prohibited to refresh" or "connected to a different template" cause problems in real world scenarios.
I have had tons of support calls from different customers which were caused by them. I think that it would be worth to give us more control over them on a database-property level.
4) Yellow Dog535 (26 Nov 2009)
If Administrators want an option to make design decisions and override what I set as a developer. Well I'm OK with that as long as IBM then add another property for each design element that says "Prohibit Design Refresh/Replace even when Ignore Design Refresh Exceptions set".
5) Rob Goudvis6585 (26 Nov 2009)
I do not think that it is the job of an administrator to correct any mistakes made by a developer. I would not promote an administrator to use an external tool to remove these marks.
6) Dirk Stelloh2259 (26 Nov 2009)
Simply cleaning the "prohibit design refresh"-flag should be the better choice. This is a onetime action and resets db design to orginating template.


Welcome to IdeaJam™

You can run IdeaJam™ in your company. It's easy to install, setup and customize. Your employees, partners and customers will immediately see results.

Use IdeaJam to:

  • Collect ideas from employees
  • Solicit feedback and suggestions from employees and customers
  • Run innovation contests and competitions
  • Validate concepts
  • Use the power of "crowd-sourcing" to rank ideas and allow the best ideas to rise to the top

IdeaJam™ works with:

  • IBM Connections
  • IBM Lotus Quickr
  • Blogs and Wikis
  • Websphere Portal
  • Microsoft Sharepoint
  • and other applications.

IdeaJam has an extensive set of widgets and API's that allow you to extend and integrate IdeaJam™ with other applications.

Learn more about IdeaJam >>

Use more customization features in ND9 NotesMail
reminder setting for NON-SameTime Event
Traveler refresh by pull down
System wide Web Query Save
How to Connect Windows Active Directive Group?

IdeaJam developed by

Elguji Software Logo