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:
Related
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
Requirement:
The business provides a URL in the format as (":category/:name") and against this format, system will have an SKU defined for which PDP needs to be opened without changing the URL.
e.g. for a defined URL -- https://example.com/categoryName/baseProductName and SKU (SKU123) will be configured in backend.
When a customer opens the above URL, the PDP of SKU123 should load where the URL remains the same.
Spartacus code has a constraint that PDP cannot be opened without providing a product code (SKU number) to it. We have tried to override the routing configurations but internally spartacus is redirecting to a 404 page.
In Spartacus Docs(https://sap.github.io/spartacus-docs/route-configuration/) it is mentioned that it is not allowed otherwise functionality will break.
I am looking for a workaround on the same to allow routing config as (":category/:name") and (":category/:name/:productCode") both which seems to be a constraint from Spartacus end. We can feed in the productCode but the URL needs to be as is.
The current PDP functionality should not break.
Spartacus: 1.4.4
SAP Commerce: 1905
that's an interesting question, and not straightforward to solve actually. I'll give you a few pointers to workaround.
First off, Spartacus uses the product code as a unique key in all layers of the application. The code is used in the routing logic, in the store and to load the product from the backend.
Moreover, the code is passed to the CMS, as the CMS is capable to resolve custom page structure per product; you can configure a specific CMS page structure for a specific product code or product category; therefor the product code is passed as an id to the CMS when loading.
To workaround these features you need to configure and override a number of things:
Bring product name into the routing configuration
You can easily do this with the routing configuration, or just by provide a paramsMapping from product.code to product.name. More on this can be found at the docs. Additionally, you could prettify the product name (avoid spaces and other characters to avoid ugly encoding)
Bring the category name into the routing configuration
Before you can configure the router (see 1) for the category name, you need to get the category from the backend. You can do this by normalising the (first) category from the product model. However, by default the product doesn't contain the categories, which is why you'd need to configure the OCC field configuration. It's all described at https://sap.github.io/spartacus-docs/connecting-to-other-systems/. Special attention is required for the SOLR results, as they also need to expose the categories.
Additionally, you could prettify the product name (avoid spaces and other characters to avoid ugly encoding)
Change the product key internally
To ensure that the category name and product name are used instead of the product code to store (ngrx) and load (OCC) the product, you need to trick the system. You can provide a custom implementation of the CurrentProductService, where you'd evaluate if the Router state contains the category name and product name parameters. If those parameters are available, you would concatenate them so that they can later on be reconstructed.
Load product data by category and product name
You could introduce a custom adapter to resolve the product code by it's category and product name, but i'd not recommend this. It would involve an additional API call, and that's expensive. Instead, I would implement a custom backend endpoint, that takes the the category and product name. You could still provide a custom adapter in Spartacus, for deconstructing the concatenated category and product name from step 3, as this would result in a cleaner code base.
Load CMS product page by category and product name
The CMS uses the product code (id) as well to load the right cms structure. You could do 2 things here:
a. use the same pattern from step 4; create custom OCC endpoint to resolve the product code and then load the right CMS product page structure
b. use a static (but existing) product code in a customer OccCmsPageAdapter, to load the same CMS structure for all product pages. This will obviously block existing CMS functionality, but it might be ok. Or at least for your first implementation you can get it to work with this workaround.
Hope that gives you an idea or 2.
All of this being said, I believe this is quite an uncommon requirement. Not that you need pretty URLs and want to use the product name as a unique "code". But using both the category name and product name as a unique key. If possible, I'd try to move into this pattern:
use the product category and product name in the title for SEO purposes (exactly as you require)
only depend on the product code as being the unique property
change the product code structure in the backend; the product.code there are various ways to do this, the idea is that the actual product code could be stored in an alternative field, and the generated (based on name) product.code in the native code field.
all application logic (UIs, APIs, SOLR, Spartacus) will transparently use the product name as the unique key.
We are facing a strange issue with the Look-back API.
We have created a Custom field initially as xyz, back end name c_xyz for the features.
After few days we renamed the Custom attribute to abc which in-turn changed the back-end name to c_abc, which was an expected behavior.
However , the Lookback API still gives the old field name c_xyz in the result set of that object till we actually make an update via UI/API on the abc(c_abc) attribute. Is there any way we can workaround this, apart from updating the particular value.
Briefly, no. Responding to field name changes in this way would be a big performance hit.
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".
I want to create a custom field type (MyCompLookup) that will be used in lists that all users will have access to. However, the field type will be fairly complicated / confusing to a regular user who is creating a simple list in their department's site. Is there a way to restrict certain users from selecting the custom field when they are creating columns for their lists?
I'm afraid you can't set ACL on field types.
A few things you can do to achieve some kind of workaround:
Add a custom logic in SPField OnAdded method that removes the field immediately after it was added by a regular user. This method might be very confusing for users, so at least you should give a descriptive name to your field. You can find a similar solution here, where I add extra fields to the list in this method.
You can add a custom editor control (see a simple sample here) to your field, that interactsts with other controls on the add new field page, for example disables the OK button.
Hope it helps.