I have a situation that I have a system that communicate with iLog and it should show the values of decision table first column.
Can I get all the values of the first column in a decision table? Given that the values are distinct and unique.
If yes, What if I want to get the values of the next column under the scope of the first column field.
I need this behavior since I have an agreement creation system which must allow creation of agreement terms based on what is already implemented in iLog
There isn't a way to extract values from Condition Column. I had also came across such situation when but couldn't get through it. However, there is a work-around for the same.
My Problem was, for example, there are rules to determine whether the user group to which user belong is allowed to approve the policy? If not, then what are the other user groups allowed to approve this policy?
One simple solution was to maintain two tables, one for checking and another to determine allowed groups. This was not accepted since business needs to maintain same data in two tables. Had it been FICO BLAZE Advisor, the same would have been implemented in a single table.
However, there is always another way to a problem. What I did is following:
1. Created a single table to list all are the groups which can approve the policy i.e. adding user groups into a list in the action column. Placed this decision table in a Rule Task.
2. In the final action of rule task, checked whether the user type of the incoming user exists in the list of user types. If not, it means user is not allowed to approve the policy so send the entire list; otherwise, set the list to null and set Approval flag to True.
I hope this may help you to find an alternate solution which may address your problem. Sometimes, we need to look for some weird way to get our work done.
HAPPY RULE DEVELOPMENT. :)
Related
I'm using Firebase in my iOS app but I want to ensure a value is never sent from the server to the client.
Users in the app are shown to each other based on a score they have. So a user with a score of 5 will see other users who have a score of 5. I don't want to include this value in the request/response to Firebase.
Where I can manage the server I can have server side logic handle this by looking up the user on the server then calling a function that determines who has the same score and returning the relevant users without the client ever receiving the user score.
With Firebase my understanding is I'd have to send the value to Firebase in a query i.e. get all users with this user's score.
How can I do this without exposing the user's score? I want something along the lines of a node user_scores where I can query the current users score and then using this query another node users to return me the relevant users without having to nest the query on the client and thus expose the score in the request/response?
Many thanks!
Your understanding is pretty much on point, there is no way to make a "dynamic" query like this without actually exposing the varying parameter to the client.
Here are two ideas you could try to use as a workaround:
A variation of "security by obscurity": instead of exposing a single number, obfuscate that value in a way that makes guessing its purpose and other values an unpleasant experience; and share that with the client.
If you keep your users grouped by this key, not just as a flat list where this is a child node, you can use security rules to enforce that the user cannot read any other group than theirs.
(Note that this is also true for numerical values. Security rules are not filters.)
In a much more involved strategy, you could make the query static. Store and maintain a list of matching users per user, so the clients can load their own personal list without any varying parameters sans the UID.
(This is probably not really feasible if there is a lot of movement involved. But it might work in some edge cases.)
We are trying to use BDD to create a web service to supply data to a web page and then save the user's changes.
The story I have so far goes
Given I want the data for order number 1234
When I load the data
Then I have the data for order number 1234
What am I missing in my approach?
Are user stories not appropriate for this kind of task?
How do I go about formulating meaningful user stories?
[Update]
As a customer
I want to see my order
So that I can check it is what I expect
Given I have entered the order number
When I Click GO
Then I should see my order displayed on the screen
Here's how I'd write what you have so far:
Feature:
As a customer
I want to be able to view and change my orders
So that I can check that they're being processed as I expect and deal with them if they're not
Scenario:
Given I am a customer
And I have an order
When I go to the order
Then I should see the order
(I indented the way my tools seem to want me indent Cucumber, which is what I use, but that's not important.)
Here are at least some of the reasons why I'd rewrite it that way:
It is usual for several Scenarios that have to do with the same product feature (order management in this case) to be in the same Feature file, so the Feature section should have a broader scope than a single Scenario. Maybe this Feature should even include placing orders in the first place.
Givens are things that are true before the time period that the scenario is about, like the existence of the customer and the order. Actions during the scenario belong in Whens.
It's good to avoid UI detail like "click" and specific button names and "displayed on the screen". The scenario should focus on behavior. The When I go to the order step can encapsulate the details of going to the screen where you enter the number, entering the number, and clicking the button.
Likewise, all of the checks for different fields of the order that should be visible can be encapsulated in Then I should see the order.
I said "the order" rather than "my order" because And I have an order establishes that there's a single order with a special relationship with the scenario, and it's good to establish a language across all your scenarios that makes that relationship clear -- I always use "the" in that case. (This is a very small point.)
With those stylistic points taken care of, this is an OK scenario and I've certainly written many similar ones. To get to your real question, however:
Where Specflow-type tools really shine is when you use them to describe as complete a use case/user story as you can. For example:
Scenario:
Given I am a customer
And there is a product
When I go to the product page
Then I should see the product
When I add the product to my cart
And I check out
Then I should see that the order has been placed
And I should receive an order confirmation email
When I go to my orders
Then I should see the order listed
When I go to the order
Then I should see the order
When I cancel the order
Then I should see that the order has been cancelled
And I should receive an order cancellation email
When I go to my orders
Then I should not see the order listed
This is more valuable as an acceptance test, because it captures more requirements, and it's more powerful as an integration test, because it exercises more of the system, and fakes less of it. (In the short scenario we had to create an order artificially. Here we're doing it through the system.)
I'm learning Rails by building a simple site where users can create articles and comment on those articles. I have a view which lists a user's most recent articles and comments. Now I'd like to add user 'profiles' where users can enter information like their location, age and a short biography. I'm wondering if this profile should be a separate model/resource (I already have quite a lot of fields in my user model because I'm using Authlogic and most of it's optional fields).
What are the pros and cons of using a separate resource?
I'd recommend keeping profile columns in the User model for clarity and simplicity. If you find that you're only using certain fields, only select the columns you need using :select.
If you later find that you need a separate table for some reason (e.g. one user can have multiple profiles) it shouldn't be a lot of work to split them out.
I've made the mistake of having two tables and it didn't buy me anything but additional complexity.
Pros: It simplifies each model
Cons: Managing 2 at once is slightly harder
It basically comes down to how big the user and profile are. If the user is 5 fields, and the profile 3, there is no point. But if the user is 12 fields, and the profile 20, then you definitely should.
I think you'd be best served putting in a separate model. Think about how the models correspond to database tables, and then how you read those for the various use cases your app supports.
If a user only dips in to his actual profile once in a while but the User model is accessed frequently, you should definitely make it a separate object with a one-to-one relationship. If the profile data is needed every time the User data is needed, you might want to stick them in the same table.
Maybe the location is needed every time you display the user (say on a comment they left), but the biography should be a different model? You'll have to figure out the right breakdown, but the general rule is to structure things so you don't have to pull data that isn't being used right away.
A user "owns" various resources on your site, such as comments, etc. If you separate the profile from the user then it's just one more resource. The user is static, while the profile will change from time to time.
Separating it out would also allow you to easily maintain a profile history.
I would keep it separate. Not all your users would want to fill out a profile, so those would be empty fields sitting in your user table. It also means you can change the profile fields without changing any of the logic of your user model.
Depends on the width of the existing user table. Databases typically havea limit to the number of bytes a recird can contain. I fyou are close to (or over which you can usually do if you have lots of fields with null values) the limit, I would add a table with a one-to-one relationship for better performance and less of a likelihood of a record that suddenly can't be inserted as there is too much data for the row size. If you are nowhere near the limit, the add to the exisiting table.
I have a Comment model in my app but am encountering a lot of problematic postings that I have to remove manually.
What I want to do is add a "flag for moderator attention" feature so that users of the app have the ability to remove a comment from view without my need to review all content in the app.
I'm thinking that after a comment has been flagged three times, I will remove it from view automatically and then when I have a chance to review these postings I will decide whether to allow them or permanently remove them from view.
What I'm having trouble with is how to implement this.
Should I have a separate table that records all items that have been flagged?
Or should I have a "flag count" field as part of the Comment table that keeps track of how many times a comment has been flagged?
A separate table would allow me to keep track of detailed information about the flagging actions - who is flagging, which IP they are flagging from, etc. This is what I'm leaning towards.
But perhaps a gem or plugin already exists that does this type of thing?
I don't know of any plugin. I like the solution you are leaning towards.
If you want to hide the comment after three flaggings have been created for it, you need to keep track of who created them, so people can flag just once.
I'd create a flag resource (which can hold any kind of flags your users can assign to particular comment), then a flagging resource which connects flags with comments and holds information about the entity which is responsible for flagging (which could be a user or a user represented by IP).
Every comment will then have many flaggings.
You can use state machine to change the status of a comment to "to_be_revised" or something similar after three flaggings have been added. State machine (aasm_state_machine or the one which is now incorporated directly into Rails) will also provide you with named_scopes for groups of comments with the same state.
After revision, you can set the state to "published" again and delete all the flaggings or to "unpublishable" and so hide it forever.
Perhaps the acts-as-flaggable plugin would work.
I am developing a gallery which allows users to post photos, comments, vote and do many other tasks.
Now I think that it is correct to allow users to unsubscribe and remove all their data if they want to. However it is difficult to allow such a thing because you run the risk to break your application (e.g. what should I do when a comment has many replies? what should I do with pages that have many revisions by different users?).
Photos can be easily removed, but for other data (i.e. comments, revisions...) I thought that there are three possibilities:
assign it to the admin
assign it to a user called "removed-user"
mantain the current associations (i.e. the user ID) and only rename user's data (e.g. assign a new username such as "removed-user-24" and a non-existent e-mail such as "noreply-removed-user-24#mysite.com"
What are the best practices to follow when we allow users to remove their accounts? How do you implement them (particularly in Rails)?
I've typically solved this type of problem by having an active flag on user, and simply setting active to false when the user is deleted. That way I maintain referential integrity throughout the system even if a user is "deleted". In the business layer I always validate a user is active before allowing them to perform operations. I also filter inactive users when retrieving data.
The usual thing to do is instead of deleting them from a database, add a boolean flag field and have it be true for valid users and false for invalid users. You will have to add code to filter on the flag. You should also remove all relevant data from the user that you can. The primary purpose of this flag is to keep the links intact. It is a variant of the renaming the user's data, but the flag will be easier to check.
Ideally in a system you would not want to "hard delete" data. The best way I know of and that we have implemented in past is "soft delete". Maintain a status column in all your data tables which ideally refers to the fact whether the row is active or not. Any row when created is "Active" by default; however as entries are deleted; they are made inactive.
All select queries which display data on screen filter results for only "active records". This way you get following advantages:
1. Data Recovery is possible.
2. You can have a scheduled task on database level, which can take care of hard deletes of once in a way; if really needed. (Like a SQL procedure or something)
3. You can have an admin screen to be able to decide which accounts, entries etc you'd really want to mark for deletion
4. A temperory disabling of account can also be implemented with same solution.
In prod environments where I have worked on, a hard delete is a strict No-No. Infact audits are maintained for deletes also. But if application is really small; it'd be upto user.
I would still suggest a "virtual delete" or a "soft delete" with periodic cleanup on db level; which will be faster efficient and optimized way of cleaning up.
I generally don't like to delete anything and instead opt to mark records as deleted/unpublished using states (with AASM i.e. acts as state machine).
I prefer states and events to just using flags as you can use events to update attributes and send emails etc. in one foul swoop. Then check states to decide what to do later on.
HTH.
I would recommend putting in a delete date field that contains the date/time the user unsubscribed - not only to the user record, but to all information related to that user. The app should check the field prior to displaying anything. You can then run a hard delete for all records 30 days (your choice of time) after the delete date. This will allow the information not to be shown (you will probably need to update the app in a few places), time to allow the user to re-subscribe (accidental or rethinking) and a scheduled process to delete old data. I would remove ALL information about the member and any related comments about the member or their prior published data (photos, etc.)
I am sure it changing lot since update with Data Protection and GDPR, etc.
the reason I found this page as I was looking for advice because of new Apply policy on account deletion requirements extended https://developer.apple.com/news/?id=i71db0mv
We are using Ruby on Rails right now. Your answers seem a little outdated? or not or still useful right now
I was thinking something like that
create a new table “old_user_table” with old user_id , First name, Second name, email, and booking slug.
It will allow keep all users who did previous booking. And deleted their user ID in the app. We need to keep all records for booking for audit purpose in the last 5 years in the app.
the user setup with this app, the user but never booking, then the user will not transfer to “old_user_table” cos the user never booking.
Does it make sense? something like that?