We are developing a grants management tool on the Salesforce Platform. The Web interface for grant seekers is in .NET and it communicates with Salesforce via API.
Issue: Fields that are part of the Salesforce Managed Package can't be modified.
Specific issue and example: currency fields are all defined with 2 decimals in the Managed Package as this is what most Foundations (customers) want. But some Foundations would like not to display any decimals to the grant seeker (on the Web interface) for these managed package fields.
Question: Is there any way to overwrite the Managed Package field property for the number of decimals displayed (currently defined to show two decimals)?
Thanks for your help.
I don't know of a direct way to change the field settings in an installed managed package.
Some alternatives, with varying degrees of hackeness:
You could create a validation rule and formula field to fake it. Use the formula field for display layouts to show the value of the managed package field less the decimal places. Use the validation rule to stop users enter a value with decimal places (E.g. ROUND(number, num_digits)).
Create your own custom field with the desired number of decimal places. Only display your custom field on the page layout and hide the managed package field. Then copy the value from your custom field into the managed packages field when required. A before insert or before update trigger could handle this.
Related
I want to create a custom field in the agent new ticket screen.
I want the field to be shown as a dropdown list where the values in the dropdown list will be values taken from an API of other service.
I know Zendesk custom fields have an option to upload a csv file with options but since I want to the values to be live updated it won't work for me.
I'm wondering whether I need to create a plugin that will do that job or Zendesk have a solution for this need.
I am not sure this is a suitable stackoverflow questions, but if you have control over the backend of the other service, it is better to automate a call from it to Zendesk custom fields API whenever there are changes to the drop down options.
However, this is a bad idea in the first place because drop down options are associated to tags. There might be conflicts with other field options or other tags used by agents. This will be a nightmare for the data analysts who rely on tags for Zendesk Explore reports, especially if you delete an options and its associated tags.
So I am working on a project to create Jira issue automatically from Logic App.
I want to ask if there is a way to set the priority also.
For creating the ticket this is the only fields that can set.
To make it visible over Logic Apps, you need to check the required box in the field but currently Logic Apps do not support jira field types other than string, number, date and datetime.
However as an alterative, You can add a short text field to enter the priority level.
In jira
In LogicApps
For more information, You can refer Jira Connector - Known Issues and Limitations
Is it possible to restrict part of a smart to only a certain user group and if the user trying to edit the smart form content is not of that group, then the user cannot change that portion of the content?
Example:
Let's say I have an Employee smart form with fields for EmployeeBio, EmployeeHireDate, and EmployeeDept. Would it be possible to allow the general author user group to be able to edit the EmployeeBio field, but restrict the EmployeeDept and EmployeeHireDate fields to only an HRAdmin user group?
If it helps, I am using Ektron 9.00 SP3.
As far as I know, you either can edit a content block or you can't; there isn't a way to subdivide permissions on a per-smartform-field basis.
What you can do, is group the "restricted" fields into their own smartform, and then reference that via a content resource selector field.
So your Employee smart form might look like this:
/root/txtName (not in your example, I know...)
/root/rtfBio
/root/cresHRID
Side note: I'm using hungarian notation on my field names here. txt indicates a plain text field, rtf indicates a rich text (html) field, and cres indicates a content resource selector.
Then you could have a second smart form... let's call it "EmployeeHR", and it would have the following structure:
/root/hireDate
/root/txtDepartment
That would, in theory, work. However, I must say that I really don't like splitting up this particular type of data in this way. First, department feels like it would function better as a taxonomy to which you could add the content block. Second, it feels like this type of data would be better served by housing it outside of ektron and then using a DxH (Digital Experience Hub) connector to bring the data into Ektron. This way the external system could handle permissions at a more granular level, and you would still have access to the data within Ektron for use elsewhere within the site.
UPDATE
As I ponder this question some more, another option comes to mind. You could write an ASPX page or UserControl that checks to make sure you're logged in and a member of a particular group before presenting you with a custom edit screen. The following code will check if the current user is a member of the admin group; you can swap out a different group id to fit your needs:
// Not sure off hand which of these using statements provides access to EkConstants...
using Ektron.Cms;
using Ektron.Cms.Common;
using Ektron.Cms.Content;
var userGroupApi = new Ektron.Cms.Framework.User.UserGroupManager();
var isInGroup = userGroupApi.IsUserInGroup(currentUserId, EkConstants.g_AdminGroup);
This could be implemented as an ASPX page on your site, or it could be implemented as a widget and placed on the user's Smart Desktop tab of the workarea. Either way, you have a lot of options for getting what you want, just nothing "out of the box".
The JIRA rest api documentation suggests that you should use the field name when sending in a custom field for a create issue request, because they are not unique across instances.
However, the field names you receive from calling the meta-data on a project are translated based on the language settings of the user. That also means that the field names are subject to change, because translations are controlled by the client.
Is there any way to recover the field's base name (which is not changeable) rather than the field's translated name, when calling the createmeta function?
(Or another best practice for determining which custom field you need to set which data to?)
I think you Can Not.
In my recent plugin I had to add fields to the settings screen to map Epic Name and Epic Link:
- Epic Name custom field name:
- Epic Link custom field name:
I'm currently developing a back-end for chefs at various restaurants to report their daily menues in a structured format. Of pragmatic reasons have I chosen to use a web CMS and use many of the features already include including a flexible rights-management module
I want to utilise the existing functions in Joomla for access control, editing and navigation, but I need to replace the textfield with five field (each representing one day of the working week) and save this in a structured way into the database. I was planning to create a editor plugin which displays the field for the chef-users and parse the in-data into a structured data-format e.g. XML. For each week I will need to create empty templates for all the restaurants displaying the week number and dates.
I was also hoping for third-party developers to access this data through RESTful methods in the URL where the structure could be something like: http://domain.no/restaurant-name/menu for a text-menu http://domain.no/restaurant-name/json for json etc.
I guess my question is how I can start developing such features. Has there been developed anything similar and are there modules developed for Joomla which I can utilise? Does my approach sounds sensible or are there any other good way of solving my problem?
For a custom content management i would use Zoo component from Yootheme (not free!). You can define your fields,
But for developers access, i have no idea, sorry!