2011-01-14 11:16:25 -06:00
|
|
|
/*jsl:import ipa.js */
|
|
|
|
|
2010-08-06 09:01:44 -05:00
|
|
|
/* Authors:
|
|
|
|
* Pavel Zuna <pzuna@redhat.com>
|
2010-09-29 15:57:07 -05:00
|
|
|
* Adam Young <ayoung@redhat.com>
|
Certificate management for services.
This is an initial implementation of certificate management for
services. It addresses the mechanism required to view and update
certificates. The complete UI implementation will be addressed in
subsequent patches.
On the server side, the service.py has been modified to define
usercertificate in the service object's takes_params. This is
needed to generate the proper JSON metadata which is needed by
the UI. It also has been modified to accept null certificate for
deletion.
On the client side, the service details page has been modified to
display the base64-encoded certificate in a text area. When the
page is saved, the action handler will store the base64-encoded
certificate in the proper JSON structure. Also the service name
and service hostname are now displayed in separate fields.
The details configuration has been modified to support displaying
and updating certificates. The structure is changed to use maps
to define sections and fields. A section contains name, label,
and an array of fields. A field contains name, label, setup
function, load function, and save function. This is used to
implement custom interface and behavior for certificates.
All other entities, test cases, and test data have been updated
accordingly. Some functions and variables have been renamed to
improve clarity and consistency.
2010-10-07 14:02:44 -05:00
|
|
|
* Endi S. Dewata <edewata@redhat.com>
|
2010-08-06 09:01:44 -05:00
|
|
|
*
|
|
|
|
* Copyright (C) 2010 Red Hat
|
|
|
|
* see file 'COPYING' for use and warranty information
|
|
|
|
*
|
2010-12-09 06:59:11 -06:00
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation, either version 3 of the License, or
|
|
|
|
* (at your option) any later version.
|
2010-08-06 09:01:44 -05:00
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
2010-12-09 06:59:11 -06:00
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
2010-08-23 21:32:23 -05:00
|
|
|
*/
|
2010-08-06 09:01:44 -05:00
|
|
|
|
|
|
|
/* IPA Object Details - populating definiton lists from entry data */
|
|
|
|
|
|
|
|
/* REQUIRES: ipa.js */
|
|
|
|
|
2010-12-09 15:32:22 -06:00
|
|
|
IPA.expand_icon = 'ui-icon-minus';
|
|
|
|
IPA.collapse_icon = 'ui-icon-plus';
|
|
|
|
|
2010-11-05 12:11:56 -05:00
|
|
|
IPA.is_field_writable = function(rights){
|
|
|
|
if (!rights){
|
|
|
|
alert('no right');
|
|
|
|
}
|
|
|
|
return rights.indexOf('w') > -1;
|
2010-11-09 14:22:31 -06:00
|
|
|
};
|
2010-11-05 12:11:56 -05:00
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
IPA.details_field = function (spec) {
|
2010-10-13 12:07:43 -05:00
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
spec = spec || {};
|
2010-10-13 12:07:43 -05:00
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
var that = IPA.widget(spec);
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
|
2010-11-09 14:22:31 -06:00
|
|
|
that.load = spec.load || load;
|
|
|
|
that.save = spec.save || save;
|
2010-10-27 22:32:30 -05:00
|
|
|
|
2010-12-09 14:20:40 -06:00
|
|
|
function load(record) {
|
|
|
|
that.record = record;
|
|
|
|
that.values = record[that.name];
|
2010-11-18 20:17:14 -06:00
|
|
|
that.reset();
|
|
|
|
}
|
|
|
|
|
2010-12-09 14:20:40 -06:00
|
|
|
that.update = function() {
|
2010-11-18 20:17:14 -06:00
|
|
|
|
|
|
|
if (!that.record) return;
|
2010-11-09 14:22:31 -06:00
|
|
|
|
2010-11-16 18:10:40 -06:00
|
|
|
/* remove all <dd> tags i.e. all attribute values */
|
|
|
|
$('dd', that.container).remove();
|
2010-10-27 22:32:30 -05:00
|
|
|
|
|
|
|
var multivalue = false;
|
|
|
|
var hint_span = null;
|
|
|
|
var dd;
|
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
var param_info = IPA.get_param_info(that.entity_name, that.name);
|
2010-10-27 22:32:30 -05:00
|
|
|
if (param_info) {
|
|
|
|
if (param_info['multivalue'] || param_info['class'] == 'List')
|
|
|
|
multivalue = true;
|
2010-12-02 15:17:22 -06:00
|
|
|
var hint = param_info['doc'];
|
2010-10-27 22:32:30 -05:00
|
|
|
if (hint){
|
|
|
|
hint_span = $('<span />',{
|
|
|
|
'class': 'attrhint',
|
|
|
|
'html': 'Hint: ' + hint});
|
|
|
|
}
|
2010-10-13 12:07:43 -05:00
|
|
|
}
|
|
|
|
|
2010-11-05 12:11:56 -05:00
|
|
|
var rights = 'rsc';
|
2010-11-16 18:10:40 -06:00
|
|
|
|
2010-11-18 20:17:14 -06:00
|
|
|
if (that.record.attributelevelrights){
|
|
|
|
rights = that.record.attributelevelrights[this.name] || rights ;
|
2010-11-05 12:11:56 -05:00
|
|
|
}
|
2010-11-16 18:10:40 -06:00
|
|
|
|
|
|
|
if (that.values) {
|
2010-10-25 18:55:57 -05:00
|
|
|
/*
|
|
|
|
Too much logic currently assumes an array.
|
|
|
|
This is true everywhere but ACIs. */
|
|
|
|
|
|
|
|
if (!(that.values instanceof Array)){
|
|
|
|
that.values = [that.values];
|
|
|
|
}
|
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
dd = IPA.create_first_dd(that.name);
|
2011-01-12 21:00:38 -06:00
|
|
|
dd.append(that.create_value(that.values[0], hint_span, rights, 0));
|
2010-11-16 18:10:40 -06:00
|
|
|
dd.appendTo(that.container);
|
|
|
|
|
|
|
|
for (var i = 1; i < that.values.length; ++i) {
|
2011-01-12 18:51:22 -06:00
|
|
|
dd = IPA.create_other_dd(that.name);
|
2011-01-12 21:00:38 -06:00
|
|
|
dd.append(that.create_value(that.values[i], hint_span, rights, i));
|
2010-11-16 18:10:40 -06:00
|
|
|
dd.appendTo(that.container);
|
2010-10-13 12:07:43 -05:00
|
|
|
}
|
2010-11-16 18:10:40 -06:00
|
|
|
|
2010-11-05 12:11:56 -05:00
|
|
|
if (multivalue && IPA.is_field_writable(rights) ) {
|
2011-01-12 18:51:22 -06:00
|
|
|
dd = IPA.create_other_dd(that.name);
|
|
|
|
dd.append(IPA.details_field_create_add_link.call(that, that.name, rights, that.values.length));
|
2010-11-16 18:10:40 -06:00
|
|
|
dd.appendTo(that.container);
|
2010-10-27 22:32:30 -05:00
|
|
|
}
|
2010-11-16 18:10:40 -06:00
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
} else {
|
2010-12-09 15:32:22 -06:00
|
|
|
if (multivalue && IPA.is_field_writable(rights)) {
|
2011-01-12 18:51:22 -06:00
|
|
|
dd = IPA.create_first_dd(that.name);
|
|
|
|
dd.append(IPA.details_field_create_add_link.call(that, that.name, rights, 0));
|
2010-11-16 18:10:40 -06:00
|
|
|
dd.appendTo(that.container);
|
|
|
|
|
2010-10-13 12:07:43 -05:00
|
|
|
} else {
|
2011-01-12 18:51:22 -06:00
|
|
|
dd = IPA.create_first_dd(that.name);
|
2011-01-12 21:00:38 -06:00
|
|
|
dd.append(that.create_value('', hint_span, rights, 0));
|
2010-11-16 18:10:40 -06:00
|
|
|
dd.appendTo(that.container);
|
2010-10-13 12:07:43 -05:00
|
|
|
}
|
|
|
|
}
|
2010-11-18 20:17:14 -06:00
|
|
|
};
|
2010-10-13 12:07:43 -05:00
|
|
|
|
2011-01-12 21:00:38 -06:00
|
|
|
/* create an HTML element for displaying/editing an attribute
|
|
|
|
* arguments:
|
|
|
|
* attr - LDAP attribute name
|
|
|
|
* value - the attributes value */
|
|
|
|
that.create_value = function(value, hint, rights, index) {
|
|
|
|
|
|
|
|
// if field is primary key or non-writable, return a label
|
|
|
|
|
|
|
|
var label = $('<label/>', { html:value.toString() });
|
|
|
|
|
|
|
|
if (!IPA.is_field_writable(rights)) return label;
|
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
var param_info = IPA.get_param_info(that.entity_name, that.name);
|
2011-01-12 21:00:38 -06:00
|
|
|
if (param_info) {
|
|
|
|
if (param_info['primary_key']) return label;
|
|
|
|
if ('no_update' in param_info['flags']) return label;
|
|
|
|
}
|
|
|
|
|
|
|
|
// otherwise, create input field
|
|
|
|
|
|
|
|
var input = that.create_input(value, param_info, rights, index);
|
|
|
|
if (param_info) {
|
|
|
|
if (param_info['multivalue'] || param_info['class'] == 'List') {
|
|
|
|
input.append(_ipa_create_remove_link(that.name, param_info));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (hint) input.after(hint);
|
|
|
|
|
|
|
|
return input;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* creates a input box for editing a string attribute */
|
|
|
|
that.create_input = function(value, param_info, rights, index) {
|
|
|
|
|
|
|
|
index = index || 0;
|
|
|
|
|
|
|
|
function validate_input(text, param_info, error_link) {
|
|
|
|
if (param_info && param_info.pattern) {
|
|
|
|
var regex = new RegExp( param_info.pattern );
|
|
|
|
if (!text.match(regex)) {
|
|
|
|
error_link.style.display = "block";
|
|
|
|
if (param_info.pattern_errmsg) {
|
|
|
|
error_link.innerHTML = param_info.pattern_errmsg;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
error_link.style.display = "none";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
var doc = that.name;
|
|
|
|
if (param_info && param_info.doc) {
|
|
|
|
doc = param_info.doc;
|
|
|
|
}
|
|
|
|
var span = $("<Span />");
|
|
|
|
var input = $("<input/>", {
|
|
|
|
type: "text",
|
|
|
|
name: that.name,
|
|
|
|
value: value.toString(),
|
|
|
|
title: doc,
|
|
|
|
keyup: function(){
|
|
|
|
var undo_link = this.nextElementSibling;
|
|
|
|
undo_link.style.display = "inline";
|
|
|
|
var error_link = undo_link.nextElementSibling;
|
|
|
|
|
|
|
|
var text = $(this).val();
|
|
|
|
validate_input(text, param_info,error_link);
|
|
|
|
}
|
|
|
|
}).appendTo(span) ;
|
|
|
|
|
|
|
|
if (!IPA.is_field_writable(rights)) {
|
|
|
|
input.attr('disabled', 'disabled');
|
|
|
|
}
|
|
|
|
|
|
|
|
span.append($("<a/>", {
|
|
|
|
html:"undo",
|
|
|
|
"class":"ui-state-highlight ui-corner-all undo",
|
|
|
|
style:"display:none",
|
|
|
|
click: function(){
|
|
|
|
var previous_value = that.values || '';
|
|
|
|
if (index >= previous_value.length){
|
|
|
|
previous_value = '';
|
|
|
|
}else{
|
|
|
|
previous_value= previous_value[index];
|
|
|
|
}
|
|
|
|
|
|
|
|
this.previousElementSibling.value = previous_value;
|
|
|
|
this.style.display = "none";
|
|
|
|
var error_link = this.nextElementSibling;
|
|
|
|
validate_input(previous_value, param_info,error_link);
|
|
|
|
}
|
|
|
|
}));
|
|
|
|
span.append($("<span/>", {
|
|
|
|
html:"Does not match pattern",
|
|
|
|
"class":"ui-state-error ui-corner-all",
|
|
|
|
style:"display:none"
|
|
|
|
}));
|
|
|
|
return span;
|
|
|
|
};
|
|
|
|
|
2010-11-18 20:17:14 -06:00
|
|
|
function save() {
|
2010-10-27 22:32:30 -05:00
|
|
|
var values = [];
|
2010-10-13 12:07:43 -05:00
|
|
|
|
2010-11-16 18:10:40 -06:00
|
|
|
$('dd', that.container).each(function () {
|
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
var input = $('input', $(this));
|
|
|
|
if (!input.length) return;
|
2010-10-13 12:07:43 -05:00
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
if (input.is('.strikethrough')) return;
|
2010-10-13 12:07:43 -05:00
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
var value = $.trim(input.val());
|
|
|
|
if (!value) value = '';
|
2010-10-27 12:41:48 -05:00
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
values.push(value);
|
|
|
|
});
|
2010-10-13 12:07:43 -05:00
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
return values;
|
|
|
|
}
|
2010-10-13 12:07:43 -05:00
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
return that;
|
2011-01-14 11:16:25 -06:00
|
|
|
};
|
|
|
|
|
2010-10-13 12:07:43 -05:00
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
IPA.details_section = function (spec){
|
2010-10-13 12:07:43 -05:00
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
spec = spec || {};
|
2010-10-13 12:07:43 -05:00
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
var that = {};
|
2010-11-15 11:10:55 -06:00
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
that.name = spec.name || '';
|
|
|
|
that.label = spec.label || '';
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
that.template = spec.template;
|
|
|
|
that._entity_name = spec.entity_name;
|
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
that.fields = [];
|
|
|
|
that.fields_by_name = {};
|
|
|
|
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
that.__defineGetter__("entity_name", function(){
|
|
|
|
return that._entity_name;
|
|
|
|
});
|
|
|
|
|
|
|
|
that.__defineSetter__("entity_name", function(entity_name){
|
|
|
|
that._entity_name = entity_name;
|
|
|
|
|
|
|
|
for (var i=0; i<that.fields.length; i++) {
|
|
|
|
that.fields[i].entity_name = entity_name;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
that.get_field = function(name) {
|
|
|
|
return that.fields_by_name[name];
|
2010-10-13 12:07:43 -05:00
|
|
|
};
|
2010-10-27 22:32:30 -05:00
|
|
|
|
|
|
|
that.add_field = function(field) {
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
field.entity_name = that.entity_name;
|
2010-10-27 22:32:30 -05:00
|
|
|
that.fields.push(field);
|
|
|
|
that.fields_by_name[field.name] = field;
|
2010-10-25 18:55:57 -05:00
|
|
|
return field;
|
2010-10-27 22:32:30 -05:00
|
|
|
};
|
|
|
|
|
|
|
|
that.create_field = function(spec) {
|
2011-01-12 21:00:38 -06:00
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
//TODO: replace IPA.details_field with class-specific implementation
|
2011-01-12 21:00:38 -06:00
|
|
|
//Valid field classes: Str, IA5Str, Int, Bool and List
|
2011-01-12 18:51:22 -06:00
|
|
|
var field = IPA.details_field(spec);
|
2010-10-27 22:32:30 -05:00
|
|
|
that.add_field(field);
|
|
|
|
return field;
|
|
|
|
};
|
|
|
|
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
that.create_text = function(spec) {
|
2011-01-12 18:51:22 -06:00
|
|
|
var field = IPA.text_widget(spec);
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
that.add_field(field);
|
|
|
|
return field;
|
|
|
|
};
|
|
|
|
|
|
|
|
that.create_radio = function(spec) {
|
2011-01-12 18:51:22 -06:00
|
|
|
var field = IPA.radio_widget(spec);
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
that.add_field(field);
|
|
|
|
return field;
|
|
|
|
};
|
|
|
|
|
|
|
|
that.create_textarea = function(spec) {
|
2011-01-12 18:51:22 -06:00
|
|
|
var field = IPA.textarea_widget(spec);
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
that.add_field(field);
|
|
|
|
return field;
|
|
|
|
};
|
|
|
|
|
|
|
|
that.create_button = function(spec) {
|
2011-01-12 18:51:22 -06:00
|
|
|
var field = IPA.button_widget(spec);
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
that.add_field(field);
|
|
|
|
return field;
|
|
|
|
};
|
|
|
|
|
2010-11-09 14:22:31 -06:00
|
|
|
that.init = function() {
|
|
|
|
for (var i=0; i<that.fields.length; i++) {
|
|
|
|
var field = that.fields[i];
|
|
|
|
field.init();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2010-11-15 11:10:55 -06:00
|
|
|
that.create = function(container) {
|
|
|
|
|
|
|
|
if (that.template) return;
|
|
|
|
|
|
|
|
var fields = that.fields;
|
|
|
|
for (var i = 0; i < fields.length; ++i) {
|
|
|
|
var field = fields[i];
|
|
|
|
|
|
|
|
var span = $('<span/>', { 'name': field.name }).appendTo(container);
|
|
|
|
field.create(span);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
that.setup = function(container) {
|
|
|
|
|
2010-11-18 20:17:14 -06:00
|
|
|
that.container = container;
|
2010-11-15 11:10:55 -06:00
|
|
|
|
|
|
|
if (that.template) return;
|
|
|
|
|
|
|
|
var fields = that.fields;
|
|
|
|
for (var i = 0; i < fields.length; ++i) {
|
|
|
|
var field = fields[i];
|
|
|
|
|
|
|
|
var span = $('span[name='+field.name+']', this.container).first();
|
|
|
|
field.setup(span);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
SUDO adjustments
The SUDO rule details facet has been updated to support the latest UI
spec. The facet consists of 5 sections: general, users, hosts, commands,
and run-as.
The general section contains the SUDO rule description and status. If
the status is changed, the sudorule-enable/disable will be invoked.
The other sections contain radio buttons for the association category
and tables for the members. When a member is added or removed, the
category will be adjusted appropriately. If the category is changed to
'all', 'allow', or 'deny', all members will be removed.
The last section is currently not working because backend support is
not yet available.
The adder dialog boxes for users, groups, and hosts has been modified
to accept external identities. The layout for the base adder dialog
was updated. The base dialog class was updated to support templates.
The SUDO dialog boxes were implemented using templates. New CSS
classes were added to ipa.css.
The HBAC rule details facet has been updated as well.
2010-12-07 01:51:51 -06:00
|
|
|
that.load = function(record) {
|
2010-11-15 11:10:55 -06:00
|
|
|
|
|
|
|
var fields = that.fields;
|
|
|
|
|
|
|
|
if (that.template) {
|
|
|
|
var template = IPA.get_template(that.template);
|
|
|
|
this.container.load(
|
|
|
|
template,
|
|
|
|
function(data, text_status, xhr) {
|
|
|
|
for (var i = 0; i < fields.length; ++i) {
|
|
|
|
var field = fields[i];
|
|
|
|
var span = $('span[name='+field.name+']', this.container).first();
|
|
|
|
field.setup(span);
|
SUDO adjustments
The SUDO rule details facet has been updated to support the latest UI
spec. The facet consists of 5 sections: general, users, hosts, commands,
and run-as.
The general section contains the SUDO rule description and status. If
the status is changed, the sudorule-enable/disable will be invoked.
The other sections contain radio buttons for the association category
and tables for the members. When a member is added or removed, the
category will be adjusted appropriately. If the category is changed to
'all', 'allow', or 'deny', all members will be removed.
The last section is currently not working because backend support is
not yet available.
The adder dialog boxes for users, groups, and hosts has been modified
to accept external identities. The layout for the base adder dialog
was updated. The base dialog class was updated to support templates.
The SUDO dialog boxes were implemented using templates. New CSS
classes were added to ipa.css.
The HBAC rule details facet has been updated as well.
2010-12-07 01:51:51 -06:00
|
|
|
field.load(record);
|
2010-11-15 11:10:55 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (var j=0; j<fields.length; j++) {
|
|
|
|
var field = fields[j];
|
|
|
|
var span = $('span[name='+field.name+']', this.container).first();
|
SUDO adjustments
The SUDO rule details facet has been updated to support the latest UI
spec. The facet consists of 5 sections: general, users, hosts, commands,
and run-as.
The general section contains the SUDO rule description and status. If
the status is changed, the sudorule-enable/disable will be invoked.
The other sections contain radio buttons for the association category
and tables for the members. When a member is added or removed, the
category will be adjusted appropriately. If the category is changed to
'all', 'allow', or 'deny', all members will be removed.
The last section is currently not working because backend support is
not yet available.
The adder dialog boxes for users, groups, and hosts has been modified
to accept external identities. The layout for the base adder dialog
was updated. The base dialog class was updated to support templates.
The SUDO dialog boxes were implemented using templates. New CSS
classes were added to ipa.css.
The HBAC rule details facet has been updated as well.
2010-12-07 01:51:51 -06:00
|
|
|
field.load(record);
|
2010-11-15 11:10:55 -06:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
that.reset = function() {
|
|
|
|
for (var i=0; i<that.fields.length; i++) {
|
|
|
|
var field = that.fields[i];
|
|
|
|
var span = $('span[name='+field.name+']', this.container).first();
|
2010-11-18 20:17:14 -06:00
|
|
|
field.reset();
|
2010-11-15 11:10:55 -06:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
// methods that should be invoked by subclasses
|
2010-12-02 22:12:59 -06:00
|
|
|
that.section_init = that.init;
|
2010-11-15 11:10:55 -06:00
|
|
|
that.section_create = that.create;
|
|
|
|
that.section_setup = that.setup;
|
|
|
|
that.section_load = that.load;
|
|
|
|
|
|
|
|
return that;
|
2011-01-14 11:16:25 -06:00
|
|
|
};
|
|
|
|
|
2010-11-15 11:10:55 -06:00
|
|
|
|
2010-11-16 18:10:40 -06:00
|
|
|
/**
|
|
|
|
* This class creates a details section formatted as a list of
|
|
|
|
* attributes names and values. The list is defined using <dl> tag.
|
|
|
|
* The attribute name is defined inside a <dt> tag. The attribute
|
|
|
|
* value is defined using a <dd> tag inside a <span> tag. If the
|
|
|
|
* attribute has multiple values the content inside <span> will
|
|
|
|
* be duplicated to display each value.
|
|
|
|
*
|
|
|
|
* Example:
|
|
|
|
* <dl class="entryattrs">
|
|
|
|
*
|
|
|
|
* <dt title="givenname">First Name:</dt>
|
|
|
|
* <span name="givenname">
|
|
|
|
* <dd><input type="text" size="20"/></dd>
|
|
|
|
* </span>
|
|
|
|
*
|
|
|
|
* <dt title="telephonenumber">Telephone Number:</dt>
|
|
|
|
* <span name="telephonenumber">
|
|
|
|
* <dd><input type="text" size="20"/></dd>
|
|
|
|
* <dd><input type="text" size="20"/></dd>
|
|
|
|
* </span>
|
|
|
|
*
|
|
|
|
* </dl>
|
|
|
|
*/
|
2011-01-12 18:51:22 -06:00
|
|
|
IPA.details_list_section = function (spec){
|
2010-11-15 11:10:55 -06:00
|
|
|
|
|
|
|
spec = spec || {};
|
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
var that = IPA.details_section(spec);
|
2010-11-15 11:10:55 -06:00
|
|
|
|
|
|
|
that.create = function(container) {
|
|
|
|
|
|
|
|
// do not call section_create() here
|
|
|
|
|
|
|
|
if (that.template) return;
|
|
|
|
|
|
|
|
var dl = $('<dl/>', {
|
|
|
|
'id': that.name,
|
|
|
|
'class': 'entryattrs'
|
|
|
|
}).appendTo(container);
|
|
|
|
|
|
|
|
var fields = that.fields;
|
|
|
|
for (var i = 0; i < fields.length; ++i) {
|
|
|
|
var field = fields[i];
|
|
|
|
|
2010-11-16 18:10:40 -06:00
|
|
|
var label = field.label;
|
2011-01-12 21:00:38 -06:00
|
|
|
|
|
|
|
// no need to get i18n label from metadata
|
|
|
|
// because it's already done by field.init()
|
|
|
|
|
|
|
|
if (label !== '') {
|
2010-12-21 14:14:08 -06:00
|
|
|
label += ':';
|
|
|
|
}
|
2010-11-16 18:10:40 -06:00
|
|
|
|
|
|
|
$('<dt/>', {
|
2010-12-21 14:14:08 -06:00
|
|
|
html: label
|
2010-11-16 18:10:40 -06:00
|
|
|
}).appendTo(dl);
|
|
|
|
|
2010-11-15 11:10:55 -06:00
|
|
|
var span = $('<span/>', { 'name': field.name }).appendTo(dl);
|
|
|
|
field.create(span);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2010-12-09 14:20:40 -06:00
|
|
|
return that;
|
2011-01-14 11:16:25 -06:00
|
|
|
};
|
|
|
|
|
2010-12-09 14:20:40 -06:00
|
|
|
|
2011-01-14 11:16:25 -06:00
|
|
|
/* shorthand notation used for declarative definitions of details pages */
|
2011-01-12 18:51:22 -06:00
|
|
|
IPA.stanza = function (spec) {
|
2010-12-09 14:20:40 -06:00
|
|
|
|
|
|
|
spec = spec || {};
|
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
var that = IPA.details_list_section(spec);
|
2010-12-09 14:20:40 -06:00
|
|
|
|
2010-12-03 23:29:05 -06:00
|
|
|
// This is to allow declarative style programming for details
|
2010-12-09 14:20:40 -06:00
|
|
|
that.input = function(spec) {
|
2010-10-27 22:32:30 -05:00
|
|
|
that.create_field(spec);
|
|
|
|
return that;
|
2010-12-09 14:20:40 -06:00
|
|
|
};
|
2010-10-27 22:32:30 -05:00
|
|
|
|
2010-12-09 14:20:40 -06:00
|
|
|
that.custom_input = function(input) {
|
|
|
|
that.add_field(input);
|
|
|
|
return that;
|
|
|
|
};
|
2010-10-27 22:32:30 -05:00
|
|
|
|
2010-10-13 12:07:43 -05:00
|
|
|
return that;
|
2011-01-14 11:16:25 -06:00
|
|
|
};
|
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
IPA.details_facet = function (spec) {
|
2010-10-13 12:07:43 -05:00
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
spec = spec || {};
|
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
var that = IPA.facet(spec);
|
2010-10-27 22:32:30 -05:00
|
|
|
|
2011-01-14 14:14:32 -06:00
|
|
|
that.label = ( IPA.messages && IPA.messages.facets && IPA.messages.facets.details) || spec.label;
|
SUDO adjustments
The SUDO rule details facet has been updated to support the latest UI
spec. The facet consists of 5 sections: general, users, hosts, commands,
and run-as.
The general section contains the SUDO rule description and status. If
the status is changed, the sudorule-enable/disable will be invoked.
The other sections contain radio buttons for the association category
and tables for the members. When a member is added or removed, the
category will be adjusted appropriately. If the category is changed to
'all', 'allow', or 'deny', all members will be removed.
The last section is currently not working because backend support is
not yet available.
The adder dialog boxes for users, groups, and hosts has been modified
to accept external identities. The layout for the base adder dialog
was updated. The base dialog class was updated to support templates.
The SUDO dialog boxes were implemented using templates. New CSS
classes were added to ipa.css.
The HBAC rule details facet has been updated as well.
2010-12-07 01:51:51 -06:00
|
|
|
that.is_dirty = spec.is_dirty || is_dirty;
|
2010-12-09 10:43:21 -06:00
|
|
|
that.create = spec.create || create;
|
|
|
|
that.setup = spec.setup || setup;
|
SUDO adjustments
The SUDO rule details facet has been updated to support the latest UI
spec. The facet consists of 5 sections: general, users, hosts, commands,
and run-as.
The general section contains the SUDO rule description and status. If
the status is changed, the sudorule-enable/disable will be invoked.
The other sections contain radio buttons for the association category
and tables for the members. When a member is added or removed, the
category will be adjusted appropriately. If the category is changed to
'all', 'allow', or 'deny', all members will be removed.
The last section is currently not working because backend support is
not yet available.
The adder dialog boxes for users, groups, and hosts has been modified
to accept external identities. The layout for the base adder dialog
was updated. The base dialog class was updated to support templates.
The SUDO dialog boxes were implemented using templates. New CSS
classes were added to ipa.css.
The HBAC rule details facet has been updated as well.
2010-12-07 01:51:51 -06:00
|
|
|
that.load = spec.load || load;
|
2011-01-12 18:51:22 -06:00
|
|
|
that.update = spec.update || IPA.details_update;
|
SUDO adjustments
The SUDO rule details facet has been updated to support the latest UI
spec. The facet consists of 5 sections: general, users, hosts, commands,
and run-as.
The general section contains the SUDO rule description and status. If
the status is changed, the sudorule-enable/disable will be invoked.
The other sections contain radio buttons for the association category
and tables for the members. When a member is added or removed, the
category will be adjusted appropriately. If the category is changed to
'all', 'allow', or 'deny', all members will be removed.
The last section is currently not working because backend support is
not yet available.
The adder dialog boxes for users, groups, and hosts has been modified
to accept external identities. The layout for the base adder dialog
was updated. The base dialog class was updated to support templates.
The SUDO dialog boxes were implemented using templates. New CSS
classes were added to ipa.css.
The HBAC rule details facet has been updated as well.
2010-12-07 01:51:51 -06:00
|
|
|
that.reset = spec.reset || reset;
|
2011-01-12 18:51:22 -06:00
|
|
|
that.refresh = spec.refresh || IPA.details_refresh;
|
2010-10-27 22:32:30 -05:00
|
|
|
|
|
|
|
that.sections = [];
|
|
|
|
that.sections_by_name = {};
|
|
|
|
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
that.__defineGetter__("entity_name", function(){
|
|
|
|
return that._entity_name;
|
|
|
|
});
|
|
|
|
|
|
|
|
that.__defineSetter__("entity_name", function(entity_name){
|
|
|
|
that._entity_name = entity_name;
|
|
|
|
|
|
|
|
for (var i=0; i<that.sections.length; i++) {
|
|
|
|
that.sections[i].entity_name = entity_name;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2010-10-27 22:32:30 -05:00
|
|
|
that.get_section = function(name) {
|
|
|
|
return that.sections_by_name[name];
|
|
|
|
};
|
|
|
|
|
|
|
|
that.add_section = function(section) {
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
section.entity_name = that.entity_name;
|
2010-10-27 22:32:30 -05:00
|
|
|
that.sections.push(section);
|
|
|
|
that.sections_by_name[section.name] = section;
|
2010-10-25 18:55:57 -05:00
|
|
|
return section;
|
2010-10-27 22:32:30 -05:00
|
|
|
};
|
|
|
|
|
|
|
|
that.create_section = function(spec) {
|
2011-01-12 18:51:22 -06:00
|
|
|
var section = IPA.details_section(spec);
|
2010-10-27 22:32:30 -05:00
|
|
|
that.add_section(section);
|
|
|
|
return section;
|
|
|
|
};
|
|
|
|
|
2010-11-09 14:22:31 -06:00
|
|
|
that.init = function() {
|
|
|
|
for (var i=0; i<that.sections.length; i++) {
|
|
|
|
var section = that.sections[i];
|
|
|
|
section.init();
|
|
|
|
}
|
|
|
|
};
|
2010-10-27 22:32:30 -05:00
|
|
|
|
2010-11-18 20:17:14 -06:00
|
|
|
that.get_primary_key = function() {
|
|
|
|
var pkey_name = IPA.metadata[that.entity_name].primary_key;
|
2010-10-25 18:55:57 -05:00
|
|
|
if (that.record[pkey_name] instanceof Array){
|
|
|
|
return that.record[pkey_name][0];
|
|
|
|
}else{
|
|
|
|
return that.record[pkey_name];
|
|
|
|
}
|
2010-11-18 20:17:14 -06:00
|
|
|
};
|
|
|
|
|
2010-12-09 10:43:21 -06:00
|
|
|
that.get_section_header_prefix = function(visible) {
|
|
|
|
if (visible) {
|
2010-12-09 15:32:22 -06:00
|
|
|
return '<span class="ui-icon '+
|
|
|
|
IPA.collapse_icon +
|
|
|
|
' section-expand" ></span>';
|
2010-12-09 10:43:21 -06:00
|
|
|
} else {
|
2010-12-09 15:32:22 -06:00
|
|
|
return '<span class="ui-icon '+
|
|
|
|
IPA.expand_icon +
|
|
|
|
' section-expand" />';
|
2010-12-09 10:43:21 -06:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
function create(container) {
|
|
|
|
|
|
|
|
container.attr('title', that.entity_name);
|
|
|
|
|
2011-01-10 20:14:51 -06:00
|
|
|
$('<h1/>',{
|
|
|
|
html: "<span id='headerpkey' />"+that.entity_name + ' Settings'
|
|
|
|
}).append(IPA.create_network_spinner()).
|
|
|
|
appendTo(container);
|
|
|
|
|
2010-12-09 10:43:21 -06:00
|
|
|
var details = $('<div/>', {
|
|
|
|
'class': 'content'
|
|
|
|
}).appendTo(container);
|
|
|
|
|
|
|
|
var action_panel = that.get_action_panel();
|
|
|
|
|
|
|
|
var ul = $('ul', action_panel);
|
|
|
|
var buttons = $('.action-controls',action_panel);
|
|
|
|
|
|
|
|
$('<input/>', {
|
|
|
|
'type': 'text',
|
|
|
|
'name': 'reset'
|
|
|
|
}).appendTo(buttons);
|
|
|
|
|
|
|
|
$('<input/>', {
|
|
|
|
'type': 'text',
|
|
|
|
'name': 'update'
|
|
|
|
}).appendTo(buttons);
|
|
|
|
|
|
|
|
|
|
|
|
for (var i = 0; i < that.sections.length; ++i) {
|
|
|
|
var section = that.sections[i];
|
|
|
|
|
|
|
|
$('<h2/>', {
|
2011-01-06 08:16:05 -06:00
|
|
|
name: section.name,
|
|
|
|
title: section.label,
|
|
|
|
html: that.get_section_header_prefix(true) + ' ' + section.label
|
2010-12-09 10:43:21 -06:00
|
|
|
}).appendTo(details);
|
|
|
|
|
|
|
|
var div = $('<div/>', {
|
|
|
|
'id': that.entity_name+'-'+that.name+'-'+section.name,
|
|
|
|
'class': 'details-section'
|
|
|
|
}).appendTo(details);
|
|
|
|
|
|
|
|
section.create(div);
|
|
|
|
|
|
|
|
details.append('<hr/>');
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
function setup(container) {
|
|
|
|
|
|
|
|
that.facet_setup(container);
|
|
|
|
|
|
|
|
var button = $('input[name=reset]', that.container);
|
2010-12-09 15:32:22 -06:00
|
|
|
that.reset_button = IPA.action_button({
|
2010-12-09 10:43:21 -06:00
|
|
|
'label': 'Reset',
|
|
|
|
'icon': 'ui-icon-refresh',
|
|
|
|
'class': 'details-reset',
|
|
|
|
'click': function() {
|
|
|
|
that.reset();
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
button.replaceWith(that.reset_button);
|
|
|
|
|
|
|
|
button = $('input[name=update]', that.container);
|
2010-12-09 15:32:22 -06:00
|
|
|
that.update_button = IPA.action_button({
|
2010-12-09 10:43:21 -06:00
|
|
|
'label': 'Update',
|
|
|
|
'icon': 'ui-icon-check',
|
|
|
|
'class': 'details-update',
|
|
|
|
'click': function() {
|
|
|
|
that.update();
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
button.replaceWith(that.update_button);
|
|
|
|
|
|
|
|
for (var i = 0; i < that.sections.length; ++i) {
|
|
|
|
var section = that.sections[i];
|
|
|
|
|
|
|
|
var header = $('h2[name='+section.name+']', that.container);
|
|
|
|
|
2011-01-12 13:47:29 -06:00
|
|
|
var div = $('#'+that.entity_name+'-'+that.name+'-'+section.name,
|
|
|
|
that.container);
|
2010-12-09 10:43:21 -06:00
|
|
|
|
|
|
|
header.click(function(section, header, div) {
|
|
|
|
return function() {
|
|
|
|
var visible = div.is(":visible");
|
|
|
|
header.html(that.get_section_header_prefix(!visible) + ' ' + section.label);
|
|
|
|
div.slideToggle();
|
2011-01-12 13:47:29 -06:00
|
|
|
};
|
2010-12-09 10:43:21 -06:00
|
|
|
}(section, header, div));
|
|
|
|
|
|
|
|
section.setup(div);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
SUDO adjustments
The SUDO rule details facet has been updated to support the latest UI
spec. The facet consists of 5 sections: general, users, hosts, commands,
and run-as.
The general section contains the SUDO rule description and status. If
the status is changed, the sudorule-enable/disable will be invoked.
The other sections contain radio buttons for the association category
and tables for the members. When a member is added or removed, the
category will be adjusted appropriately. If the category is changed to
'all', 'allow', or 'deny', all members will be removed.
The last section is currently not working because backend support is
not yet available.
The adder dialog boxes for users, groups, and hosts has been modified
to accept external identities. The layout for the base adder dialog
was updated. The base dialog class was updated to support templates.
The SUDO dialog boxes were implemented using templates. New CSS
classes were added to ipa.css.
The HBAC rule details facet has been updated as well.
2010-12-07 01:51:51 -06:00
|
|
|
function is_dirty() {
|
|
|
|
var pkey = $.bbq.getState(that.entity_name + '-pkey', true) || '';
|
|
|
|
return pkey != that.pkey;
|
|
|
|
}
|
|
|
|
|
|
|
|
function load(record) {
|
|
|
|
that.record = record;
|
|
|
|
for (var i=0; i<that.sections.length; i++) {
|
|
|
|
var section = that.sections[i];
|
|
|
|
section.load(record);
|
|
|
|
}
|
2011-01-10 20:14:51 -06:00
|
|
|
if (that.pkey){
|
|
|
|
$('h1 #headerpkey',that.container).html(that.pkey+": ");
|
|
|
|
}
|
SUDO adjustments
The SUDO rule details facet has been updated to support the latest UI
spec. The facet consists of 5 sections: general, users, hosts, commands,
and run-as.
The general section contains the SUDO rule description and status. If
the status is changed, the sudorule-enable/disable will be invoked.
The other sections contain radio buttons for the association category
and tables for the members. When a member is added or removed, the
category will be adjusted appropriately. If the category is changed to
'all', 'allow', or 'deny', all members will be removed.
The last section is currently not working because backend support is
not yet available.
The adder dialog boxes for users, groups, and hosts has been modified
to accept external identities. The layout for the base adder dialog
was updated. The base dialog class was updated to support templates.
The SUDO dialog boxes were implemented using templates. New CSS
classes were added to ipa.css.
The HBAC rule details facet has been updated as well.
2010-12-07 01:51:51 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
function reset() {
|
2011-01-10 20:14:51 -06:00
|
|
|
|
SUDO adjustments
The SUDO rule details facet has been updated to support the latest UI
spec. The facet consists of 5 sections: general, users, hosts, commands,
and run-as.
The general section contains the SUDO rule description and status. If
the status is changed, the sudorule-enable/disable will be invoked.
The other sections contain radio buttons for the association category
and tables for the members. When a member is added or removed, the
category will be adjusted appropriately. If the category is changed to
'all', 'allow', or 'deny', all members will be removed.
The last section is currently not working because backend support is
not yet available.
The adder dialog boxes for users, groups, and hosts has been modified
to accept external identities. The layout for the base adder dialog
was updated. The base dialog class was updated to support templates.
The SUDO dialog boxes were implemented using templates. New CSS
classes were added to ipa.css.
The HBAC rule details facet has been updated as well.
2010-12-07 01:51:51 -06:00
|
|
|
for (var i=0; i<that.sections.length; i++) {
|
|
|
|
var section = that.sections[i];
|
|
|
|
section.reset();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-11-16 18:10:40 -06:00
|
|
|
that.details_facet_init = that.init;
|
2010-11-18 20:17:14 -06:00
|
|
|
that.details_facet_create = that.create;
|
SUDO adjustments
The SUDO rule details facet has been updated to support the latest UI
spec. The facet consists of 5 sections: general, users, hosts, commands,
and run-as.
The general section contains the SUDO rule description and status. If
the status is changed, the sudorule-enable/disable will be invoked.
The other sections contain radio buttons for the association category
and tables for the members. When a member is added or removed, the
category will be adjusted appropriately. If the category is changed to
'all', 'allow', or 'deny', all members will be removed.
The last section is currently not working because backend support is
not yet available.
The adder dialog boxes for users, groups, and hosts has been modified
to accept external identities. The layout for the base adder dialog
was updated. The base dialog class was updated to support templates.
The SUDO dialog boxes were implemented using templates. New CSS
classes were added to ipa.css.
The HBAC rule details facet has been updated as well.
2010-12-07 01:51:51 -06:00
|
|
|
that.details_facet_load = that.load;
|
2010-11-16 18:10:40 -06:00
|
|
|
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
return that;
|
2011-01-14 11:16:25 -06:00
|
|
|
};
|
2010-10-27 22:32:30 -05:00
|
|
|
|
2010-12-09 15:32:22 -06:00
|
|
|
IPA.action_button = function(spec) {
|
2011-01-12 18:51:22 -06:00
|
|
|
var button = IPA.button(spec);
|
2010-12-09 15:32:22 -06:00
|
|
|
button.removeClass("ui-state-default").addClass("action-button");
|
|
|
|
return button;
|
2011-01-12 13:47:29 -06:00
|
|
|
};
|
2010-12-09 15:32:22 -06:00
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
IPA.button = function(spec) {
|
2010-10-27 22:32:30 -05:00
|
|
|
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
spec = spec || {};
|
2010-10-27 22:32:30 -05:00
|
|
|
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
var button = $('<a/>', {
|
2011-01-06 08:16:05 -06:00
|
|
|
id: spec.id,
|
|
|
|
html: spec.label,
|
|
|
|
title: spec.title || spec.label,
|
2011-01-17 18:10:41 -06:00
|
|
|
'class': 'ui-state-default ui-corner-all'
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
});
|
2010-10-27 22:32:30 -05:00
|
|
|
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
if (spec.click) button.click(spec.click);
|
2010-11-29 08:46:39 -06:00
|
|
|
if (spec['class']) button.addClass(spec['class']);
|
2011-01-17 18:10:41 -06:00
|
|
|
|
|
|
|
if (spec.icon) {
|
|
|
|
button.addClass('input_link');
|
|
|
|
button.append('<span class="ui-icon '+spec.icon+'" ></span> ');
|
|
|
|
} else {
|
|
|
|
button.addClass('button-without-icon');
|
|
|
|
}
|
2010-10-27 22:32:30 -05:00
|
|
|
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
return button;
|
2011-01-14 11:16:25 -06:00
|
|
|
};
|
2010-10-27 22:32:30 -05:00
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
IPA.details_refresh = function () {
|
2010-09-29 00:52:56 -05:00
|
|
|
|
2010-11-09 14:22:31 -06:00
|
|
|
var that = this;
|
|
|
|
|
|
|
|
that.pkey = $.bbq.getState(that.entity_name + '-pkey', true) || '';
|
|
|
|
|
|
|
|
function on_success(data, text_status, xhr) {
|
2010-11-18 20:17:14 -06:00
|
|
|
that.load(data.result.result);
|
Certificate management for services.
This is an initial implementation of certificate management for
services. It addresses the mechanism required to view and update
certificates. The complete UI implementation will be addressed in
subsequent patches.
On the server side, the service.py has been modified to define
usercertificate in the service object's takes_params. This is
needed to generate the proper JSON metadata which is needed by
the UI. It also has been modified to accept null certificate for
deletion.
On the client side, the service details page has been modified to
display the base64-encoded certificate in a text area. When the
page is saved, the action handler will store the base64-encoded
certificate in the proper JSON structure. Also the service name
and service hostname are now displayed in separate fields.
The details configuration has been modified to support displaying
and updating certificates. The structure is changed to use maps
to define sections and fields. A section contains name, label,
and an array of fields. A field contains name, label, setup
function, load function, and save function. This is used to
implement custom interface and behavior for certificates.
All other entities, test cases, and test data have been updated
accordingly. Some functions and variables have been renamed to
improve clarity and consistency.
2010-10-07 14:02:44 -05:00
|
|
|
}
|
2010-11-09 14:22:31 -06:00
|
|
|
|
|
|
|
function on_failure(xhr, text_status, error_thrown) {
|
2010-11-18 20:17:14 -06:00
|
|
|
var details = $('.details', that.container).empty();
|
2010-11-09 14:22:31 -06:00
|
|
|
details.append('<p>Error: '+error_thrown.name+'</p>');
|
|
|
|
details.append('<p>'+error_thrown.title+'</p>');
|
|
|
|
details.append('<p>'+error_thrown.message+'</p>');
|
|
|
|
}
|
|
|
|
|
|
|
|
var params = [];
|
|
|
|
if (that.pkey) params.push(that.pkey);
|
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
IPA.cmd( 'show', params, {all: true, rights: true}, on_success, on_failure,
|
2011-01-12 13:47:29 -06:00
|
|
|
that.entity_name );
|
2011-01-14 11:16:25 -06:00
|
|
|
};
|
2010-09-16 09:28:07 -05:00
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
IPA.details_update = function (on_win, on_fail)
|
2010-08-06 09:01:44 -05:00
|
|
|
{
|
2010-11-18 20:17:14 -06:00
|
|
|
var that = this;
|
|
|
|
var entity_name = that.entity_name;
|
|
|
|
|
2010-09-16 09:28:07 -05:00
|
|
|
function update_on_win(data, text_status, xhr) {
|
|
|
|
if (on_win)
|
|
|
|
on_win(data, text_status, xhr);
|
|
|
|
if (data.error)
|
|
|
|
return;
|
2010-08-06 09:01:44 -05:00
|
|
|
|
2010-09-16 09:28:07 -05:00
|
|
|
var result = data.result.result;
|
2010-11-18 20:17:14 -06:00
|
|
|
that.load(result);
|
Certificate management for services.
This is an initial implementation of certificate management for
services. It addresses the mechanism required to view and update
certificates. The complete UI implementation will be addressed in
subsequent patches.
On the server side, the service.py has been modified to define
usercertificate in the service object's takes_params. This is
needed to generate the proper JSON metadata which is needed by
the UI. It also has been modified to accept null certificate for
deletion.
On the client side, the service details page has been modified to
display the base64-encoded certificate in a text area. When the
page is saved, the action handler will store the base64-encoded
certificate in the proper JSON structure. Also the service name
and service hostname are now displayed in separate fields.
The details configuration has been modified to support displaying
and updating certificates. The structure is changed to use maps
to define sections and fields. A section contains name, label,
and an array of fields. A field contains name, label, setup
function, load function, and save function. This is used to
implement custom interface and behavior for certificates.
All other entities, test cases, and test data have been updated
accordingly. Some functions and variables have been renamed to
improve clarity and consistency.
2010-10-07 14:02:44 -05:00
|
|
|
}
|
2010-09-16 09:28:07 -05:00
|
|
|
|
|
|
|
function update_on_fail(xhr, text_status, error_thrown) {
|
|
|
|
if (on_fail)
|
|
|
|
on_fail(xhr, text_status, error_thrown);
|
Certificate management for services.
This is an initial implementation of certificate management for
services. It addresses the mechanism required to view and update
certificates. The complete UI implementation will be addressed in
subsequent patches.
On the server side, the service.py has been modified to define
usercertificate in the service object's takes_params. This is
needed to generate the proper JSON metadata which is needed by
the UI. It also has been modified to accept null certificate for
deletion.
On the client side, the service details page has been modified to
display the base64-encoded certificate in a text area. When the
page is saved, the action handler will store the base64-encoded
certificate in the proper JSON structure. Also the service name
and service hostname are now displayed in separate fields.
The details configuration has been modified to support displaying
and updating certificates. The structure is changed to use maps
to define sections and fields. A section contains name, label,
and an array of fields. A field contains name, label, setup
function, load function, and save function. This is used to
implement custom interface and behavior for certificates.
All other entities, test cases, and test data have been updated
accordingly. Some functions and variables have been renamed to
improve clarity and consistency.
2010-10-07 14:02:44 -05:00
|
|
|
}
|
2010-08-06 09:01:44 -05:00
|
|
|
|
Certificate management for services.
This is an initial implementation of certificate management for
services. It addresses the mechanism required to view and update
certificates. The complete UI implementation will be addressed in
subsequent patches.
On the server side, the service.py has been modified to define
usercertificate in the service object's takes_params. This is
needed to generate the proper JSON metadata which is needed by
the UI. It also has been modified to accept null certificate for
deletion.
On the client side, the service details page has been modified to
display the base64-encoded certificate in a text area. When the
page is saved, the action handler will store the base64-encoded
certificate in the proper JSON structure. Also the service name
and service hostname are now displayed in separate fields.
The details configuration has been modified to support displaying
and updating certificates. The structure is changed to use maps
to define sections and fields. A section contains name, label,
and an array of fields. A field contains name, label, setup
function, load function, and save function. This is used to
implement custom interface and behavior for certificates.
All other entities, test cases, and test data have been updated
accordingly. Some functions and variables have been renamed to
improve clarity and consistency.
2010-10-07 14:02:44 -05:00
|
|
|
var values;
|
2010-11-05 12:11:56 -05:00
|
|
|
var modlist = {'all': true, 'setattr': [], 'addattr': [], 'rights': true};
|
2010-08-06 09:01:44 -05:00
|
|
|
var attrs_wo_option = {};
|
|
|
|
|
2010-11-18 20:17:14 -06:00
|
|
|
for (var i=0; i<that.sections.length; i++) {
|
|
|
|
var section = that.sections[i];
|
HBAC Details Page
The UI framework has been extended to include a collection of widgets:
- ipa_widget: base class
- ipa_text_widget: text field
- ipa_radio_widget: radio button
- ipa_textarea_widget: textarea
- ipa_button_widget: button
- ipa_column_widget: column for table
- ipa_table_widget: table
These widgets can be used to create input controls. They can also be
extended to create custom controls.
The framework has also been enhanced to support custom layouts. This
can be used to change the look of the application without changing
the code. Initially this is only available in details section.
Layout consists of a collection of HTML templates. Each template is a
complete and valid HTML file representing a portion of a page. The
template will be loaded and initialized by the code, then filled with
the data from the server. The layouts are located in
install/static/layouts/<name> folder.
By default, if no templates are used, the fields in the details page
are rendered vertically using dd/dt/dd tags. For pages that require
different layout, a custom UI needs to be developed. There are two ways
to do that:
- write a custom widget to generate the UI dynamically
- create an HTML template and write the initialization code
For components that are quite complex or used frequently, it's might
be better to use the first method. For simple pages that are used only
in one location or need to support customization, the second method
might be preferable. Other benefits of templates:
- cleaner code and UI separation
- more flexibility in customization
- new pages can be developed quickly and require less coding
- multiple templates can be used with the same initialization code
- easier to maintain
The HBAC details page has been implemented using both methods. By
default it will use custom widgets to generate the page. To use a
custom layout, add the following parameter to the URL, then reload
the page:
&layout=<name>
Currently the only available layout is 'default' which produces the
same look as the custom widgets.
The HBAC details page is usable, but it still needs additional work.
The access time is not working yet. There is no undo button, hint,
or validation yet.
The table in the association facet has also been changed to use
ipa_association_widget which is derived from ipa_table_widget.
The Makefile has been updated to include the layouts. The unit tests
have been updated as well.
2010-11-02 20:16:55 -05:00
|
|
|
|
2010-10-25 18:55:57 -05:00
|
|
|
if (section.save){
|
|
|
|
section.save(modlist);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2010-11-18 20:17:14 -06:00
|
|
|
var div = $('#'+that.entity_name+'-'+that.name+'-'+section.name, that.container);
|
2010-08-06 09:01:44 -05:00
|
|
|
|
2010-11-09 14:22:31 -06:00
|
|
|
for (var j=0; j<section.fields.length; j++) {
|
|
|
|
var field = section.fields[j];
|
2010-08-06 09:01:44 -05:00
|
|
|
|
2010-11-15 11:10:55 -06:00
|
|
|
var span = $('span[name='+field.name+']', div).first();
|
2010-11-18 20:17:14 -06:00
|
|
|
values = field.save();
|
|
|
|
if (!values) continue;
|
2010-08-06 09:01:44 -05:00
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
var param_info = IPA.get_param_info(entity_name, field.name);
|
Certificate management for services.
This is an initial implementation of certificate management for
services. It addresses the mechanism required to view and update
certificates. The complete UI implementation will be addressed in
subsequent patches.
On the server side, the service.py has been modified to define
usercertificate in the service object's takes_params. This is
needed to generate the proper JSON metadata which is needed by
the UI. It also has been modified to accept null certificate for
deletion.
On the client side, the service details page has been modified to
display the base64-encoded certificate in a text area. When the
page is saved, the action handler will store the base64-encoded
certificate in the proper JSON structure. Also the service name
and service hostname are now displayed in separate fields.
The details configuration has been modified to support displaying
and updating certificates. The structure is changed to use maps
to define sections and fields. A section contains name, label,
and an array of fields. A field contains name, label, setup
function, load function, and save function. This is used to
implement custom interface and behavior for certificates.
All other entities, test cases, and test data have been updated
accordingly. Some functions and variables have been renamed to
improve clarity and consistency.
2010-10-07 14:02:44 -05:00
|
|
|
if (param_info) {
|
|
|
|
if (param_info['primary_key']) continue;
|
2010-10-22 15:23:02 -05:00
|
|
|
if (values.length === 1) {
|
|
|
|
modlist[field.name] = values[0];
|
|
|
|
}else if (values.length > 1){
|
|
|
|
modlist[field.name] = values;
|
|
|
|
} else if (param_info['multivalue']){
|
2010-11-18 20:17:14 -06:00
|
|
|
modlist[field.name] = [];
|
2010-10-22 15:23:02 -05:00
|
|
|
}
|
Certificate management for services.
This is an initial implementation of certificate management for
services. It addresses the mechanism required to view and update
certificates. The complete UI implementation will be addressed in
subsequent patches.
On the server side, the service.py has been modified to define
usercertificate in the service object's takes_params. This is
needed to generate the proper JSON metadata which is needed by
the UI. It also has been modified to accept null certificate for
deletion.
On the client side, the service details page has been modified to
display the base64-encoded certificate in a text area. When the
page is saved, the action handler will store the base64-encoded
certificate in the proper JSON structure. Also the service name
and service hostname are now displayed in separate fields.
The details configuration has been modified to support displaying
and updating certificates. The structure is changed to use maps
to define sections and fields. A section contains name, label,
and an array of fields. A field contains name, label, setup
function, load function, and save function. This is used to
implement custom interface and behavior for certificates.
All other entities, test cases, and test data have been updated
accordingly. Some functions and variables have been renamed to
improve clarity and consistency.
2010-10-07 14:02:44 -05:00
|
|
|
} else {
|
|
|
|
if (values.length) attrs_wo_option[field.name] = values;
|
|
|
|
}
|
2010-08-25 11:49:30 -05:00
|
|
|
}
|
Certificate management for services.
This is an initial implementation of certificate management for
services. It addresses the mechanism required to view and update
certificates. The complete UI implementation will be addressed in
subsequent patches.
On the server side, the service.py has been modified to define
usercertificate in the service object's takes_params. This is
needed to generate the proper JSON metadata which is needed by
the UI. It also has been modified to accept null certificate for
deletion.
On the client side, the service details page has been modified to
display the base64-encoded certificate in a text area. When the
page is saved, the action handler will store the base64-encoded
certificate in the proper JSON structure. Also the service name
and service hostname are now displayed in separate fields.
The details configuration has been modified to support displaying
and updating certificates. The structure is changed to use maps
to define sections and fields. A section contains name, label,
and an array of fields. A field contains name, label, setup
function, load function, and save function. This is used to
implement custom interface and behavior for certificates.
All other entities, test cases, and test data have been updated
accordingly. Some functions and variables have been renamed to
improve clarity and consistency.
2010-10-07 14:02:44 -05:00
|
|
|
}
|
2010-08-06 09:01:44 -05:00
|
|
|
|
2011-01-14 11:16:25 -06:00
|
|
|
for (var attr in attrs_wo_option) {
|
Certificate management for services.
This is an initial implementation of certificate management for
services. It addresses the mechanism required to view and update
certificates. The complete UI implementation will be addressed in
subsequent patches.
On the server side, the service.py has been modified to define
usercertificate in the service object's takes_params. This is
needed to generate the proper JSON metadata which is needed by
the UI. It also has been modified to accept null certificate for
deletion.
On the client side, the service details page has been modified to
display the base64-encoded certificate in a text area. When the
page is saved, the action handler will store the base64-encoded
certificate in the proper JSON structure. Also the service name
and service hostname are now displayed in separate fields.
The details configuration has been modified to support displaying
and updating certificates. The structure is changed to use maps
to define sections and fields. A section contains name, label,
and an array of fields. A field contains name, label, setup
function, load function, and save function. This is used to
implement custom interface and behavior for certificates.
All other entities, test cases, and test data have been updated
accordingly. Some functions and variables have been renamed to
improve clarity and consistency.
2010-10-07 14:02:44 -05:00
|
|
|
values = attrs_wo_option[attr];
|
2010-08-25 11:49:30 -05:00
|
|
|
modlist['setattr'].push(attr + '=' + values[0]);
|
2011-01-12 13:47:29 -06:00
|
|
|
for (var k = 1; k < values.length; ++k){
|
|
|
|
modlist['addattr'].push(attr + '=' + values[k]);
|
|
|
|
}
|
2010-08-06 09:01:44 -05:00
|
|
|
}
|
|
|
|
|
2011-01-14 12:19:56 -06:00
|
|
|
var pkey = that.get_primary_key() ;
|
|
|
|
if (pkey){
|
|
|
|
pkey = [pkey];
|
|
|
|
}else{
|
|
|
|
pkey = [];
|
|
|
|
}
|
|
|
|
|
|
|
|
IPA.cmd('mod', pkey, modlist, update_on_win, null, entity_name);
|
2011-01-14 11:16:25 -06:00
|
|
|
};
|
2010-08-06 09:01:44 -05:00
|
|
|
|
Certificate management for services.
This is an initial implementation of certificate management for
services. It addresses the mechanism required to view and update
certificates. The complete UI implementation will be addressed in
subsequent patches.
On the server side, the service.py has been modified to define
usercertificate in the service object's takes_params. This is
needed to generate the proper JSON metadata which is needed by
the UI. It also has been modified to accept null certificate for
deletion.
On the client side, the service details page has been modified to
display the base64-encoded certificate in a text area. When the
page is saved, the action handler will store the base64-encoded
certificate in the proper JSON structure. Also the service name
and service hostname are now displayed in separate fields.
The details configuration has been modified to support displaying
and updating certificates. The structure is changed to use maps
to define sections and fields. A section contains name, label,
and an array of fields. A field contains name, label, setup
function, load function, and save function. This is used to
implement custom interface and behavior for certificates.
All other entities, test cases, and test data have been updated
accordingly. Some functions and variables have been renamed to
improve clarity and consistency.
2010-10-07 14:02:44 -05:00
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
IPA.create_first_dd = function (field_name, content){
|
2010-11-16 18:10:40 -06:00
|
|
|
var dd = $('<dd/>', {
|
Certificate management for services.
This is an initial implementation of certificate management for
services. It addresses the mechanism required to view and update
certificates. The complete UI implementation will be addressed in
subsequent patches.
On the server side, the service.py has been modified to define
usercertificate in the service object's takes_params. This is
needed to generate the proper JSON metadata which is needed by
the UI. It also has been modified to accept null certificate for
deletion.
On the client side, the service details page has been modified to
display the base64-encoded certificate in a text area. When the
page is saved, the action handler will store the base64-encoded
certificate in the proper JSON structure. Also the service name
and service hostname are now displayed in separate fields.
The details configuration has been modified to support displaying
and updating certificates. The structure is changed to use maps
to define sections and fields. A section contains name, label,
and an array of fields. A field contains name, label, setup
function, load function, and save function. This is used to
implement custom interface and behavior for certificates.
All other entities, test cases, and test data have been updated
accordingly. Some functions and variables have been renamed to
improve clarity and consistency.
2010-10-07 14:02:44 -05:00
|
|
|
'class': 'first',
|
|
|
|
'title': field_name
|
2010-11-16 18:10:40 -06:00
|
|
|
});
|
|
|
|
if (content) dd.append(content);
|
|
|
|
return dd;
|
2011-01-14 11:16:25 -06:00
|
|
|
};
|
2010-08-06 09:01:44 -05:00
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
IPA.create_other_dd = function (field_name, content){
|
Certificate management for services.
This is an initial implementation of certificate management for
services. It addresses the mechanism required to view and update
certificates. The complete UI implementation will be addressed in
subsequent patches.
On the server side, the service.py has been modified to define
usercertificate in the service object's takes_params. This is
needed to generate the proper JSON metadata which is needed by
the UI. It also has been modified to accept null certificate for
deletion.
On the client side, the service details page has been modified to
display the base64-encoded certificate in a text area. When the
page is saved, the action handler will store the base64-encoded
certificate in the proper JSON structure. Also the service name
and service hostname are now displayed in separate fields.
The details configuration has been modified to support displaying
and updating certificates. The structure is changed to use maps
to define sections and fields. A section contains name, label,
and an array of fields. A field contains name, label, setup
function, load function, and save function. This is used to
implement custom interface and behavior for certificates.
All other entities, test cases, and test data have been updated
accordingly. Some functions and variables have been renamed to
improve clarity and consistency.
2010-10-07 14:02:44 -05:00
|
|
|
return $('<dd/>', {
|
|
|
|
'class': 'other',
|
|
|
|
'title': field_name
|
|
|
|
}).append(content);
|
2011-01-14 11:16:25 -06:00
|
|
|
};
|
2010-08-06 09:01:44 -05:00
|
|
|
|
|
|
|
|
|
|
|
/* creates a Remove link for deleting attribute values */
|
|
|
|
function _ipa_create_remove_link(attr, param_info)
|
|
|
|
{
|
2011-01-14 11:16:25 -06:00
|
|
|
if (param_info){
|
|
|
|
/* check if the param is required or of the Password type
|
|
|
|
* if it is, then we don't want people to be able to remove it */
|
|
|
|
if ((param_info['required']) || (param_info['class'] == 'Password')){
|
|
|
|
return ('');
|
|
|
|
}
|
|
|
|
}
|
2010-10-22 15:23:02 -05:00
|
|
|
return $('<a/>',{
|
|
|
|
href:"jslink",
|
2011-01-12 13:47:29 -06:00
|
|
|
click: function (){return (_ipa_remove_on_click(this));},
|
2010-10-22 15:23:02 -05:00
|
|
|
title: attr,
|
|
|
|
text: 'Remove'});
|
|
|
|
|
2010-08-06 09:01:44 -05:00
|
|
|
}
|
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
IPA.details_field_create_add_link = function (title, rights, index) {
|
2010-08-06 09:01:44 -05:00
|
|
|
|
2010-11-16 18:10:40 -06:00
|
|
|
var that = this;
|
2010-08-25 11:49:30 -05:00
|
|
|
|
2010-11-16 18:10:40 -06:00
|
|
|
var link = $('<a/>', {
|
|
|
|
'href': 'jslink',
|
|
|
|
'title': title,
|
|
|
|
'html': 'Add',
|
|
|
|
'click': function () {
|
2010-10-22 15:23:02 -05:00
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
var param_info = IPA.get_param_info(that.entity_name, '');
|
2011-01-12 21:00:38 -06:00
|
|
|
var input = that.create_input('', param_info, rights, index);
|
2010-08-25 11:49:30 -05:00
|
|
|
|
2010-11-16 18:10:40 -06:00
|
|
|
link.replaceWith(input);
|
|
|
|
input.focus();
|
|
|
|
|
2011-01-12 18:51:22 -06:00
|
|
|
var dd = IPA.create_other_dd(that.name);
|
|
|
|
dd.append(IPA.details_field_create_add_link.call(that, that.name, rights, index+1));
|
2010-11-16 18:10:40 -06:00
|
|
|
dd.appendTo(that.container);
|
2010-08-06 09:01:44 -05:00
|
|
|
|
2010-11-16 18:10:40 -06:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
return link;
|
2011-01-14 11:16:25 -06:00
|
|
|
};
|
2010-10-22 15:23:02 -05:00
|
|
|
|
|
|
|
|
2010-08-06 09:01:44 -05:00
|
|
|
function _ipa_remove_on_click(obj)
|
|
|
|
{
|
|
|
|
var jobj = $(obj);
|
|
|
|
var attr = jobj.attr('title');
|
|
|
|
var par = jobj.parent();
|
|
|
|
|
2010-10-13 12:07:43 -05:00
|
|
|
var input = par.find('input');
|
2010-08-06 09:01:44 -05:00
|
|
|
|
2010-10-22 15:23:02 -05:00
|
|
|
if (input.is('.strikethrough')){
|
|
|
|
input.removeClass('strikethrough');
|
|
|
|
jobj.text("Remove");
|
|
|
|
}else{
|
|
|
|
input.addClass('strikethrough');
|
|
|
|
jobj.text("Undo");
|
|
|
|
}
|
2010-08-06 09:01:44 -05:00
|
|
|
return (false);
|
|
|
|
}
|