Follow this link to our draft categorization of system properties. As a reminder, we have identified 4 access types and 4 value rules that we'd like your feedback on. Are the access types right for the way you implement your systems? Do the places we have added default value rules make sense? Should there be more? We do plan to make the value rules editable by the 'master'.
to view the document.
Please submit any feedback that you have by Friday August 17th.
Pinned topic Properties Categorization - what do you think?
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-08-15T01:20:31Z at 2012-08-15T01:20:31Z by StevenShull
StevenShull 270003PYB85 Posts
Re: Properties Categorization - what do you think?2012-08-15T01:20:31ZThis is the accepted answer. This is the accepted answer.Colleen,
Here are some things we've come up with at Projetech in regards to the System Properties (along with a few developer related questions).
• SMTP Properties (mail.smtp.host, mail.smtp.ssl.enable, mxe.smtp.user, mxe.smtp.password, etc.) -> should be a tenant level (2) instead of master (1) (and is a prime example of how a master account may wish to reduce it back down to a 1 level). Using one host for the entire system, in some cases is desired, but because Maximo sends email on behalf of the user’s domain the tenants may wish to have emails transferred from Maximo to their SMTP server instead of white listing the system SMTP server.
• LDAP Authentication-> These properties are at a system level, which is understandable, but is this something being addressed in a multitenant solution where more than one LDAP authentication can be used (one per tenant and potentially other tenants non LDAP)?
• mxe.adminmode.logoutmin -> Assuming this property is used for “mini” Admin mode, this would ideally be tenant level as some may have it at a level of 0 minutes while others wait 5 minutes. If this is for global DB Config than this property is accurately categorized.
• mxe.db.logSQLTimeLimit -> What’s the reasoning behind letting the tenants configure this property? Especially without restrictions, the users can fill up the logs with useless information by setting the value too low and in most systems, the tenants won’t be able to view the logs anyways.
• Doclink properties (mxe.doclink.doctypes.defpath, mxe.doclink.path01, etc.) -> Would be nice at a tenant level (2) so that doclinks amongst tenants would be isolated from one another, presuming that a folder unique to each tenant isn’t created automatically by Maximo.
• Email properties (mxe.email.content.type, mxe.email.charset)-> Would be nice at a tenant level. Some may not be able to receive HTML style emails and choose to change this, while others want the rich text coming through on emails.
• mxe.int.globaldir -> What’s the reasoning behind letting a tenant configure this when in most cases, they won’t have access to this? It makes sense to be separated on a tenant by tenant basis, but I don’t think we want tenants configuring this property.
• mxe.int.textqualifier-> Strangely this is flagged as System level, but the delimiter (mxe.int.flatfiledelimiter) is setup as tenant level. To us, it makes sense for both these to be tenant level 2.
• mxe.lsnr.validateperson-> This would make sense as a tenant property (2) because each client determines how to handle it differently. One may want it to ensure that the email address exists in Maximo because users should only be responding from their work email address. Others may find it acceptable that a user uses his Gmail account when he’s away, and that may or may not exist in Maximo.
I hope this helps, but I wanted to reiterate we think you guys are doing a GREAT job ob this. Keep up the good work!