Sum up all the Effort field (Custom Field) scored for each Epic under a Feature and push it to the Value field in the Feature. The AC/PPM integration will then automatically push that to PPM (Agile Score).
Related
For our Spartacus project, we need to introduce additional Data properties in the checkout:
We have the case, that the user needs to select a delivery mode per product.
In an ideal world, upon selection, the selected delivery mode would be saved in the NGRX Store and also in the Backend to stay within the principle of the data binding defined here: https://sap.github.io/spartacus-docs/connecting-to-other-systems/#component-data-binding
Expected Data / User flow:
User goes to Checkout and to Delivery Mode Step
Custom OCC Call is made to load the supported delivery modes for each product (depends on product type and further customer specific logic)
The cart items are displayed, enhanced with a dropdown containing the available delivery modes
The user selects a delivery mode
The selected delivery mode is stored on the cart entry within the NGRX Store and saved in the backend
The new Cart totals is calculated based on the costs of the selected delivery mode
The new Cart totals is stored on the cart within the NGRX Store and saved in the backend
The user clicks on continue to get to the Review Order Step
The cart items are listed with the previously selected delivery mode
After some analysis of the existing code, we found a property deliveryMode on the orderEntry. This does not seem to be used anywhere in spartacus, but could be used to make Step 9 work by following this stackoverflow answer and this one.
Questions regarding this flow:
How can we extend the NGRX Store? We assume, it would be possible to just extend the facade (Active Cart Service), bypass the store and save the information in the backend (Described here) and afterwards refresh the store from the backend. Is that Assumption correct? If yes, that feels awkward though, as we need to reload the whole store just to contain the new property deliveryMode on the orderEntry
How can we hook into the price calculation of the cart totals to update the total based on the selected delivery mode? And again, how can we bring the new total sum into the store?
There seem to be several Answers within the Slack Channel without very few usable answers around extending the ngrx store, even though for us, it seems to be a quit normal task.. :-/
Any thoughts, inputs or support would be very appreciated. :-)
This seems like a difficult thing to accomplish seeing as delivery modes per product aren't supported as-is in spartacus. But some ideas:
You can extend core CartEntry classes (adapter, connecter, facade, etc.) to include the delivery mode for entries added to the cart. You will probably need to change all to include the delivery mode setting(s). All of these are exposed so you can modify them as needed including the store.
Utilizing multiple carts to have a product per cart and set delivery mode that way. But this would be cumbersome in my opinion.
As far as price calculation goes, I'm assuming OCC calls return total prices. Does the call for the cart entries include delivery mode costs per entry?
We have implemented the following work around and it works so far:
Enhance the Cart Model in the backend
Add new Endpoints to load the available delivery Modes per Product (by bypassing the NGRX Store)
Add new Endpoints to save the selected Delivery Mode (by bypassing the NGRX Store)
After Save Endpoint, a cart Reload is triggered, which loads the new cart totals having a custom property on the order entry (via type augmentation) into the store from the backend
It's already a lot of years past since Spartacus project started, but looks like it's still really raw projects. Spartacus is not ready to deal with real word customer's requirement and complexity of customize it quickly grow at real project(so you start to think do we really need it, as it's so unflexible at some dimentions). Some parts is really hard or not possible to customize, so you begin to search a workarounds(This question is one common case).
I think NGRX Store is one of the biggest pain in the ass to customize something at Spartacus. 2 years past and nothing changed by Spartacus team...
I took a look at Bluesnap's Auth Capture API - https://developers.bluesnap.com/v8976-XML/docs/auth-capture specifically the "card-holder-info" element.
What minimum fields needs to be passed to maximize payment conversions? I want to map these fields to my checkout UI page where I would like to have my customers enter minimum number of fields to strike a balance between being frictionless vs maximize conversions.
Thanks.
The minimal details of the card holder are first name, last name and zip code. That's all the information BlueSnap requires to process the purchase.
The process is already pretty streamlined. From the optional fields you may add, adding country and state might have some effect as some processors use this information to validate the shopper.
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:
In an effort to unify and automate my activity report across multiple projects I am trying to generate a timeline-like report from several Trello boards.
An event on the timeline would be generated when a card is moved into the "Doing" list, with the time of list change as the start date.
The end date stays at the current date until the card is moved to the "Done" list at which point it's set to the date on which the activity was completed.
I've looked at some tools to connect Trello activity to Google Calendar, so far with no success:
Trello powerups: only provides due dates when connecting to the calendar
IFTTT - doesn't seem to provide Trello as a recipe source
Zapier - Only provides due date and last activity dates as source values
Ducksboard - No template available for this kind of visualisation
Ideally, an "API catalyst" like the ones listed above would be the best solution, alternatively any other suggestion on how to approach the problem using other tools is very welcome (I have a little experience with d3.js).
Just do it yourself with their API, you can check the guide.
Here's my algorithm for a similar task where I show which cards were having that user as a member, so basically it's like "which cards have I been working on yesterday?" report.
Connect Trello SDK;
Authorize user (only read permissions) when he clicks a button (so the popup doesn't get blocked);
Fetch /tokens/[token] endpoint to figure out the user's memberID;
Fetch /members/[memberID]/actions for a required period filtering only by addMemberToCard,removeMemberFromCard actions;
Run a loop over resulting array to figure out datetime difference between addMemberToCard and removeMemberFromCard for every card in the response;
Format everything and show to the user!
As an example, here's my realization of it: Trello Activity Report
Code is here: https://github.com/pistonsky/trello-activity-report
P.S. Instead of using addMemberToCard and removeMemberFromCard action types, you can filter by updateCard:idList and calculate the datetime difference between when card is moved from To Do to Done list.
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.